9月1日 | 英语翻译 | XSS的变异攻击

前言：从一篇论文引入变异而强大的XSS攻击：
“mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations.”

翻译1：

Several years ago, my friend and colleague Mario Heiderich published a paper called
“mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations.” This paper was one of the first introductions to a new and emerging classification of XSS attacks that has been dubbed mutation-based XSS (mXSS).
mXSS attacks are possible against all major browsers today. They rely on developing a
deep understanding of methods by which the browser performs optimizations and
conditionals when rendering DOM nodes.

几年前，我的朋友兼同事马里奥·海德里希发表了一篇名为
" mXSS攻击:通过使用innerHTML变异攻击安全的Web应用程序."这篇论文是对一种新的和新兴的XSS攻击分类的第一次介绍，这种分类被称为基于突变的XSS (mXSS)。
当今所有主流浏览器都可能遭到mXSS攻击。他们依靠一种
对浏览器执行优化和
呈现DOM节点时的条件。

翻译2:

Just as mutation-based XSS attacks were not widely known or
understood in the past, future technologies may also be vulnerable
to XSS.
XSS-style attacks can target any client-side display technology, and
although they are usually concentrated in the browser, desktop and
mobile technologies may be vulnerable as well.

就像基于突变的XSS攻击并不广为人知或
未来的技术也可能容易受到跨站攻击。
xss样式的攻击可以针对任何客户端显示技术
尽管它们通常集中在浏览器上，桌面和移动技术也可能受到攻击。

client-side xss attack

翻译 What Is the Client Side?

In web development, client-side is a term that describes that describe where application code runs. 

The Client-side is everything in a web application displayed or occurring on a client’s (end user’s) device, including what they see – images, text, and the rest of the UI. It also involves any actions performed by the app within the user’s browser.

The browser on the client-side interprets markup languages like CSS and HTML. Many developers now run client-side methods in their application architecture as business logic for dynamic webpages, such as in modern web applications. 

This methodology is a shift from performing everything on the server-side. Client-side processes are nearly always written in JavaScript.

在web开发中，客户端是一个描述应用程序代码在哪里运行的术语。

客户端是在客户端(最终用户的)设备上显示或发生的web应用程序中的一切，包括他们看到的内容——图像、文本和UI的其余部分。它还涉及应用程序在用户浏览器中执行的任何操作。

客户端的浏览器解释CSS和HTML等标记语言。许多开发人员现在在其应用程序架构中运行客户端方法，作为动态网页的业务逻辑，例如在现代web应用程序中。

这种方法是从在服务器端执行所有事情的转变。客户端流程几乎总是用JavaScript编写的。

翻译3：

Although new and often misunderstood, mXSS attacks have been used to bypass
most robust XSS filters available. Tools like DOMPurify, OWASP AntiSamy, and
Google Caja have been bypassed with mXSS, and many major web applications (in
particular, email clients) have been found vulnerable. At its core, mXSS functions by
making use of filter-safe payloads that eventually mutate into unsafe payloads after
they have passed filtration.

尽管mXSS攻击是新的并且经常被误解，但它已经被用来绕过
最强大的XSS过滤器可用。像DOMPurify, OWASP AntiSamy这样的工具
谷歌Caja已经被mXSS绕过，许多主要的web应用程序(在
特别是电子邮件客户端)被发现是脆弱的。mXSS的核心功能是使用过滤器安全的有效载荷，但最终会变异成不安全的有效载荷
它们通过了过滤。

DOMPurify, OWASP AntiSamy, and Google Caja

翻译4：

It’s easiest to understand mXSS with an example. Early in 2019, a security researcher
named Masato Kinugawa discovered an mXSS that affected a Google library called
Closure, which was used inside of Google Search.
Masato did this by using a sanitization library called DOMPurify that Closure used to
filter potential XSS strings. DOMPurify was being run on the client (in the browser)
and performed filtration by reading a string prior to permitting it to be inserted as
innerHTML. This is actually the most effective way of sanitizing strings that will be
injected into the DOM via innerHTML, as browsers vary in implementation, and ver‐
sions of browsers also vary (hence server-side filtration would not be as effective).

