跨站脚本（XSS）综合指南

当您访问网页或将鼠标悬停在某些特定文本时，您是否曾经用弹出窗口表示欢迎？想象一下，如果这些弹出窗口变成一种工具，从而将恶意负载传送到您的系统中，甚至捕获一些敏感信息。今天，在本文中，我们将参观跨站点脚本，并了解攻击者如何通过输入参数执行恶意 JavaScript 代码并生成此类弹出窗口，以破坏 Web 应用程序或劫持活动用户的会话。

动态 Web 应用程序基于三个支柱：定义其完整结构的 HTML，描述其外观的 CSS，以及添加强大功能（如警报、滚动效果和下拉菜单）的 JavaScript。

因此，JavaScript 是 Internet 上的基本编程语言，被认为是最流行的脚本语言之一，因为大约 93% 的网站都由 Javascript 提供支持。这是由于它的一些功能，例如：

容易学习。

它有助于构建交互式WEB应用程序。

是唯一可以被浏览器解释的编程语言，即浏览器运行它，而不是显示它。 

它是灵活的，它能够与 HTML 代码“混合”。

当 JavaScript 代码嵌入到 HTML 页面中时，此 JavaScript 会对某些特定事件做出“反应”，

例如：

当页面加载时，它是一个事件。

当用户点击一个按钮时，点击也是一个事件。

其他示例，例如 :  按任意键、关闭窗口、调整窗口大小等。因此，此类事件由某些事件处理程序管理。

Javascript 使用onload函数在网页上加载对象。

例如，我想为访问我网站的用户生成警报；我将给出以下 JavaScript 代码。

因此，无论何时加载 body 标签，都会弹出一条警告，内容为“Welcome to Hacking Articles”。这里body 标签的加载是一个“事件”或一个发生，“onload”是一个事件处理程序，它决定应该在该事件上发生什么动作。

使用 Onmouseover 事件处理程序，当用户将光标移到特定文本上时，嵌入的 javascript 代码将被执行。

例如，让我们理解以下代码：

现在，当用户将光标移动到页面上显示的 surprise 文本上时，会弹出一个带有 50% 折扣 的警告框。

同样，有许多 JavaScript 事件处理程序，它们定义了此类操作（例如向下滚动或图像加载失败等）应发生的事件。

跨站点脚本或 XSS(Cross-Site Scripting) 是一种客户端代码注入攻击，其中恶意脚本被注入受信任的网站。XSS 发生在那些未正确配置或验证输入参数的 Web 应用程序中，允许攻击者向另一个最终用户发送恶意 Javascript。最终用户的浏览器无法知道脚本不应该被信任，因此会执行它。

在这次攻击中，虽然攻击者通过将恶意脚本注入看似网站真实部分的网页来消除 XSS 漏洞，但用户并未通过有效载荷直接受到损害。因此，当任何用户访问该网站时，病态的 XSS 网页会在浏览器不知情的情况下直接向浏览器发送恶意 JavaScript。

不完全清楚发生了什么？现在是时候通过以下示例来阐明这一点了。

一个 Web 应用程序允许用户在他们的个人资料中设置“简短描述”，以便每个人都可以看到它。攻击者现在注意到描述字段没有正确验证输入，因此他将恶意脚本注入其中。

当访问者查看攻击者的个人资料时，浏览器会自动执行获取代码，它会获取经过身份验证的 cookie，另一方面，攻击者会获取活动的受害者会话。

从上次衰败开始，跨站脚本已经在 OWASP Top10 名单中占据了一席之地，因为它是互联网上最关键和最广泛使用的攻击方法之一。

因此，攻击者能够执行以下操作：

操作 Web 应用程序的结构

然而，据报道，XSS 的 CVSS 评分为 6.1，严重程度中等。

CWE-80：网页中与脚本相关的 HTML 标签无效（基本 XSS）

到目前为止，您可能对JavaScript和XSS的概念及其主要后果有一个清晰的认识。所以，让我们继续沿着同一条路走下去，将这个 XSS 分为三种主要类型：

存储型 XSS

反射型 XSS

DOM型 XSS

存储型 XSS也称为 持久型 XSS 或 Type I，因为该漏洞将注入的恶意脚本永久存储在 Web 应用程序的数据库服务器中，然后在用户访问相应网站时服务器将其重置。

当客户端单击或悬停在某个受感染部分时会发生这种情况。注入的 JavaScript 将被浏览器执行，就像它写入应用程序数据库一样，因此这种攻击不需要对用户执行任何网络钓鱼技术。

