51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 3011|回复: 0
打印 上一主题 下一主题

[原创] 聊一聊(XSS)跨站脚本攻击

[复制链接]
  • TA的每日心情
    无聊
    11 小时前
  • 签到天数: 935 天

    连续签到: 2 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2021-4-28 13:57:44 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    跨站脚本攻击(XSS)是一种将恶意脚本注入到可信任网站中的一种攻击方式。在XSS攻击中,攻击者利用web应用程序将恶意代码发送至终端用户。这些恶意脚本通常经由浏览器端形式呈现, 恶意攻击者往web页面里插入恶意Script代码,当用户浏览该页面时,嵌入web页面中的Script代码就会被执行,这样即可达到恶意攻击用户的目的。

      【概述】
      在[url=]互联网[/url]中,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]"margin-right: auto; margin-left: auto; font-family: 微软雅黑; line-height: 24px; color: rgb(62, 62, 62);">

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


      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)漏洞以及常见测试方法,应用场景进行详细剖析,对于软件测试从业者而言,无论是否身兼安全/渗透测试一职,都需对基本的安全漏洞有宏观的认知,希望本次分享能够给各位带来收获,持续完善你的测试知识库。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-4-23 20:25 , Processed in 0.072817 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表