用一个例子来理解mXSS是最容易的。2019年初，一名安全研究员
Masato Kinugawa发现了一个影响谷歌库的mXSS
闭包Closure，它在谷歌Search中使用。
Masato通过使用Closure曾经使用的名为DOMPurify的消毒库来做到过滤潜在的XSS字符串。DOMPurify在客户端(在浏览器中)上运行并通过在允许将字符串插入之前读取该字符串来执行过滤innerHTML。这实际上是处理字符串最有效的方法
通过innerHTML注入到DOM中，因为浏览器的实现各不相同
浏览器的版本也各不相同(因此服务器端过滤不会那么有用)。

security researcher
named Masato Kinugawa discovered an mXSS Google Search.

翻译5：

By shipping the DOMPurify library to the client and performing evaluation, Google expected they would have a robust XSS filtration solution that worked across old and new browsers alike.


通过将DOMPurify库交付给客户端并执行评估，谷歌期望他们会有一个健壮的XSS过滤解决方案，可以在新旧浏览器中同样地工作。

翻译6：

Masato used a payload that consisted of the following:
<noscript><p title="</noscript><img src=x onerror=alert(1)>">
Technically this payload should be DOM safe as a literal append of this would not
result in script execution due to the way the tags and quotes are set up. Because of
this, DOMPurify let it pass as “not an XSS risk.” However, when this was loaded into
the browser DOM, the DOM performed some optimizations causing it to look like
this:
<noscript><p title="</noscript>
<img src="x" onerror="alert(1)">
"">
"

The reason this happened is because DOMPurify uses a root element <template> in
its sanitization process. The <template> tag is parsed but not rendered, so it is ideal
for use in sanitization.

Inside of a <template> tag, element scripting is disabled. When scripting is disabled,
the <noscript> tag represents its children elements, but when scripting is enabled it
does nothing.

从技术上讲，这个有效负载应该是DOM安全的，因为它的文字附加就不安全了
由于标签和引号的设置方式，导致脚本执行。因为
因此，DOMPurify让它作为“不是XSS风险”而通过。然而，当这个加载到
在浏览器DOM中，DOM执行了一些优化，使它看起来像
这样的:

发生这种情况的原因是因为DOMPurify在
它的消毒过程。< template >标记被解析但不被呈现，所以它是理想的
用于消毒。

在< template >标记内部，元素脚本被禁用。禁用脚本时，
< noscript >标记表示它的子元素，但是当脚本被启用时，它
什么都不做。

翻译7:

In other words, the img onerror is not capable of script execution inside of the sani‐
tizer, but when it passed sanitization and moved to a real browser environment the <p
title=" was ignored and the img onerror became valid.

To summarize, browser DOM elements often act conditionally based on their
parents, children, and siblings. In some cases, a hacker can take advantage of this fact
and craft XSS payloads that can bypass filters by not being a valid script—but that
turn into a valid script when actually run in the browser.

Mutation-based XSS is extremely new, and often misunderstood in the application
security industry. Many proof-of-concept exploits can be found on the web, and more
are likely to emerge. Unfortunately, because of this, mXSS is probably here to stay.

换句话说，img onerror不能在sani‐内部执行脚本
这是一个Tizer软件，但是当它通过消毒程序并移动到一个真正的浏览器环境时，</p<>
Title ="被忽略，img onerror变为有效。

总而言之，浏览器DOM元素的行为通常基于它们的条件
父母、孩子和兄弟姐妹。在某些情况下，黑客可以利用这一事实
并制作XSS有效负载，它可以通过不是一个有效的脚本而绕过过滤器
在浏览器中实际运行时转换为有效的脚本。

基于突变的XSS非常新，在应用程序中经常被误解
安全行业。许多概念验证漏洞可以在网络上找到，甚至更多
可能会出现。不幸的是，正因为如此，mXSS可能会继续存在下去。

关键点总结：

DOMPurify

原来已经有人总结了。

资料链接：
1.https://elementor.com/resources/glossary/what-is-the-client-side/
2.https://cloud.tencent.com/developer/article/1578269?from=article.detail.1825938
3.https://www.acunetix.com/blog/web-security-zone/mutation-xss-in-google-search/?chat_vt=1
4.https://cloud.tencent.com/developer/article/1768520?from=article.detail.1578269
5.https://github.com/cure53/DOMPurify