存储型 XSS 最常见的例子是博客上的“评论选项”，它允许任何用户提供反馈，作为给管理员或其他用户的消息。

是时候看看这样的例子了：

Web 应用程序要求用户提供反馈，因为其网页有两个输入字段，一个用于名称，另一个用于评论。

现在，当用户单击“提交”按钮时，他的记录将保存在数据库中。

为了让这个例子更清楚，这个人在屏幕上转储了数据库表，如下所示：在这种情况下，开发人员信任他的用户并且不会在字段中放置任何验证。于是，这个漏洞被攻击者发现了，所以他就利用了它，因为他没有提交评论，而是评论了他的恶意脚本。

从下面的屏幕截图中，您可以看到攻击者成功了，因为 Web 应用程序会弹出警报。

现在，回到数据库，您可以看到该表已更新为Name为“Ignite”，并且Feeback字段为空，这表明攻击者的脚本已成功注入。

因此，让我们以不同的用户身份切换到另一个浏览器，并再次尝试提交真实的反馈。

现在，当我们点击提交按钮时，我们的浏览器将执行注入的脚本并将其反映在屏幕上。

反射型 XSS ,也称为 非持久型 XSS 或Type II，当 Web 应用程序立即响应用户输入而不检查用户输入的内容时就会出现。这可能会导致攻击者将可执行的浏览器代码注入到单个 HTML 响应中。之所以称为“非持久性”，是因为恶意脚本未存储在 Web 服务器的数据库中，因此攻击者需要使用网络钓鱼发送恶意链接来诱骗用户。

反射型 XSS 是一种常见的做法，很容易在“网站搜索框”中找到，攻击者在搜索文本框中包含一些任意 Javascript，如果网站易受攻击，网页将返回脚本中描述的事件。

反射型 XSS 有两种类型：

反射型 XSS GET

反射型 XSS POST

为了更好地理解反射型 XSS 的概念，是时候考虑以下场景了。 此处创建了一个网页，从而允许用户搜索特定的培训课程。当一个人搜索“Bug Bounty”时，屏幕上会出现一条消息："You have searched for Bug Bounty."因此，这个即时响应和 URL 中的“搜索”参数表明，该页面可能容易受到 XSS 攻击，甚至数据已通过 GET 方法请求。

所以，现在让我们尝试通过将 Javascript 代码注入到这个“搜索”参数中来生成一些弹出窗口:

在下面的屏幕截图中，您可以看到用户收到了 欢迎消息。想知道为什么这一切会这样？需要检查以下代码。通过在屏幕上轻松显示消息，开发人员没有在 ignite 函数中设置任何输入验证，而只是将“搜索消息”的回显与 ignite ($search) 和变量“$_GET”一起留下。

基于 DOM 的跨站点脚本是出现在文档对​​象模型而不是 HTML 页面中的漏洞。但是这个文档对象模型是什么？

DOM 或文档对象模型描述了不同的网页片段，如标题、标题、表格、表单等，甚至是 HTML 页面的层次结构。因此，该 API 提高了开发人员生成和更改 HTML 和 XML 文档作为编程对象的技能。

当一个 HTML 文档被加载到 Web 浏览器中时，它就变成了一个“文档对象”。

然而，这个文档对象是 HTML 文档的根节点和所有其他节点的“所有者”。

通过对象模型，JavaScript 获得了创建动态 HTML 所需的全部功能:

JavaScript 可以修改页面上的所有 HTML 元素

JavaScript 能够更改所有 HTML 属性

JavaScript 可以更改页面上的 CSS 样式

JavaScript 能够删除现有的 HTML 元素和属性

JavaScript 可以添加新的 HTML 元素和属性

JavaScript 能够对页面上所有现有的 HTML 事件做出反应

JavaScript 可以创建新的 HTML 事件

因此DOM操作本身不是问题，但是当JavaScript在DOM中不安全地处理数据时，就会引发各种攻击。

基于 DOM 的 XSS 漏洞通常出现在 JavaScript 从攻击者可控制的来源（例如 URL）获取数据并将其传递给支持动态代码执行的接收器（危险的 JavaScript 函数或 DOM 对象 eval()）时。

这与反射型和存储型 XSS 完全不同，因为在这次攻击中，开发者在 HTML 源代码和 HTML 响应中都找不到恶意脚本，可以在执行时观察到。

基于DOM的XSS在用户本地计算机上利用这些漏洞如下：

