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

白帽子讲web 安全 读书笔记

防止挂马

1. 客户端沙箱（浏览器保护自己）
   通常会有恶意代码注入的问题，为了解决"挂马"对浏览器的影响，浏览器有两种解决方法:
   sandbox + 多进程。

   • 浏览器将不被信任的用户代码（用sandbox包裹）与浏览器内核进程隔绝开，只通过IPC通道访问。
   • 每一个tab页都是一个进程，多进程可以防止某一个崩溃，整个浏览器就崩溃的问题，提升了用户体验。

2. 恶意网址拦截（浏览器保护用户）
   恶意网址包括：

   • 挂马网站
   • 钓鱼网站

   通常情况下，挂马可能有两种，一种是直接嵌入代码，一种就是恶意网址链接（通过script指向恶意网址）。其实后者是前者的前一步。
   拦截的方法主要是：浏览器定时从服务获取黑名单匹配。

   （而不是浏览器去进行匹配操作，一方面是因为匹配操作放在浏览器，那么攻击者是可以分析解决的，另一方面，数据量过大）

   除此之外，还有EVSSL证书（全球证书颁发机构与浏览器厂商的增强型证书），比普通的https还要显著。

3. XSS payload

   • Cookie劫持
     document.cookie访问后，可以伪造发包，然后模拟登录，然后就可以获取更多的信息了。
     解决：
     httpOnly不许通过脚本访问cookie。即cookie可以被自动被发送，但是无法获取

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

   • 其他要攻击者多做的事情包括：

     • 图片验证码.(黑客：可以把图片url发往远程服务器去解析)
     • old password：钓鱼

   • 收集信息

     • 识别用户浏览器：
       （1）navigator.userAgent(不太准确，因为userAgent可以伪造)
       （2）分析浏览器独特特征，来进行匹配 【学者Gareth Heyes】
     • 识别安装软件、插件、扩展：
       通过识别是否安装某控件来判断、是否有某软件的classId来判断
       扫描Plugins列表，Extension（比如某扩展如果装了就可以显示某个图标，那么放一个src=图标的url，看是否显示）

   • XSS构造技巧

     • 绕过长度限制：
       （1）放event事件中（少了"script"）
       (2) location.hash中写（而不是input中）
       （3）利用注释符，把input注释掉，在后面放script

       <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>" />

     • 使用base：把本页面的所有相对路径，都附上base指向的恶意网址。然后在恶意网址的服务器中构造相应的路径。

     • window.name 可以在两个域传输数据

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

4. 防范XSS

   • HttpOnly
     服务器发送指示，要求set-Cookie中某一个cookie httpOnly。那么浏览器会设置所有的cookie。但是设置了httpOnly的cookie是不能被访问的。
     通过TRACE请求可以绕过这个，它的responseBody里面会返回cookie.
   • 输入检查
     看是否包括有害特殊字符，匹配XSS特征等
     XSS-filter（但是某些转义可能会违背用户本意）
   • 输出检查
     escape编码，但是其实也不一定能满足需求。要分场景。
   • 根本解决方案：列出场景，逐一解决：
     
     • html: htmlEncode
     • script中：保证所有变量都在“”双引号中。
     • 事件中： javascriptEncode
       
     • css中：尽可能禁止用户输入变量放在style标签中，用encodeForCSS()
     • 地址（url）中:URLEncode
       
       
   • 富文本（用户自定义的html）:禁止“事件”

5. Dom based XSS首先，在“$var”输出到时，应该执行一次javascriptEncode；其次，在docu-ment.write输出到HTML页面时，要分具体情况
   之前的都是在应用中获得输入然后放到html中，但是dom based是从javascript中获取然后放进html中

   

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

6. 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，无法发送请求）。

     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。