《白帽子讲Web安全》世界观安全

Posted 2023-03-31 FangWenJing150

1.Web安全简史

1.1中国黑客简史

对于现代计算机系统来说，在用户态的最高权限是root，也是黑客们最渴望能够获取的系统最高权限。不想拿到“root”的黑客，不是好黑客。

在现实世界中，真正造成破坏的，往往并非那些挖掘并研究漏洞的“黑客们”，而是这些脚本小子。而在今天已经形成产业的计算机犯罪、网络犯罪中，造成主要破坏的，也是这些“脚本小子”。

1.2黑客技术的发展历程

从黑客技术发展的角度看，在早期，黑客攻击的目标以系统软件居多。运营商、防火墙对于网络的封锁，使得暴露在互联网上的非Web服务越来越少，且Web技术的成熟使得Web应用的功能越来越强大，最终成为了互联网的主流。黑客们的目光，也逐渐转移到了Web这块大蛋糕上。

1.3Web安全的兴起

2.黑帽子，白帽子

正如一个硬币有两面一样，“黑客”也有好坏之分。

在黑客的世界中，往往用帽子的颜色来比喻黑客的好坏。

3.返璞归真，揭秘安全的本质

安全问题的本质是信任的问题。

一切的安全方案设计的基础，都是建立在信任关系上的。我们必须相信一些东西，必须有一些最基本的假设，安全方案才能得以建立；如果我们否定一切，安全方案就会如无源之水，无根之木，无法设计，也无法完成。

4.破除迷信，没有银弹

安全是一个持续的过程。

5.安全三要素

6.如何实施安全评估

6.1资产等级划分

对互联网公司所拥有的资产进行等级划分，就是对数据做等级划分。

做资产等级划分的过程，需要与各个业务部门的负责人一一沟通，了解公司最重要的资产是什么，他们最着重的数据是什么。通过访谈的形式，安全部门才能熟悉、了解公司的业务，公司所拥有的数据，以及不同数据的重要程度，为后续的安全评估过程指明方向。

6.2威胁分析

在本书中介绍一种威胁建模的方法，它最早是由微软提出的，叫做STRIDE模型。

威胁	定义	对应的安全属性
Spoofing（伪装）	冒充他人身份	认证
Tampering（篡改）	修改数据或代码	完整性
Repudiation（抵赖）	否认做过的事情	不可抵赖性
InformationDisclosure（信息泄露）	机密信息泄露	机密性
Denial of Service（拒绝服务）	拒绝服务	可用性
Elevation of Privilege（提升权限）	未经授权获得许可	授权

6.3风险分析

如何更科学地衡量风险呢？这里再介绍一个DREAD模型，它也是由微软提出的。

等级	高（3）	中（2）	低（1）
Damage Potential	获取完全验证权限； 执行管理员操作； 非法上传文件	泄露敏感信息	泄露其他信息
Reproducibility	攻击者可以随意再次攻击	攻击者可以重复攻击，但有时间限制	攻击者很难重复攻击过程
Exploitability	初学者在短期内能掌握攻击方法	熟练的攻击者才能完成这次攻击	漏洞利用条件非常苛刻
Affected users	所有用户，默认配置，关键用户	部分用户，非默认配置	极少数用户，匿名用户
Discoverability	漏洞很显眼，攻击条件很容易获得	在私有区域，部分人能看到，需要深入挖掘漏洞	发现该漏洞及其困难

6.4设计安全方案

作为安全工程师，要想的就是如何通过简单而有效的方案，解决遇到的安全问题。安全方案必须能够有效抵抗威胁，但同时不能过多干涉正常的业务流程，在性能上也不能拖后腿。

好的安全方案对用户应该是透明的，尽可能地不要改变用户的使用习惯。

7.白帽子兵法

7.1 Secure By Default原则

按照白名单的思想，应该根据业务需求，列出一个允许使用的软件以及软件版本的清单，在此清单外的软件则禁止使用。如果允许工程师在服务器上随意安全软件的话，则可能会因为安全部门不知道、不熟悉这些软件而导致一些漏洞，从而扩大攻击面。

通配符“*”，代表来自任意域的Flash都能访问本域的数据，因此就造成了安全隐患。

所以在选择使用白名单时，需要注意避免出现类似通配符“*”的问题。

最小权限原则要求系统只授权主体必要的权限，而不要过度授权，这样能有效地减少系统、网络、应用、数据库出错的机会。

7.2 纵深防御原则

