《白帽子讲web安全》读书笔记系列13：浏览器安全、XSS与CSRF攻击与防御

1、浏览器安全

1）同源策略：限制来自不同源的document或脚本，对当前document读取或设置某些属性。

影响源的因素：host、子域名、端口、协议

2）挂马：在网页中插入一段恶意代码，利用浏览器漏洞执行任意代码的攻击方式

沙箱：资源隔离类模块，让不可信任的代码运行在一定的环境中，限制其房屋隔离区之外的资源；

3）恶意网址拦截：黑名单拦截

 

2、跨站脚本攻击（XSS） Cross Site Script 本来为CSS，为与Cascading Style Sheet区别，故安全领域叫做XSS

XSS：客户端脚本安全的头号大敌，黑客通过“HTML注入”篡改页面，插入恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。

反射型XSS：简单地把用户输入的数据“反射”给浏览器，非持久型XSS；

存储型XSS：把用户输入的数据“存储”在服务器，持久攻击。

DOM Based XSS：通过修改页面的DOM节点形成的XSS

XSS攻击成功后，攻击者能够对用户当前浏览器的页面植入恶意脚本，被称为XSS Payload

一个最常见的XSSPayload就是通过读取cookie，从而发起cookie劫持攻击。

强大的XSSPayload:

1）构造GET与POST请求

2）XSS钓鱼

3）识别用户浏览器

4）识别用户安装的软件

5）CSS History Hack 发现用户曾经访问过的网站

6）获取用户真实IP

 

XSS攻击平台：演示XSS危害，方便渗透测试

Attack API

BeEF

XSS-Proxy

 

终极武器：XSS Worm

一般而言，用户之间发生交互行为的页面，如果存在存储型XSS，则比较容易发生XSS Worm攻击。

 

2.1、XSS的防御

1）HttpOnly

严格地说，HttpOnly并非为对抗XSS，而是解决XSS后的cookie劫持攻击。

2）输入检查

同时在客户端javascript中和服务器端代码中实现相同的输入检查，客户端检查可以阻挡大部分误操作的正常用户，从而节约服务器资源。

3）输出检查

2.2、正确的防御XSS

XSS的本质是“HTML注入”，用户的数据被当成了HTML代码的一部分来执行，从而混淆了原本的语义，产生了新的语义。

以下从变量被填充入HTML代码中的不同场景，分析防御方法：

1）在HTML标签中输出 HtmlEncode

2）在HTML属性中输出 HtmlEncode

3）在<script>标签中输出 JavascriptEncode

4）在事件中输出 JavascriptEncode

5）在CSS中输出 encodeForCSS()

6）在地址中输出 如果变量是整改URL，则应该先检查变量是否以http开头（如果不是则自动添加），以保证不会出现伪协议类的XSS攻击，然后再对变量进行URLEncode。

7）处理富文本、防御DOM Based XSS 略。

 

3、跨站点请求伪造（CSRF） Cross Site Request Forgery

3.1 浏览器cookie分两种：

1）session cookie 临时cookie 保存在浏览器内存，浏览器关闭即失效

2）Third-party cookie 本地cookie 保存在本地，达到expire时间后失效

很多浏览器不会拦截Third-party cookie，如firefox、chrome等，这会利于CSRF攻击；

P3P头的副作用会导致原本拦截Third-party cookie的浏览器也不再拦截。

GET、POST均能构造CSRF攻击；

CSRF Worm，即使没有XSS，仅依靠CSRF，也可能发起大规模蠕虫攻击。

3.2 CSRF的防御

1）验证码

2）Referer Check

常见应用：防止图片盗链，也可用于检查请求是否来自合法的“源”；

缺陷：服务器并非什么时候都能取到referer

3）Anti CSRF Token

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

初级解决方案：将URL中的参数值加密；缺点：URL难读、不利于被收藏和数据分析；

优化解决方案：保持URL中的参数不变，增加一个随机的、不可预测的token参数值；

token同时存在于表单和session，服务器验证其一致性，不一致则可能发生了CSRF攻击。

token应用原则：

a、足够随机

b、token不是为了防止重复提交，但可应用于防止表单提交；

c、如果token存于cookie，而不是服务端session，多个相同页面同时操作时，首次操作消耗掉token后，其他页面操作将报token错误；

d、注意token保密性，不要出现在URL中，否则会通过referer被获取，应尽量将之放到表单中，改GET为POST，以避免token泄露；

e、如果存在XSS或其他跨域漏洞，token将被泄露，形成XSRF攻击。