8月30日 | 英语翻译 | DOM-XSS 文档对象模型基本跨站

DOM-XSS

---

一个特别大的优点就是：

这本书内容非常全面，体系非常完整，给人很舒服很靠谱的感觉。

同时给我的启发是每一篇都适合写文章，给人原创的感觉，有体系的感觉，感觉自己肯定会学完。和单独的PPT相比，两者优势都非常巨大，对我来说，启示很大，想想我以前为找不到题材而苦难无奈得很呢。

翻译1：

The final major categorization for XSS attacks is DOM-based XSS, illustrated in
Figure 10-3. DOM XSS can be either reflected or stored, but makes use of browser
DOM sinks and sources for execution. Due to differences in browser DOM imple‐
mentation, some browsers might be vulnerable while others are not. These XSS
attacks are much more difficult to find and take advantage of than traditional reflec‐
ted or stored XSS, as they require deep knowledge of the browser DOM and
JavaScript.

XSS攻击的最后一个主要类别是基于DOM的XSS，如
图10-3。DOM XSS可以被反映或存储，但利用浏览器
用于执行的DOM接收器和源。由于浏览器DOM实现的差异
心理状态，一些浏览器可能容易受到攻击，而另一些则不会。这些XSS
与传统的反射相比，发现和利用攻击要困难得多
ted或stored XSS，因为它们需要对浏览器DOM和
JavaScript。

翻译2:

The major difference between for DOM XSS and other forms of XSS is that DOM-
based XSS attacks never require any interaction with a server. As a result, there is a
movement to start categorizing DOM XSS as a subset of a new category called client-
side XSS.

大XSS森林和其他XSS形式的主要区别在于
基于XSS的攻击从不需要与服务器进行任何交互。因此，有一个
开始将多姆XSS归类为一个新类别的子集，这个新类别叫做客户端
XSS这边。

特殊的

翻译3：

Because DOM XSS doesn’t require a server to function, both a “source” and a “sink”
must be present in the browser DOM. Generally, the source is a DOM object capable
of storing text, and the sink is a DOM API capable of executing a script stored as text.
Because DOM XSS never touches a server, it is nearly impossible to detect with static
analysis tools or any other type of popular scanner.

因为DOM-XSS不需要一个服务器来运行，无论是“源”还是“接收器”
必须存在于浏览器DOM中。通常，源是支持DOM对象的
接收器是一个DOM API，能够执行存储为文本的脚本。
因为多姆·XSS从不接触服务器，所以几乎不可能检测到静电干扰
分析工具或任何其他类型的流行扫描仪。

不可检测的

翻译4：

DOM XSS is also difficult to deal with because of the number of different browsers
there are in use today. It is very possible that a bug in a DOM implementation
shipped by one browser would not be present in the DOM implementation shipped
by another browser.
The same can be said for browser versions. A browser version from 2015 might be
vulnerable, while a modern browser might not. A company that attempts to support
many browsers could have difficulty reproducing a DOM XSS attack if not enough
details regarding the browser/OS are given. Both JavaScript and the DOM are built
on open specs (TC39 and WhatWG), but the implementation of each browser differs
significantly and often differs from device to device.

由于不同浏览器的数量，DOM XSS也很难处理
今天仍在使用。很有可能是DOM实现中的一个错误
由一个浏览器发布的不会出现在发布的DOM实现中
另一个浏览器。
浏览器版本也是如此。2015年的浏览器版本可能是
易受攻击，而现代浏览器可能不会。一家试图支持
如果不够充分，许多浏览器可能很难再现多姆XSS攻击
给出了关于浏览器/操作系统的细节。JavaScript和DOM都是构建好的
在开放规范(TC39和WhatWG)上，但是每个浏览器的实现是不同的
设备与设备之间存在显著且经常的差异。

浏览器异构性

难以解决性

版本不同难检测性

翻译5：

Without further ado, let’s examine a mega-bank.com DOM XSS vulnerability.
MegaBank offers an investment portal for its 401(k) management service, located at
investors.mega-bank.com. Inside investors.mega-bank.com/listing is a list of funds
available for investment via 401(k) contributions. The lefthand navigation menu
offers searching and filtering of these funds.

事不宜迟，让我们检查一个mega-bank.com多姆XSS漏洞。
MegaBank为其401(k)管理服务提供了一个投资门户，位于
investors.mega-bank.com。investors.mega-bank.com/listing里面有一份基金清单
可通过401(k)缴款进行投资。左侧导航菜单
提供这些资金的搜索和过滤。

检测发现

过滤器

investors.mega-bank.com

翻译6:

