• 12
  • 12
分享
  • 聊一聊(XSS)跨站脚本攻击——软件测试圈
  • 曼倩诙谐 2021-05-11 09:54:31 字数 4183 阅读 1234 收藏 12

  跨站脚本攻击(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]自动生成或手动构造,例如:

1.png

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

  检查影响

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

  理想情况下,所有HTML的特殊字符都要替换成HTML实体:

1-1.png

  更多HTML实体规则可以参见:https://www.w3school.com.cn/tags/html_ref_entities.html

  在HTML或JavaScript代码上下文中,特殊字符需要转义,编码,替换或过滤,这些字符包括:

1-2.png

  更多完整参考,请参见[Mozilla JavaScript指南]:

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#Using_special_characters_in_strings

  Example 1

  有如下站点自带welcome提示及下载链接:

1-3.png

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

1-4.png

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

1-5.png

  Example 2

  除了在URL中提交植入的 JS alert弹框外,还可以有如下尝试:

1-6.png

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

1-7.png

  值得一提的Bypass XSS Filters

  当web应用程序启用防火墙阻止恶意输入,或通过web浏览器中自带的内嵌机制,清理应用程序的外来输入时,反射型跨站脚本攻击(Reflected_XSS)是可以防止的。

  但在测试的时候,测试人员必须假定web浏览器是不具备阻止攻击的机制,且客户端也未开启防火墙,这是因为在一些过时的浏览器中,相关过滤机制内置的安全防范功能已经被禁用了。同样的道理,我们也不能保证即便客户端防火墙开启后,web应用程序能够识别“与时俱进”的未知攻击,网络攻击者往往紧跟时代步伐,制作出web应用程序防火墙无法识别的攻击性字符串。

  大多数XSS预防取决于Web应用程序对“不可信用户”输入的清理。开发人员可以通过多种机对“问题输入”进行净化,例如返回错误,删除,编码或替换无效输入。

  Example 3:Bypass XSS Filters —— 仅通过标签属性值

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

1-8.png

  攻击者可以直接在该输入框中提交以下代码:

" onfocus="alert(document.cookie)

  Example 4:Bypass XSS Filters —— 通过编码植入未知变体

  在某些情况下,可以通过混淆攻击来简单地破坏基于签名的过滤器。通常,攻击者可以通过在语法或后续编码中插入未知变体(如下实例)来实现此目的。当返回时,浏览器会将这些变体视为有效的HTML内容。

1-9.png

  Example 5:Bypass XSS Filters —— 绕过非递归机制的过滤

  有时过滤器的清理仅应用一次,不会递归执行。在这种情况下,攻击者可以通过发送包含多次尝试的字符串来击败多滤器,例如:

1-10.png

  Example 6:Bypass XSS Filters —— 包含外部脚本

  假设目标站点的开发人员实现了以下代码,用来保护输入内容免受外部脚本的影响。

1-11.png

  以上代码中的正则表达式: $re = "/<script>+src/i" 

  用来检查是否存在这样的插入:<script [anything but the character: '>'] src

  这种判断仅针对于过滤类似于如下常见攻击有效。

1-12.png

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

1-13.png

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

  (2)灰盒测试

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

  【总结】

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


作者:罗狮小钉   

来源:51Testing软件测试网原创

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   据分析师郭明錤(Ming-Chi Kuo)称,苹果计划为 2 月 2 日发布的 Vision Pro 生产 60000 至 80000 台。由于初期出货量较小,他认为 Vision Pro 将"在发布后很快售罄"。  郭明錤认为,虽然苹果尚未确定 Vision Pro 的主要应用,而且价格较高,但"突破性的技术创新"和苹果的"核心粉丝和重度用户群"将使该设备供不应求。  本周早些时候他也发表了类似的看法,他说,对这款头显的需求将导致其在预购期间售罄,而且他认为,在上市初期之后,发货延迟的时间会很长。由于生产的复杂性,预计 2024...
            0 0 773
            分享
          • 前言接口自动化逐渐成为各大公司投入产出最高的测试技术。但是如何在版本迅速迭代过程中提高接口自动化的测试效率,仍然是大部分公司需要解决的问题。框架定位数据驱动设计模式,无需写测试代码脚本即可实现自动化;等价类非等价类覆盖, E2E(接口流程性测试) Case 覆盖;使用 Excel 的方式进行自动化用例编写,简单,易用,高效。框架架构图框架介绍技术栈Jenkins + Svn + Maven+TestNG+ReportNG+(HttpClien+URLConnection)Case 展示1、单个接口 CaseJson response 解析用的是 Json...
            0 0 701
            分享
          • 在接口测试的工作中我们一般首先面对的时登录操作,由于部分系统出于对安全性的考虑,登录做的都比较复杂如:参数加密传输;需要输入验证码;需要进行ToKen等。面对这里都是让我们接口测试时比较头疼的,那我们就先从易到难说下去。1、常规登录:首先我们要建一个HTTP请求默认值,将公共用到的协议,服务器或ip,端口进行录入如:然后新建一个线程组,在线程组中我们建一个cookie管理器(不需要任何设置),这个的作用就是将下面登录的获得cookie共享给整个线程(如需共享给整个计划,将cookie管理器放置到线程组同级即可)。最后我们就可以做接口请求了:新建一个HTTP请求这里需要填入:方法post;路径/...
            0 0 1287
            分享
          •   故事点是敏捷项目管理和开发中的一种抽象的度量单位,用于估计实现一个或多个用户故事的复杂度,它是对工作量的一种描述方式。一个故事点就是一个数字,透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。  故事点(story point)和预估时间(estimated)不一样,故事点是一种相对的估计,它并不能和类似“人/天”这样的单位画等号,因为每个人完成同样复杂度的工作所需的时间是不同的。我们举个例子说明一下:  假设T团队有A、B、C三位员工,A君的能力是B君的2倍,B君的能力是C君的2倍(能力是不能这样对比的,这里只是方便说明问题),T团队约定10天为一个...
            0 0 1540
            分享
          •   在利用Jmeter工具进行性能或自动化测试工作之初,第一步面临的交易想必就是登录。你可以运用控制器录制登录交易的脚本,或是通过自行配置环境、上送正确的用户名和密码完成登录操作,但这就算完成登录交易了么?事实是在继续配置后续交易之后,当你重复执行脚本时会发现,只有登录本身成功了,后续交易却报错。  产生这样的原因往往是当利用Jmeter首次录制登录交易后,此时有一个叫做token的值便作为固定参数存储在脚本中,而后置交易需依赖这个“令牌”而被系统所识别,而再次登录时,可能会返回不同的token,致使后续交易使用未匹配的token发给服务器,导致交易失败。  为解决这个问题,不得不分析toke...
            13 12 2138
            分享
      • 51testing软件测试圈微信