聊一聊(XSS)跨站脚本攻击

lsekfe

跨站脚本攻击（XSS）是一种将恶意脚本注入到可信任网站中的一种攻击方式。在XSS攻击中，攻击者利用web应用程序将恶意代码发送至终端用户。这些恶意脚本通常经由浏览器端形式呈现， 恶意攻击者往web页面里插入恶意Script代码，当用户浏览该页面时，嵌入web页面中的Script代码就会被执行，这样即可达到恶意攻击用户的目的。

　　【概述】
　　在互联网中，XSS几乎到处可见，例如：当应用程序接受用户输入时，这些内容在未经验证或编码的情况下，就直接经由web应用程序生成相应的输出。XSS漏洞借助于php输出函数，将javascript代码输出到html页面中，再通过用户本地浏览器执行，所以在代码审核中，查找XSS漏洞的关键就在于找到那些入参未经过滤的输出函数。
　　攻击者利用XSS将恶意脚本发送给毫无戒心的大众用户，浏览器端用户们在不知情的情况下执行了这些不受信任的恶意脚本，从而泄漏了自己在浏览器端保留个人隐私身份验证等相关状态信息（如：与该站点相关的cookie、session、token以及其他敏感信息）。此外，攻击者的恶意脚本甚至还可以重写HTML页面内容。

　　【XSS分类】
　　反射型XSS：＜非持久化＞
　　攻击者事先制作好恶意链接，需要用户自己去点击链接才能触发XSS代码（这些代码不会被保存至服务端）。

　　存储型XSS：＜持久化＞添加线程组
　　恶意代码存储在服务器中,如攻击者在个人信息或发表文章等页面中加入恶意脚本；在接受输入参数时，如果没有对这些入参进行过滤或过滤不严谨，那么页面中的恶意代码将存储到服务器中，一旦有用户访问该页面时，就会触发恶意代码。这种XSS非常危险，容易造成蠕虫（会大量盗窃用户cookie信息）。

　　【反射型XSS详解】
　　当攻击者在单个HTTP响应中注入浏览器可执行的代码，这时就会发生反射型跨站脚本攻击（Reflected_XSS）。由于这类注入攻击不会驻留在应用程序本身，所以它是一种非持久性注入，仅对于那些打开恶意链接（刻意制作的）或第三方页面的用户造成影响。这些带有攻击性的恶意字符串包含在攻击者精心设计的URL或HTTP参数中，被存在安全隐患的应用程序处理后，将结果返回给用户（受害者/被攻击者）。
　　反射型跨站脚本攻击（Reflected_XSS）是XSS攻击中最常见的类型，这类攻击也称非持久型XSS攻击，因为此类攻击的载体源于单个请求，通过响应将返回结果传递给客户端浏览器，然后被用户执行，从而触发Reflected_XSS（Reflected_XSS也称一阶XSS，即XSS的第一种类型）。
　　一个易受到Reflected_XSS攻击的web应用程序，会将请求中未经验证的输入通过响应直接回传给客户端。常见的攻击手段/途径有：精心设计步骤（攻击者创建问题URI），社会工程相关（试图说服受害者将其URL加载到他们的浏览器上），最终攻击者就能通过受害者的浏览器来执行问题代码。
　　从前文可知，攻击者的代码大多都用JavaScript语言编写，当然也可以是其他脚本语言，例如ActionScript，VBScript等。攻击者通常利用web应用程序漏洞来安装密钥日志，窃取受害者的Cookie，进行剪贴板盗窃，以及更改页面内容（例如添加下载链接等）。
　　预防XSS漏洞的主要困难之一是如何设置合适的字符编码进行参数过滤。在某些情况下，Web服务器或Web应用程序可能无法过滤一些特殊的字符编码，例如Web应用程序可能会过滤掉<script>，但也许不会过滤 ”%3cscript%3e“。

　　【反射型XSS测试方法】
　　(1)黑盒测试
　　黑盒测试包含三个阶段：

　　检测输入
　　针对web应用程序中每个页面上的用户自定义输入，测试人员必须确定其输入形式，包括隐藏（hidden），或者非显式的输入，如：HTTP参数、POST数据、表单中的隐藏字段以及预定义的单选（radio）或下拉选框（selection）中的值。 这些隐藏变量可以通过浏览器内置HTML编辑器或是web代理来查看。

　　分析输入
　　分析页面上每一项用户输入以检测潜在漏洞。为了发现XSS漏洞，测试人员通常会将“定制化”数据作为输入框的测试数据，这类测试数据不会对应用程序造成损害，其目的只是用于触发来自浏览器的响应，从而验证漏洞是否存在。测试数据可以通过[web application fuzzer]自动生成或手动构造，例如：

　　更多有关潜在测试字符串的完整列表，参见https://owasp.org/www-community/xss-filter-evasion-cheatsheet。