Because the number of funds is limited, searching and sorting take place client side. A
search for “oil” would modify the page URL to investors.mega-bank.com/listing?
search=oil. Similarly, a filter for “usa” to only view US-based funds would generate a
URL of investors.mega-bank.com/listing#usa and would automatically scroll the page
to a collection of US-based funds.
Now it’s important to note that just because the URL changes, that does not always
mean requests against the server are being made. This is more often the case in
modern web applications that make use of their own JavaScript-based routers, as this
can result in a better user experience.

因为基金的数量有限，所以搜索和排序发生在客户端。A
搜索“石油”会将页面URL修改为investors.mega-bank.com/listing?
搜索=石油。类似地，只查看美国基金的“usa”筛选器将生成一个
investors.mega-bank.com/listing#usa的网址，并会自动滚动页面
一个美国基金的集合。
现在需要注意的是，仅仅因为URL改变了，并不总是这样
意味着正在向服务器发出请求。这种情况更常见于
现代web应用程序使用自己的基于JavaScript的路由器，就像这样
可以带来更好的用户体验。

investors.mega-bank.com/listing#usa

JavaScript-based

翻译7:

When we enter a search query that is malicious, we won’t run into any funny interac‐
tions on this particular site. But it’s important to note that query params like search
can be a source for DOM XSS, and they can be found in all major browsers via
window.location.search.

当我们输入恶意的搜索查询时，我们不会遇到任何有趣的交互
在这个特殊的网站上。但是需要注意的是，像搜索这样的查询参数
可以是DOM XSS的一个来源，它们可以通过
windows . location . search

没读懂

读得快，但不懂

翻译8：

Likewise, the hash can also be found in the DOM via window.location.hash. This
means that a payload could be injected into the search query param or the hash. A
dangerous payload in many of these sources will not cause any trouble, unless
another body of code actually makes use of it in a way that could cause script execu‐
tion to occur—hence the need for both a “source” and a “sink.”
Let’s imagine that MegaBank had the following code in the same page:

同样，也可以通过window.location.hash在DOM中找到散列
意味着有效负载可以被注入到搜索查询参数或散列中。A
许多这些来源中的危险有效载荷不会引起任何麻烦，除非
另一部分代码实际上以一种可能导致脚本执行的方式使用了它
这就需要“源”和“汇”
让我们想象一下，MegaBank在同一个页面中有以下代码:

翻译9：源码分析：

/*
 * Grab the hash object #<x> from the URL.
 * Find all matches with the findNumberOfMatches() function,
 * providing the hash value as an input.
 */
const hash = document.location.hash;
const funds = [];
const nMatches = findNumberOfMatches(funds, hash);
/*
* Write the number of matches found, plus append the hash
* value to the DOM to improve the user experience.
*/
document.write(nMatches + ' matches found for ' + hash);

investors.mega-bank.com/listing#usa

findNumberOfMatches() function

Here we are utilizing the value of a source (window.location.hash) in order to gen‐
erate some text to display back to the user. This is done via a sink (document.write)
in this case, but could be done through many other sinks, some of which require
more or less effort than others.
Imagine we generated a link that looked like this:

这里我们利用源(window.location.hash)的值来生成
生成一些文本显示给用户。这是通过接收器(document.write)完成的
在这种情况下，可以通过许多其他接收器来完成，其中一些接收器需要
比别人或多或少的努力。
假设我们生成了一个如下所示的链接:

investors.mega-bank.com/listing#<script>alert(document.cookie);</script>

翻译10：

The document.write() call will result in the execution of this hash value as a script
once it is injected in the DOM and interpreted as a script tag. This will display the
current session cookies, but could do many harmful things as we have seen in past
XSS examples.
From this you can see that although this XSS did not require a server, it did require
both a source (window.location.hash) and a sink (document.write). Furthermore,
it would not have caused any issues if a legitimate string had been passed, and as such
could go undetected for a very long time.

document.write()调用将导致这个哈希值作为脚本执行
一旦它被注入DOM并被解释为脚本标签。这将显示
当前会话cookies，但可以做许多有害的事情，因为我们已经看到在过去
XSS的例子。
由此可以看出，虽然这个XSS不需要服务器，但它需要
源(window.location.hash)和接收器(document.write)。此外，
如果传递了合法的字符串，这不会导致任何问题，因此
很长一段时间都不会被发现。

seesion cookies

more harmful things

undetected for a long time

What's sinks？What's source?

Mean document.write

Mean document.cookie

过程感受：要将DOM-XSS，要先把xss文本展示出来。感觉看完还是没讲什么技术点呢，但是内容感觉写得还挺多的，总共2页半，下一次变种XSS。

缺少大量实例，理解还是有误差。