随笔- 12  文章- 0  评论- 31 

1. 什么是XSS攻击?

正常的页面被渗出了攻击者的js脚本,这些脚本可以非法地获取用户信息,然后将信息发送到attacked的服务端。

XSS是需要充分利用输出环境来构造攻击脚本的

2. 危害

  • 非法获取用户cookie、ip等内容

  • 窃取用户输入的内容

  • 劫持浏览器,形成DDOS攻击

3. 类型

  • Reflected XSS:可以理解为参数型XSS攻击,攻击的切入点是url后面的参数
    // 合法页面
    url: http://aa.com?test=1234
    <input type="text" value={test} />
    
    // result is:
    <input type="text" value="1234" />
    
    // XSS攻击
    url: http://aa.com?test=" /><script>alert('xss')</script>
    <input type="text" value={test} />
    
    // result is:
    <input type="text" value="" /> <script> alert('xss')</script> />
  • stored XSS: 将攻击js脚本上传到服务器端,每次输出时,也随着内容将脚本输出,这样js恶意脚本就可以起到攻击作用。
    // input: 
    <textarea>
        hello  </div><script src="..."></script>
    </textarea>
    // 将hello及后面的内容一起提交到服务上
    
    //输出上述内容
    <div>
        hello</div><script src="..."></script>
    </div>
  • DOM based XSS:这种攻击方式也是通过URL的参数,但是需要了解正常js的DOM操作,将js脚本注入到页面中
    <div id="inner"></div>
    <script>
    var ele = document.querySelector('#inner');
    var search = window.location.search;
    var age = getAge(search) // 获取search中age的内容
    ele.innerHTML = age;
    
    // if url: aa.com?age=23
    <div id="inner">23</div>
    </script>
    
    // if url: aa.com?age=</div><script src="..."></script>
    <div id="inner"></div><script src="..."></script>
  • 突变型XSS:是当不可信数据在DOM的innerHTML属性的上下文被处理并通过浏览器发生突变,导致变成一种有效的XSS方向的一种XSS漏洞

4.解决方案

  • 对内容进行编码,包括server、client端均要进行编码。但是不同的内容,就需要采用不同的编码方式。

总体来讲需要对HTML、Attribute、js context、URL、style context、JSON分别进行编码处理。

  • 对html内容进行过滤,例如html purifierjs-xss

  • X-XSS-Protection

    IE8+以上的浏览器均支持该http header,目前goole里面已经添加该属性:

    x-xss-protection:1; mode=block
  • 监控跨站资源:针对csp中存在的问题,进行监控。FEX团队写了几篇非常好的文章:

    【XSS】利用 onload 事件监控跨站资源

    XSS 前端防火墙 —— 内联事件拦截

    XSS 前端防火墙 —— 可疑模块拦截

    XSS 前端防火墙 —— 无懈可击的钩子

    XSS 前端防火墙 —— 天衣无缝的防护

    XSS 前端防火墙 —— 整装待发

  •  content security policy(CSP): W3C和各大浏览器厂商均推荐和实践防御XSS的标准,限制执行、请求具有风险的外链资源,攻击者无法将目标信息传出,并对relected XSS进行防御。

    在HTTP的response中部署CSP,指定资源白名单来限制浏览器访问未经允许的外部资源。

    目前Google、facebook、twitter均支持该标准,例如twitter的配置信息:

    content-security-policy:default-src https:; 
    connect-src https:; font-src https: data:; 
    frame-src https: twitter:; frame-ancestors 'self'; 
    img-src https: blob: data:; media-src https: blob:; 
    object-src https:; 
    script-src 'unsafe-inline' 'nonce-w6FV5VZOKta+7JaW7PpR3A==' 'unsafe-eval' https:; 
    style-src 'unsafe-inline' https:; 
    report-uri https://twitter.com/i/csp_report?a=NVQWGYLXFVZXO2LGOQ%3D%3D%3D%3D%3D%3D&ro=false; 

    上述配置的详细参数请参考CSP的相关规范,csp1.0,目前csp1.1草案已经出来。 然而,csp中不允许Eval、inline js、白名单获取远程脚本,这些阻碍着csp的推广。

  • Template Engine:对处理输出内容进行编码,放置恶意代码执行,对stored Xss进行防御。

    例如经常使用handlebars就对输出的内容进行了编码:

    Handlebars HTML-escapes values returned by a {{expression}}. 
    If you don't want Handlebars to escape a value,
    use the "triple-stash", {{{.
    
    <div class="entry">
        <h1>{{title}}</h1>
       <div class="body">
            {{{body}}}
      </div>
    </div>
    
    {
         title: "All about <p> Tags",
         body: "<p>This is a post about &lt;p&gt; tags</p>"
    }
    
    result is as below:
    
    <div class="entry">
        <h1>All About &lt;p&gt; Tags</h1>
        <div class="body">
            <p>This is a post about &lt;p&gt; tags</p>
      </div>
    </div>
  • Util Lib:提供安全的environment、Encode等工具,避免location、cookie封装对DOM based XSS工具。

    首先在服务端端,对输出的内容进行编码,对request中的内容进行检查编码。

    在客户端,对js获取的widow.location、document.cookie等信息也需要相应处理。

  • 仅可能采用POST而非GET请求方式
  • 严格检查refer

5.参考

https://developer.mozilla.org/zh-CN/docs/Web/Security/CSP

http://www.80sec.com/browser-hijacking.html

https://cure53.de/fp170.pdf

http://www.freebuf.com/articles/web/40520.html

http://www.freebuf.com/articles/web/42727.html

http://blog.knownsec.com/wp-content/uploads/2014/07/%E7%BB%99%E5%BC%80%E5%8F%91%E8%80%85%E7%9A%84%E7%BB%88%E6%9E%81XSS%E9%98%B2%E6%8A%A4%E5%A4%87%E5%BF%98%E5%BD%95.pdf

 

 posted on 2015-07-05 21:57 big-brother 阅读(...) 评论(...) 编辑 收藏