纵深防御并不是同一个安全方案要做两边或多遍，而是要从不同的层面、不同的角度对系统做出整体的解决方案。

它要求我们深入理解威胁的本质，从而做出正确的应对措施。

7.3 数据与代码分离原则

在Web安全中，由“注入”引起的问题比比皆是，此类问题均可以根据“数据与代码分离原则”设计出真正安全的解决方案，因为这个原则抓住了漏洞形成的本质原因。

7.4 不可预测性原则

不可预测性能有效地对抗基于篡改、伪造的攻击。

不可预测性的实现往往需要用到加密算法、随机数算法、哈希算法。

《白帽子讲Web安全》读后感

0x00：简介

0x01：白帽世界观

一、实施安全评估

1.1 一个安全评估的过程，可以分为4个阶段：资产等级划分、威胁分析、风险分析、确认解决方案

1.2  资产等级划分。就是对数据做等级划分，互联网安全的核心问题，是数据安全的问题。

做资产等级划分的过程，需要与各个业务部门的负责人一一沟通，了解公司最重要的资产是什么，他们最看重的数据是什么。

1.3 威胁分析。注意与“风险分析”区别。

什么是威胁分析？威胁分析就是把所有的威胁都找出来。一般采用头脑风暴的方法。

也可以使用微软提出的STRIDE模型Spoofing(伪装)、Tampering(篡改)、Repudiation(抵赖)、InformaitonDisclosure(信息泄露)、Denial or Service(拒绝服务)、Elevation of Privilege(提升权限)

1.4 Secure By Default 原则：设计安全方案时，最基本、最重要的原则

黑名单、白名单
最小权限原则
纵深防御原则：从不同的层面、不同的角度对系统做出整体的解决方案。将风险分散到系统的各个层面，通过在不同层面设计的安全方案，共同组成整个防御体系；深入理解威胁的本质，从而做出正确的应对措施。
数据与代码分离原则：广泛适用于各种由于“注入”而引发的安全问题，缓冲区溢出。将数据片段当成代码片段来解释。
不可预测性原则：从克服攻击方法的角度看问题。有效的对抗基于篡改、伪造的攻击。

0x02：客户端脚本安全

2.1 同源策略

浏览器的同源策略，限制了来自不同源的“document”或脚本，对当前“document”读取或设置某些属性。

对于JavaScript来说，以下情况被认为是否同源

下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:

URL	结果	原因
http://store.company.com/dir2/other.html	同源	只有路径不同
http://store.company.com/dir/inner/another.html	同源	只有路径不同
https://store.company.com/secure.html	失败	协议不同
http://store.company.com:81/dir/etc.html	失败	端口不同 ( http:// 默认端口是80)
http://news.company.com/dir/other.html	失败	主机不同

同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。所以xyz.com下的js脚本采用ajax读取abc.com里面的文件数据是会被拒绝的。

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。

不受同源策略限制的

1. 页面中的链接，重定向以及表单提交是不会受到同源策略限制的。

2. 跨域资源的引入是可以的。但是js不能读写加载的内容。如嵌入到页面中的<script src="..."></script>，<img>，<link>，<iframe>等。

2.2 跨站脚本攻击（XSS）

2.2.1 XSS成因：把用户输入的参数直接输出到页面上，用户输入的参数被当作代码执行；本质是一种“HTML注入”

2.2.2 DOM型XSS

将HTML代码写入了DOM节点，最后导致了XSS的发生

这种类型的XSS并非按照“数据是否保存在服务器端”来划分。从效果上来看也是一种反射型XSS。

通过修改页面的DOM节点形成XSS，称之为DOM Based XSS

一句话概括：DOM—based XSS漏洞是基于文档对象模型Document Objeet Model,DOM)的一种漏洞。

dom - xss是通过url传入参数去控制触发的。

dom树的关系：

 

 

 DOM xss取决输出位置，并不取决于输出环境，有可能是反射型也有可能是存储型，DOM型XSS可以改变HTML的结构

2.2.3 XSS构造技巧

2.2.3.1 利用字符编码

var redirectUrl="\\";alert(/xss/)"

我的理解：对参数中的特殊字符 单引号或双引号等 前面加上斜杠转义。当页面返回是GBK/GB2312编码时，可利用“%df\\”这两个字符组合在一起是一个汉字，这样就把  \\  去掉，让其失去作用。类似宽字节注入。

2.2.3.2 绕过长度限制

