8月27日 | 英语翻译 | 凶狠的Refectived-XSS 反射式XSS

目录选择：

前言：xss原来厉害起来这么凶！
今天早上效率也是低于20%的一天，重新开始，不要积压，15天就快结束啦。

翻译1：

Most books and educational resources teach reflected XSS before introducing stored
XSS. I believe reflected XSS attacks are often much more difficult for newly minted
hackers to find and take advantage of than stored XSS attacks.

大多数书籍和教育资源在介绍存储之前都会介绍反映XSS
XSS。我相信反射类型跨站攻击对于新手来说通常要困难得多发现并利用比存储的XSS攻击。

翻译2:

A stored XSS attack is very simple to understand from a developer’s point of view.
The client sends a resource to the server, typically over HTTP. The server updates a
database with the resource received from the client. Later on, that resource may be
accessed by other users, in which case the malicious script will execute unknowingly
inside of the requester’s internet browser.

从开发人员的角度来看，很容易理解存储的XSS攻击。
客户端向服务器发送资源，通常是通过HTTP。服务器更新
使用从客户端接收到的资源创建数据库。稍后，这个资源可能会是
被其他用户访问，在这种情况下，恶意脚本将不知不觉地执行
在请求者的Internet浏览器内部。

翻译3:

Reflected XSS attacks, on the other hand, operate identically to stored XSS attacks but
are not stored in a database, nor should they regularly hit a server. A reflected XSS
affects the code of the client in the browser directly without relying on a server to
relay a message to be rendered with a script to be executed (see Figure 10-2).

另一方面，反射类型跨站攻击的操作与存储式跨站攻击相同，但是不存储在数据库中，也不应该定期命中服务器。一个Refective-XSS直接影响浏览器中的客户机代码，而不依赖于服务器用一个要执行的脚本来呈现的消息(参见图10-2)。

翻译4：

As a result of not being stored on the server, reflected XSS can be a bit hard to under‐
stand compared to stored XSS. Let’s start out with an example.
We are once again a customer of a fictional bank with a web application located at
mega-bank.com. This time, we are trying to look up support documentation for how
to open a new savings account to complement our existing checking account. Fortu‐
nately, mega-bank.com’s support portal, support.mega-bank.com, has a search bar we
can use to look up common support requests and their solutions.

由于没有存储在服务器上，与存储的XSS相比，反射XSS可能有点难以理解。让我们从一个例子开始。
我们又再一家虚拟银行的客户，该银行的web应用程序位于
mega-bank.com。这一次，我们试图查找支持文档来了解如何操作
开一个新的储蓄帐户来补充我们现有的支票帐户。Fortu量
Nately, mega-bank.com的支持门户网站support.mega-bank.com有一个搜索栏，我们
可以用来查找常见的支持请求及其解决方案。

关键词：搜索条

We are once again a customer of a fictional bank with a web application located at
mega-bank.com. This time, we are trying to look up support documentation for how
to open a new savings account to complement our existing checking account. Fortu‐
nately, mega-bank.com’s support portal, support.mega-bank.com, has a search bar we
can use to look up common support requests and their solutions.

我们曾经是一家虚拟银行的客户，该银行的web应用程序位于mega-bank.com。这一次，我们试图查找支持文档来了解如何操作开一个新的储蓄帐户来补充我们现有的支票帐户。幸运的是，mega-bank.com的支持门户网站support.mega-bank.com有一个搜索栏，我们可以用它来查找常见的支持请求及其解决方案。

翻译5：

The first thing we try is a search for “open savings account.” This search redirects us to a new URL at support.mega-bank.com/search?query=open+savings+account. On this search results page we see the heading: 3 results for “open savings account.”


我们尝试的第一件事是搜索“开放储蓄账户”。这次搜索改变了我们的方向到
support.mega-bank.com/search?query=open+savings+account
的新URL。在在这个搜索结果页面我们看到3个标题为“开通储蓄帐户”的结果

观测他：

Next we try adjusting the URL to support.mega-bank.com/search?query=open+check‐
ing+account. The heading on the results page now becomes: 4 results for “open
checking account.”
From this we can gather that there is a correlation between the URL query params
and the heading displayed on the results page.

接下来，我们尝试将URL调整为support.mega-bank.com/search?query=open+check‐
ing + account。结果页面上的标题现在变成了:“打开”的4个结果开通
支票账户。”
由此我们可以推断URL查询参数之间存在相关性
以及显示在结果页面上的标题。

联想他：

Since we remember finding a stored XSS vulnerability in the support form by includ‐
ing a <strong></strong> tag inside of our comment, let’s try to add a bold tag to the
search query: support.mega-bank.com/search?query=open+<strong>checking</strong>
+account.

因为我们记得通过包含<strong></strong>的标签形式找到了一个存储的XSS漏洞
在我们的注释中加入一个<strong></strong>标签，让我们试着
搜索查询:support.mega-bank.com/search?query=open+<strong>checking</strong>
+account。

