读书笔记——白帽子讲web安全（一）

防止挂马

客户端沙箱（浏览器保护自己）
通常会有恶意代码注入的问题，为了解决”挂马”对浏览器的影响，浏览器有两种解决方法:
sandbox + 多进程。
- 浏览器将不被信任的用户代码（用sandbox包裹）与浏览器内核进程隔绝开，只通过IPC通道访问。
- 每一个tab页都是一个进程，多进程可以防止某一个崩溃，整个浏览器就崩溃的问题，提升了用户体验。
恶意网址拦截（浏览器保护用户）
恶意网址包括：
- 挂马网站
- 钓鱼网站
  
  通常情况下，挂马可能有两种，一种是直接嵌入代码，一种就是恶意网址链接（通过script指向恶意网址）。其实后者是前者的前一步。
  拦截的方法主要是：浏览器定时从服务获取黑名单匹配。
  
  （而不是浏览器去进行匹配操作，一方面是因为匹配操作放在浏览器，那么攻击者是可以分析解决的，另一方面，数据量过大）
  
  除此之外，还有EVSSL证书（全球证书颁发机构与浏览器厂商的增强型证书），比普通的https还要显著。

跨站脚本攻击

XSS payload

Cookie劫持

document.cookie访问后，可以伪造发包，然后模拟登录，然后就可以获取更多的信息了。

解决：
httpOnly不许通过脚本访问cookie。即cookie可以被自动被发送，但是无法获取

1 Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

其他要攻击者多做的事情包括：
- 图片验证码.(黑客：可以把图片url发往远程服务器去解析)
- old password：钓鱼
- 收集信息
  - 识别用户浏览器：
    1. navigator.userAgent(不太准确，因为userAgent可以伪造)
    2. 分析浏览器独特特征，来进行匹配【学者Gareth Heyes】
  - 识别安装软件、插件、扩展：
    1. 通过识别是否安装某控件来判断
    2. 是否有某软件的classId来判断
      扫描Plugins列表，Extension（比如某扩展如果装了就可以显示某个图标，那么放一个src=图标的url，看是否显示）
  - XSS构造技巧
    - 绕过长度限制：
      1. 放event事件中（少了”script”）
        
        location.hash中写（而不是input中）
        
        利用注释符，把input注释掉，在后面放script

     1
2
3
4
5
6
7 <input id=1 type="text" value="" />
xxxxxxxxxxxxx
<input id=2 type="text" value="" />
在第一个input框中，输入："><!--
在第二个input框中，输入：--><script>alert(/xss/);</script>
最终
<input id=1 type="text" value=""><!--" /> xxxxxxxxxxxxxxxxx <input id=2 type="text" value="--><script>alert(/xss/);</script>" />


    4. 使用base：把本页面的所有相对路径，都附上base指向的恶意网址。然后在恶意网址的服务器中构造相应的路径。
    5. window.name 可以在两个域传输数据

- 变废为宝： apache expect (可注入)

防范XSS

HttpOnly

服务器发送指示，要求set-Cookie中某一个cookie httpOnly。那么浏览器会设置所有的cookie。但是设置了httpOnly的cookie是不能被访问的。
通过TRACE请求可以绕过这个，它的responseBody里面会返回cookie.

输入检查

看是否包括有害特殊字符，匹配XSS特征等
XSS-filter（但是某些转义可能会违背用户本意）

输出检查

escape编码，但是其实也不一定能满足需求。要分场景。

根本解决方案：列出场景，逐一解决：

html: htmlEncode
script中：保证所有变量都在“”双引号中。
事件中： javascriptEncode

![](http://p1.bpimg.com/567571/1236b29deaada5b0.png)

css中：尽可能禁止用户输入变量放在style标签中，用encodeForCSS()
地址（url）中:URLEncode
富文本（用户自定义的html）:禁止“事件”

Dom based XSS

首先，在$var输出到<script>时，应该执行一次javascriptEncode；其次，在document.write输出到HTML页面时,要分具体情况看待：如果是输出到事件或者脚本，则要再做一次javascriptEncode；如果是输出到HTML内容或者属性，则要做一次HtmlEncode。

csrf

在b.com域名下，有一个img，src为a.com域名下的某个请求A，黑客先诱导用户登录a.com。由于在同一个浏览器下同一个域名的tab页面是共享cookie的，因此A中是携带了cookie的。那么用户访问b页面时，间接访问了a，就达到了跨域执行a页面请求的目的。（第三方cookie）
在某些浏览器下，第三方cookie是被禁止的，比如ie,可以避免csrf。但是由于p3p的出现，使得第三方cookie可以被发送，csrf。

P3P Header是W3C制定的一项关于隐私的标准，全称是The Platform for Privacy Prefer-ences。如果网站返回给浏览器的HTTP头中包含有P3P头，则在某种程度上来说，将允许浏览器发送第三方Cookie。

它的防御有

验证码：因为csrf往往在用户不知情的情况下进行操作，用验证码就是让用户对自己的请求操作知晓、负责。
Referer Check在互联网中最常见的应用就是“防止图片盗链”。用来验证发送请求的页面是否是应有的页面，或者是否是在同一个域名下。比如之前的b中iframe中有a的请求，它的referer就是b。
但是服务端有时候是不能获取到referer的。由于隐私设置等等。
token：一个仅被浏览器与服务器知晓的随机数，每次请求时都需要携带这个token信息来验证身份。（使得攻击者无法知晓token，无法发送请求）。

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

因为csrf请求的前提是攻击者要知道完整的url，如果用token的话，就需要提前知道这个token。而token的获取是随着页面生成/打开才生成的。（可以理解为执行生成，非编译时）。攻击者给出来的只是链接非页面，它无法知道token。所以请求无法构造。但是如果嵌入的是iframe...= =。

具体来说是，每次打开某个请求页面，服务器都会返回一个token，（可以是后端渲染前端页面时直接嵌进表单，如下图）。

然后表单请求的时候，服务端读取这个token，跟后端session中的token比对，验证表单是否可信。(实际上，比对可以是前端跟后端，也可以是前端跟前端，就是表单跟cookie比对，因为后端存session中的话是需要消耗一定资源的，如果直接放在cookie中可以减少消耗，在仅仅csrf攻击，不涉及其他的情况下，cookie是不能被更改的，那么验证表单跟cookie中token===表单与session中token)。

还有几个注意事项是：

- token生命周期，为了使用方面，可以在某个时间段内都使用同一个token，但是一提交表单就应废弃一个token。
- 多个相同页面打开时，如果一个消耗完，其他页面要相应的同步，或者设置几个同时有效的token。
- token应该避免存在url中，（应尽量放在表单中），否则可以由referer被泄露。
- 尽量用post代替get，因为get请求的话参数会被暴露到url中，就可能暴露表单提交中的token。

why it works?

- 难猜到
- 难获取：攻击者需要通过某种手段获取你站点的CSRF token， 他们只能使用JavaScript来做，但是如果站点不支持CORS，跨域的话，那么他们就没有办法来获取CSRF token。因此确保CSRF token不能通过AJAX访问到。