跨站脚本攻击（XSS）

  • XSS简介

    • 跨站脚本攻击，英文全称是Cross Site Script,本来缩写是CSS,但是为了和层叠样式表（Cascading Style Sheet,CSS）有所区别，所以在安全领域叫做"XSS"。
    • XSS，通常指黑客通过“HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。在一开始，这种攻击的演示案例是跨越的，所以叫“跨站脚本呢”。但是发展到今天，由于JavaScript的强大功能以及网站前端应用的复杂化，是否跨站已经不再重要。
    • 反射型XSS
      • 反射型XSS只要简单地把用户输入的数据“反射”给浏览器，也就是说，黑客往往需要诱使用户“点击”一个恶意连接，才能成功。反射性XSS也叫做“非持久型XSS”
    • 存储型XSS
      • 存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。存储型XSS通常也叫做”持久性XSS“
    • DOM Based XSS
      • DOM Based XSS从效果上来说也是反射型XSS。单独划分出来，是因为DOM Based XSS的形成原因比较特别。发现它的安全专家专门提出了这种类型的XSS。

  • XSS攻击进阶

    • 初探XSS Payload
      • XSS攻击成功后，攻击者能够对用户当前浏览的页面植入恶意脚本，通过恶意脚本，控制用户的浏览器。这些用以完成各种具体功能的恶意脚本吗，被称为”XSS Payload”。
    • 构造GET和pOST请求
    • XSS钓鱼
    • 识别用户浏览器
    • 识别用户安装的软件
    • CSS History Hack （失效）
    • 获取用户的真实IP地址
      • javascript本身并没有提供获取本地IP地址的能力， 一般来说，XSS攻击需要借助第三方软件来完成。比如，客户端安装了Java环境（JRE），那么XSS就可以通过调用JavaApplet的接口来获取客户端的本地IP地址
      • Metasploit 引擎曾展示过一个强大的测试页面，综合了Java Applet、Flash、iTunes、Office Word、QuickTime等第三方软件的功能，抓取用户的本地信息。
    • Xss攻击平台
      • Attack API，它总结了很多能够直接使用XSS Payload归纳为API的方式。
      • BeFF，曾经是最好的XSS演示平台。BeFF所演示的是一个完整的XSS攻击过程。BeFF有一个控制后台，攻击者可以在后台控制前端的一切。
      • XSS-Proxy，是一个轻量级的XSS攻击平台，通过嵌套iframe的方式可以实时地远程控制被XSS攻击的浏览器
    • XSS worm
    • 调试javascript
      • firebug、IE 8 Developer Tools、Fiddler、HttpWatch

  • XSS构造技巧

    • 利用字符编码构造

    • 绕过长度限制

      • 利用location.hash可以绕过
      • 利用注释符绕过长度限制

    • 使用<base>标签

      <body>
<base href="http://www.google..com">
<img src="/intl/en_ALL/images/srpr/logolw.png">
</body>
      • <base>标签将指定其后的标签默认从"http://www.google.com"取
      • 需要特别注意的是，在有的技术文档中，提到<base>标签只能用于<head>标签之内，其实这是不对的，<base>标签可以出现页面的任何地方，并作用于位于该标签之后的所有标签。
      • 所以在设计XSS安全方案时，一定要过滤掉这个非常危险的标签

    • window.name的妙用

      • 对当前窗口的winodw.name对象复制，攻击者利用这个对象，可以实现跨域、跨页面传递数据。

            <script>
     window.name = "alert(docunment.cookie)"
     location.href="http://www.xssedsite.com/xssed.php
    </script>

      • 到新的窗口后执行eval(name)

  • XSS的防御

    • HttpOnly
      • HttpOnly标记的Cookie不能被浏览器读取。
      • 但是，HttpOnly不是万能的，添加了HttpOnly不等于解决了XSS问题
      • 使用HttpOnly有助于缓解XSS攻击，但仍然需要其他能够解决XSS漏洞的方案
    • 输入检查
      • XSS Filter
    • 输出检查
      • 安全的编码函数
    • 只需一种编码吗
    • 正确的防御XSS
      • 在HTML标签中输出，使用HtmlEncode
      • 在HTML属性中输出，使用HtmlEncode
      • 在<script>标签中输出，使用JavascriptEncode
      • 在事件中输出，使用JavascriptEncode
      • 在CSS中输出，尽量禁止用户可控制的变量在CSS中输出，如果必须，那么，使用OWASP ESAPI中的encodeForCSS()函数
      • 在地址中输出，可以用URLEncode，但是整个URL的时候，可以用OWASP ESAPI中的一个URLEncode实现（此API未解决为伪协议的问题）
      • 处理富文本，应该使用白名单，避免使用黑名单，还要进行专门的过滤
    • 防御DOM Based XSS
      • DOM Based XSS是一种比较特别的XSS漏洞，前文提到的几种防御方法都不太使用，需要特别对待。
      • DOM Based XSS是从javascript输出到HTML页面的，而不是从服务器应用直接输出到HTML页面的。
      • 首先，在输出到<script>时，应该执行一次JavascriptEncode，其次，在DOM输出到HTML页面的时候，要分具体情况看待，如果是输出到事件过着脚本，则要再做一次javascriptEncode,如果输出到HTML内容或着属性，则要做一次HtmlEncode。
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成，浏览时请结合常识与多方信息审慎甄别。
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

相关阅读更多精彩内容

友情链接更多精彩内容