　　检查影响
　　对于以上所有测试数据，测试人员需要关注并分析其提交后的响应结果，从而确定每条数据是否对web应用程序安全性造成实际影响（漏洞的存在）。一旦发现漏洞，测试人员需要识别出漏洞存在的原因，例如：应用程序未对输入数据采取合适编码，应用程序对某些特殊字符没有进行过滤或替换等。
　　理想情况下，所有HTML的特殊字符都要替换成HTML实体：

　　更多HTML实体规则可以参见：https://www.w3school.com.cn/tags/html_ref_entities.html
　　在HTML或JavaScript代码上下文中，特殊字符需要转义，编码，替换或过滤，这些字符包括：

　　更多完整参考，请参见[Mozilla JavaScript指南]：
　　https://developer.mozilla.org/en ... aracters_in_strings

　　Example 1
　　有如下站点自带welcome提示及下载链接：

　　测试人员本着怀疑每个数据输入点都可能导致XSS攻击的原则，对其进行分析后，尝试以下测试数据：

　　如果出现如下弹出框，则说明存在一个XSS漏洞，并且这个链接可以在任何浏览器中执行。

　　Example 2
　　除了在URL中提交植入的 JS alert弹框外，还可以有如下尝试：

　　从URL附带的提交数据中可以发现，测试人员（模仿攻击者）改变了当前页面中的超链接资源，将链接引导到一个恶意的可执行文件，只要这个超链接被用户点击，就会在本地自动下载恶意文件“malicious.exe”：

　　值得一提的Bypass XSS Filters
　　当web应用程序启用防火墙阻止恶意输入，或通过web浏览器中自带的内嵌机制，清理应用程序的外来输入时，反射型跨站脚本攻击（Reflected_XSS）是可以防止的。
　　但在测试的时候，测试人员必须假定web浏览器是不具备阻止攻击的机制，且客户端也未开启防火墙，这是因为在一些过时的浏览器中，相关过滤机制内置的安全防范功能已经被禁用了。同样的道理，我们也不能保证即便客户端防火墙开启后，web应用程序能够识别“与时俱进”的未知攻击，网络攻击者往往紧跟时代步伐，制作出web应用程序防火墙无法识别的攻击性字符串。
　　大多数XSS预防取决于Web应用程序对“不可信用户”输入的清理。开发人员可以通过多种机对“问题输入”进行净化，例如返回错误，删除，编码或替换无效输入。

　　Example 3：Bypass XSS Filters —— 仅通过标签属性值
　　虽然Bypass XSS Filters基于黑名单，但并不能阻止每种类型的字符串表达式。在实际情况下，甚至于不需要依赖<script>标签就能发起XSS攻击。例如页面中有如下input输入框：

　　攻击者可以直接在该输入框中提交以下代码：
[table=98%,rgb(221, 221, 221)]
[tr][td]"text-align: center;">

　　Example 5：Bypass XSS Filters —— 绕过非递归机制的过滤
　　有时过滤器的清理仅应用一次，不会递归执行。在这种情况下，攻击者可以通过发送包含多次尝试的字符串来击败多滤器，例如：

　　Example 6：Bypass XSS Filters —— 包含外部脚本
　　假设目标站点的开发人员实现了以下代码，用来保护输入内容免受外部脚本的影响。

　　以上代码中的正则表达式： $re = "/<script>+src/i"
　　用来检查是否存在这样的插入：<script [anything but the character: '>'] src
　　这种判断仅针对于过滤类似于如下常见攻击有效。

　　但可以在script和src中间的某个属性利用”>“字符进行绕过， 从而发起reflected-XSS攻击，不知不觉中让用户执行了攻击者web服务器上存储的javascript代码，例如：

　　可以看出这里利用了reflected-XSS漏洞，执行了javascript代码，这些代码看似来自受害网站http://example/， 实际上是存储在攻击者的Web服务器上。

　　（2）灰盒测试
　　这里的灰盒测试有点类似黑盒测试，但需要测试人员对应用程序有一定的了解，例如用户可能的输入，输入的验证机制，输入提交后的返回信息，以及返回信息呈现给用户的方式。如果测试人员有权限可以查看源代码（白盒测试），那么还需要对每个用户变量进行深入分析，此处已涉及更多白盒测试相关领域，暂不进行拓展。

　　【总结】
　　文章介绍了Cross Site Scripting (XSS) 跨站脚本及其分类展开介绍，其中针对反射型XSS（reflected-XSS）漏洞以及常见测试方法，应用场景进行详细剖析，对于软件测试从业者而言，无论是否身兼安全/渗透测试一职，都需对基本的安全漏洞有宏观的认知，希望本次分享能够给各位带来收获，持续完善你的测试知识库。

Miss_love