发现他：

To our surprise, the new URL we generated does indeed bold the heading present
within the results page. Using this newfound knowledge, let’s include a script tag in the query params: support.mega-bank.com/search?query=open+<script>alert(test);</
script>checking+account.Using this newfound knowledge, let’s include a script tag in the query params:support.mega-bank.com/search?query=open+<script>alert(test);</
script>checking+account.

让我们惊讶的是，在结果页面中我们生成的新URL确实将标题加粗了。使用这个新发现的知识，让我们在查询参数中包括一个script标签:support.mega-bank.com/search?query=open+<script>alert(test);</
script>checking+account.
打开这个URL会加载搜索结果，但最初会弹出一个警告模式
里面有"test"这个词。

为什么叫反射式：

What we have found here is an XSS vulnerability—only this time it will not be stored
in the server. Instead, the server will read it and send it back to the client. These types
of vulnerabilities are called “reflected XSS.”

我们在这里发现的是一个XSS漏洞——只是这次它不会被存储在服务器。相反，服务器将读取它并将其发送回客户机。这些类型
的漏洞被称为“反射XSS”。

为什么不容易被发现：

Previously we discussed the risks of stored XSS, and mentioned that it can be very
easy to hit many users with a stored XSS. But we also mentioned that a downside of
stored XSS is that these attacks can be easily found as they are stored server-side.
Reflected XSS is much more difficult to detect since these attacks often target a user
directly and are never stored in a database. In our example, we could craft a malicious
link payload and send it to the user we wish to attack directly. This could be done via
email, web-based advertisements, or many other ways.

之前我们讨论了存储XSS的风险，并提到它可能非常
很容易用存储的XSS攻击许多用户。但我们也提到了
存储的XSS是这些攻击很容易发现，因为它们存储在服务器端。
反射式XSS更难以检测，因为这些攻击通常以用户为目标
直接，并且从不存储在数据库中。在我们的例子中，我们可以制造一个恶意的
链接有效载荷，并将其发送给我们希望直接攻击的用户。这可以通过
电子邮件，网络广告，或许多其他方式。

实战：

Furthermore, the reflected XSS we discussed previously could easily be disguised as a
valid link. Let’s take this HTML snippet as an example:
Welcome to MegaBank Fans!
Your #1 source for legit MegaBank support info and links.
<a href="https://mega-bank.com/signup">Become a New Customer</a>
<a href="https://mega-bank.com/promos">See Promotional Offers</a>
<a href="https://support.mega-bank.com/search?query=open+
 <script>alert('test');</script>checking+account">
 Create a New Checking Account</a>

此外，我们前面讨论的反射XSS很容易伪装成
有效的链接。让我们以这个HTML片段为例:
Welcome to MegaBank Fans!
Your #1 source for legit MegaBank support info and links.
<a href="https://mega-bank.com/signup">Become a New Customer</a>
<a href="https://mega-bank.com/promos">See Promotional Offers</a>
<a href="https://support.mega-bank.com/search?query=open+
 <script>alert('test');</script>checking+account">
 Create a New Checking Account</a>

伤害：

Here we have three links, all of which have custom text. Two are legitimate. Clicking
the last link with the text “Create a New Checking Account” would take you to the
support pages. The alert() would suggest that something funny was happening, but
just like with the earlier stored XSS example, we could easily execute some code
behind the scenes. Perhaps we could find enough customer information to imperso‐
nate the user, or get a checking/routing number if it is present in the support portal
UI.

这里我们有三个链接，它们都有自定义文本。两个都是合法的。点击
最后一个带有文本“创建一个新的支票帐户”的链接会把你带到
支持页面。alert()会提示发生了一些有趣的事情，但是
就像前面存储的XSS示例一样，我们可以轻松地执行一些代码
在幕后。
也许我们可以找到足够多的客户信息来模拟用户，或者获得一个检查/路由号(如果它存在于支持门户UI中)。

优点：

This reflected XSS relies on a URL that makes it quite easy for an attacker to distribute. Most reflected XSS will not be this easy to distribute and might require the end
user take additional actions like pasting JavaScript into a web form.
It’s safe to say that as a general rule, reflected XSS is much better at avoiding detec‐
tion, but generally harder to distribute to a wide number of users.

这反映反射XSS依赖于一个URL，这使得攻击者很容易发布它。大多数反映出来的XSS不会这么容易发布，可能需要结束
用户采取额外的行动，如粘贴JavaScript到web表单。
可以肯定地说，作为一般规则下的情况，反射式XSS在避免检测方面要好得多，但通常很难分发给大量用户。

激发点：

微信任何可以输入的地方
QQ邮箱任何可以输入的地方
百度任何可以输入的地方
观察任何URL与输入点击的关系：只要能执行输入就行。
就是要任何输入：文件，图片，文字，等等都会在URL显现出来，不需要数据库。