攻击者创建恶意网站

用户打开它

他的电脑上有一个易受攻击的页面

攻击者的站点向易受攻击的 HTML 页面发送命令

易受攻击的本地页面在这台机器上使用用户权限运行这些命令

攻击者获得对受害者计算机的控制权

在实践中检查基于 DOM 的 XSS 执行也是值得的。

以下应用程序容易受到基于 DOM 的 XSS 攻击。Web 应用程序允许其用户选择具有以下选项的语言并通过特定 URL 执行数据输入。

在上面的屏幕截图中，您可以看到用户没有任何可以运行恶意代码的特定部分。因此，为了破环这个 Web 应用程序，我们现在将操纵“URL”，因为这是 DOM XSS 最常见的来源。

操作完 URL 后，按 Enter。现在，我们将再次选择语言，当我们启动选择按钮时，浏览器会执行 URL 中的代码并弹出 DOM XSS 警报。

基于 DOM 的 XSS 与反射型或存储型 XSS 之间的主要区别在于它不能被服务器端过滤器阻止，因为在“#”之后写入的任何内容都不会转发到服务器。

我相信你可能想知道“好吧，我们有弹出窗口，但现在怎么办？我们可以用它做什么？我将单击“确定”按钮，此弹出窗口就会消失。”

但是这个弹出窗口大约有一千个字。让我们掉头回到第一个弹出窗口的地方；是在存储区。

因此，正如我们现在意识到的那样，每当用户提交反馈时，它都会直接存储到服务器的数据库中。如果攻击者使用“警报消息”操纵反馈，那么即使是警报也会存储在其中，并且每次其他用户访问应用程序的网页时都会弹出。

但是，如果不是弹出窗口而是欢迎用户登录页面呢？

让我们尝试通过注入恶意负载来解决这个问题，该负载将在网页上创建一个虚假的用户登录表单，从而将捕获的请求转发到攻击者的 IP。

因此，让我们在 Web 应用程序的反馈字段中包含以下脚本

此恶意代码现已存储在 Web 应用程序的数据库中。在其他一些浏览器中，用户正在尝试提交他们的反馈。只要他点击提交按钮，浏览器就会运行脚本，用户收到一个带有登录表单的问候语：”Please login to continue!!“

在另一边，让我们启用我们的监听器

nc –lvp 4444

现在，当用户输入他们的凭据时，脚本将再次加载，输入的凭据将发送到攻击者的侦听器。

在下面的屏幕截图中，您可以看到受害者的凭据被成功劫持。Cookie捕捉

有时，攻击者需要登录用户的经过身份验证的cookie来访问他的帐户或出于其他恶意目的。

那么让我们看看这个 XSS 漏洞如何授权攻击者捕获会话 cookie 以及攻击者如何滥用它们以进入用户的帐户。

在浏览器中打开了易受攻击的 Web 应用程序“DVWA”，并使用 admin: password 登录。此外，在左侧面板中，将漏洞选择为 XSS（存储），这一次让我们将安全性保持在较低水平。

让我们在“消息”部分输入我们的恶意负载，但在此之前，我们需要增加文本区域的长度，因为它不足以注入我们的负载。因此，通过按“Ctrl + I”打开检查元素选项卡以查看文本区域的给定消息长度，然后将消息最大长度字段从 50 -150 进一步更改。

在下面的屏幕截图中，可以看到已经注入了脚本，该脚本将捕获 cookie，并在任何用户访问此页面时将响应发送到我们的侦听器。

现在，在另一边，让我们像这样设置我们的 Netcat 侦听器:

nc –lvp 4444

注销并以新用户或其他浏览器的身份再次登录，现在如果用户访问XSS（存储）页面，他的会话 cookie 将因此被传输到我们的侦听器。

从下面的屏幕截图中您可以看到，我们已经成功捕获了经过身份验证的 cookie。

但是我们能用它们做什么呢？

让我们试着进入他的账户。我再次打开了 DVWA，但这一次，我们不会登录，而是使用捕获的 cookie。我使用了 cookie 编辑器插件来操纵会话。

从下面的截图中可以看出，我将PHPSESID更改为我捕获的PHPSESID，并将安全性从不可能变低，甚至将安全性_level从1降低到0，从而保存了这些更改。让我们甚至通过删除 login.php 来操作 URL。

现在只需重新加载页面，从屏幕截图中您可以看到我们正在进入应用程序。

存储型 XSS 很难找到，但反射型 XSS 非常常见，因此可以通过一些简单的点击来利用。