当服务端对输入参数长度进行限制，普通payload：<script>alert(/xss/)</script>，就无法全部输入。

此时可以利用事件（Event）来缩短所需的字节数

<input type=text value="$var" />

$var 输出为："onclick=alert(1)//

<input type=text value=""onclick=alert(1)//" />

在某些环境下，可以利用注释符绕过长度限制

有两个文本框，第一个文本框有长度限制，第二个文本框允许写入更多的字节

<input id=1 type="text" value="" />
xxxxxxxxx
<input id=2 type="text" value="" />

最终效果：
<input id=1 type="text" value=""><!--" />
xxxxxxxxx
<input id=2 type="text" value="--><script>alert(/xsss/)</script>" />

或者写到“location.hash”

2.2.4 XSS的防御

2.2.4.1 HttpOnly

浏览器将禁止页面的JavaScript访问带有HttpOnly属性的Cookie。

一个Cookie的使用过程：

（1）浏览器向服务器发起请求，这时候没有Cookie.

（2）服务器返回时发送Set-Cookie头，向客户端浏览器写入Cookie

（3）在该Cookie到期之前，浏览器访问该域下的所有页面，都将发送该Cookie

HttpOnly时在Set-Cookie时标记的

Set-Cookie:<name>=<value>xxxxx
xxxxx[;HttpOnly]

2.2.4.2 输入检查

HTML实体编码、白名单

2.2.4.3 输出检查

 

一些XSS的利用记录

XSS盲打获取cookie：https://www.cnblogs.com/liqik/p/12885493.html 

XSS靶场练习  ： https://www.cnblogs.com/liqik/p/11347083.html

2.3 跨站点请求伪造（CSRF）

CSRF漏洞学习笔记 ：https://www.cnblogs.com/liqik/p/11160806.html

成因：没有对用的操作进行验证

2.3.1 浏览器的Cookie策略

两种Cookie：“session Cookie”,又称“临时Cookie”;“Third-party Cookie”，也称“本地Cookie”

（1）session是临时的浏览器关闭即失效；cookie是长期的保存在本地，有截止日期，到期后失效

（2）Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。

（3）Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关

（4）Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击

（5）Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力

（6）可以考虑将登陆信息等重要信息存放为session，不重要的信息可以放在cookie中

（7）单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie

在当前浏览器中会拦截“本地Cookie”的有：IE6、IE7、IE8、Safari，不会拦截的有：Firefox、Google Chrome、Android

2.3.1.1 一个CSRF的POC例子，使用JavaScript自动提交

<from action="http://www.a.com/register" id="register" method="post">
<input type=text name="username" value="" />
<input type=password name="password" value="" />
<input type=submit name="submit" value="submit" />
</from>
<script type="text/javascript">
    var f = document.getElementById("register");
    f.inputs[0].value = "test";
    f.inputs[1].value = "password";
    f.submit();
</script>

攻击者可以将这个页面隐藏在一个不可见的iframe窗口中，整个自动提交表单的过程，用户是不可见的

Burpsuite可以一键生成POC，POC也可写成404

2.3.2 CSRF的防御

 2.3.2.1 验证码

 验证码强制用户必须于应用交互，但是影响用户体验，只能作为一种防御手段。

2.3.2.2 Referer check

 检查请求是否来自合法的“源”。无法依赖Referer check来防御CSRF，但是可以监控CSRF的发生

Referer check的缺陷在于，服务器并非什么时候都能取到Referer 

2.3.2.3 CSRF Token  ***

主要防御手段

CSRF的本质原因是：重要操作的所有参数都是可以被攻击者猜测到的

方法一：参数加密

例如：

http://host/path/delere?username=abc&item=123
参数加密之后
http://host/path/delere?username=md5(salt+abc)&item=123

这样会使URL非常难读，且可能无法收藏

方法二：Token - 新加一个参数Token

http://host/path/delere?username=abc&item=123&token=[random(seed)]

Token会作为一个隐藏的input字段，放在from中，同时存在于session中

要避免Token泄露（带有Token的Referer会泄露Token）

配合XSS https://www.cnblogs.com/xishaonian/p/6557769.html

2.4 点击劫持（ClickJacking）

一种视觉欺骗，在网页中插入一个指向目标网站的iframe，这个iframe是透明的，可覆盖在正常网页关键按钮处，用户在不知情的情况下点击了透明的iframe的按钮

解决方案：使用一个HTTP头-----X-Frame-Options

 

finished