[关闭]
@lizlalala 2017-01-28T13:54:35.000000Z 字数 3273 阅读 1193

读书笔记——白帽子讲web安全(一)

白帽子讲web 安全 读书笔记


防止挂马

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

    • 浏览器将不被信任的用户代码(用sandbox包裹)与浏览器内核进程隔绝开,只通过IPC通道访问。
    • 每一个tab页都是一个进程,多进程可以防止某一个崩溃,整个浏览器就崩溃的问题,提升了用户体验。
  2. 恶意网址拦截(浏览器保护用户
    恶意网址包括:

    • 挂马网站
    • 钓鱼网站

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

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

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

  3. 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】
      • 识别安装软件、插件、扩展:
        通过识别是否安装某控件来判断、是否有某软件的classId来判断
        扫描Plugins列表,Extension(比如某扩展如果装了就可以显示某个图标,那么放一个src=图标的url,看是否显示)
    • XSS构造技巧

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

        1. <input id=1 type="text" value="" />
        2. xxxxxxxxxxxxx
        3. <input id=2 type="text" value="" />
        4. 在第一个input框中,输入:"><!--
        5. 在第二个input框中,输入:--><script>alert(/xss/);</script>
        6. 最终
        7. <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中

    1. 首先,在“$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,无法发送请求)。

      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。
添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注