但是到目前为止，我们只利用了未经开发人员验证的 Web 应用程序，那么受限制的应用程序呢？

带有输入字段的 Web 应用程序在某个地方或其他地方容易受到 XSS 攻击，但我们不能赤手空拳地利用它们，因为它们已通过一些验证进行保护。因此，为了利用这些经过验证的应用程序，我们需要一些模糊测试工具，因此对于模糊测试，我们可以依靠 BurpSuite。

在浏览器中打开目标 IP 并以 bee: bug 的身份登录 BWAPP，此外将“Choose Your Bug”选项设置为“XSS –Reflected (Post)”并启动了 hack 按钮，这里已将安全性设置为“中”。

在下面的屏幕截图中，可以看到当用户尝试将有效负载作为 警告执行时，没有得到预期的结果。

因此，让我们在 burpsuite 中捕获其正在进行的 HTTP 请求，并将捕获的请求进一步共享给“入侵者”。

进入入侵者，切换到 Position 选项，我们将使用 Add $ 按钮将输入值参数的位置配置为“firstname”。

是时候切换到Payloads选项。单击 load按钮以添加字典。甚至可以选择 burpsuite 的预定义 XSS 字典，只需单击“Add from list”按钮并选择 Fuzzing-XSS。

完成配置后，我们将启动“Start attack”按钮。

从下图可以看出我们的攻击已经开始，长度部分出现了波动。为了按长度降序获得结果，我双击了Length字段。

快完成了，让我们双击有效负载来检查它提供了什么。

可是！！我们无法在 response选项中看到 XSS 结果，因为浏览器只能渲染此恶意代码，因此为了检查其响应，我们只需右键单击并选择 “Show response in browser” 选项

复制提供的 URL 并将其粘贴到浏览器中。

从下图中，您可以看到我们在收到警报时已成功绕过该应用程序。

跨站点“Scripter”或“XSSer”是一个自动框架，它可以检测 Web 应用程序中的 XSS 漏洞，甚至提供多种利用它们的选项。

XSSer 预装了 1300 多个 XSS 模糊测试向量，从而使攻击者能够绕过肯定过滤的 Web 应用程序和 WAF（Web – 应用程序防火墙）。

那么，让我们看看这个模糊器如何帮助我们利用我们的 bWAPP 的网络应用程序。但是为了继续，我们需要将 XSSer 克隆到我们的 kali 中，所以让我们这样做

git clone https://github.com/epsylon/xsser.git

现在，重新启动 bWAPP，并将“Choose your Bug”选项设置为“XSS –Reflected (Get)”并点击 hack 按钮，这次我们将安全级别设置为“中等”。

XSSer 提供两个平台：图形界面和命令行。

在这里，重点介绍命令行方法。

由于 XSS 漏洞依赖于输入参数，因此 XSSer 作用于“URL”；并且您还需要 cookie 才能获得准确的结果。为了捕获它们，用户将第一个名称设置为“test”，将最后一个名称设置为“test1”。

现在，让我们将浏览器的请求捕获到我们的 burpsuite 中，通过简单地启用代理和拦截选项，然后当我们点击 Go按钮时，我们得到:

用 XSSer 启动 Kali 终端，并使用 –url 和 –cookie 标志运行以下命令。在这里，甚至用了一个 –auto 标志，它将检查带有所有预加载向量的 URL。在应用程序 URL 上，我们需要将输入参数值操作为“XSS”，因为在这个的例子中，将“test”更改为“XSS”。

从下面的屏幕截图中，可以看到该 URL 存在 1287 个向量。

这个 模糊器 最好的地方是它提供了浏览器 url。

注：没有必要在每个有效负载中都收到弹出警报，因为其他所有有效负载都由某些特定事件决定，无论是设置 iframe、抓取一些 cookie 还是重定向到其他网站或是其他东西。

从下面的屏幕截图中，很明显我们已经成功地破坏了这个 Web 应用程序。

开发人员应实现允许输入的白名单，如果不可能，则应该进行一些输入验证，并且必须尽可能过滤用户输入的数据。

输出编码是处理 XSS 最可靠的解决方案，即它需要用脚本代码并将其转换为纯文本。

应实施 WAF 或 Web 应用程序防火墙，因为它可以在某处保护应用程序免受 XSS 攻击。

在 Cookie 上使用 HTTPOnly 标志。

开发人员可以使用内容安全策略 (CSP) 来降低 XSS 漏洞。