存储xss 反射xss_XSS权威指南

存储xss 反射xss

什么是XSS，又称为跨站点脚本？ (What is XSS, aka Cross Site Scripting?)

XSS is the term we use to define a particular kind of attack where a website (your website, if you don’t pay attention) might be used as a vector to attack its users, because of an insecure handing of the user input.

XSS是我们用来定义一种特定类型的攻击的术语，由于用户输入的处理不安全，网站(您的网站，如果您不注意的话)可能被用作攻击其用户的媒介。

Basically a bad actor (the attacker) can inject JavaScript, in some way or another, into our site, by taking advantage of a vulnerability we left in our code.

基本上，不良行为者(攻击者)可以利用我们在代码中留下的漏洞，以某种方式将JavaScript注入我们的网站。

Using this vulnerability, they can steal user’s information.

使用此漏洞，他们可以窃取用户的信息。

Based on how the XSS vulnerability is exploited, we have 3 major kinds of XSS attacks:

根据XSS漏洞的利用方式，我们有3种主要的XSS攻击：

• persistent XSS
  持续的XSS
• reflected XSS
  反映的XSS
• DOM-based XSS
  基于DOM的XSS

为什么XSS危险？ (Why is XSS dangerous?)

Imagine you have a website. An attacker can somehow inject JavaScript code that is served by your website, and it’s executed - without your will, and without you knowing about it - by your user’s browsers.

假设您有一个网站。 攻击者可以某种方式注入由您的网站提供JavaScript代码，并且该代码是在用户的浏览器不经您的意愿和您不知道的情况下执行的。

This is very dangerous.

这是非常危险的。

Due to your negligence in fixing a XSS vulnerability, your site can be used as an attack vector and your users information is at risk.

由于您疏于解决XSS漏洞，您的网站可以用作攻击媒介，并且用户信息受到威胁。

In particular, when anyone can inject JavaScript in a page, they can have access to the user’s cookies associated with the website, and read any information contained in them. And send this to their own servers. They can listen for keyboard events, and get access to anyone the user types into the page and send it to the attacker’s servers using fetch or XHR. Usernames and passwords, for example. They can also manipulate the DOM and with this power they can perform lots of bad things.

尤其是，当任何人都可以在页面中注入JavaScript时，他们就可以访问与网站相关联的用户cookie，并读取其中包含的任何信息。 并将其发送到自己的服务器。 他们可以侦听键盘事件，并可以访问用户在页面中键入的任何内容，并使用访存或XHR将其发送到攻击者的服务器。 例如，用户名和密码。 他们还可以操纵DOM，并借助此功能可以执行许多不良操作。

XSS是前端还是后端问题？ (Is XSS a frontend or backend problem?)

It’s both. It’s a website architectural problem that involves both the frontend and the backend.

都是。 这是一个涉及前端和后端的网站架构问题。

XSS攻击示例 (An XSS attack example)

XSS is basically enabled when you allow the user to enter information, which you store (in your backend) and then present back.

当您允许用户输入要存储的信息(在后端)然后再显示时，XSS基本上已启用。

Say you have a blog, and you allow users to comment in the blog. If you blindly accept any content a users enter, a malicious user can try to enter a JavaScript snippet, in its most basic form enclosed within <script></script>. For example <script>alert('test')</script>.

假设您有一个博客，并允许用户在博客中发表评论。 如果您盲目接受用户输入的任何内容，恶意用户可以尝试以最基本的形式包含在<script></script>JavaScript代码段。 例如<script>alert('test')</script> 。

You might store this comment in your database, and when the page is reloaded - again, if you don’t have any prevention in place - all the users loading that page will run that JavaScript snippet.

您可以将此注释存储在数据库中，并且在重新加载页面时-如果没有采取任何措施，则再次加载该页面的所有用户都将运行该JavaScript代码段。

I used a simple alert() call to make an example, but as listed above a user could enter any kind of script. At this point, the site is compromised.

我使用一个简单的alert()调用来举一个例子，但是如上所列，用户可以输入任何类型的脚本。 此时，该站点已被破坏。

什么是持久性XSS？ (What is persistent XSS?)

Persistent XSS is one of the 3 kinds of XSS we find in the wild. It’s the one I described above in the blog post example.

持久XSS是我们在野外发现的三种XSS之一。 这是我上面在博客文章示例中描述的内容。

In this case, the code for the vulnerability is stored in the database or into some other source, which is hosted by yourself.

在这种情况下，该漏洞的代码存储在数据库中或其他资源中，这些资源由您自己托管。

Once someone can enter a JavaScript snippet, it’s served automatically by your site without any other action required.

一旦有人可以输入JavaScript代码段，您的网站就会自动提供该代码段，而无需执行任何其他操作。

XSS反映了什么？ (What is reflected XSS?)

Reflected XSS is a way to exploit a vulnerability in your site on-the-fly by providing the end user a link that has a script inside it.

Reflected XSS是一种通过向最终用户提供一个内部包含脚本的链接来动态利用站点中漏洞的一种方法。

In this way, the attacker provides a link similar to

这样，攻击者提供的链接类似于

yoursite.com/?example=<script>alert('test')</script>

If your site uses the example GET variable to perform something and display it on the page, and you don’t check and sanitize its value, now that script will be executed by the user’s browser.

如果您的站点使用example GET变量执行某些操作并将其显示在页面上，并且您没有检查和清理其值，那么该脚本将由用户的浏览器执行。

A typical example is a search form. It might live in the /search URL and you might accept the search term using the GET term variable.

一个典型的例子是搜索表单。 它可能位于/search URL中，并且您可以使用GET term变量接受搜索词。

You might display the You searched for <term> string when someone searches for it. Now, if you didn’t sanitize the value, you now have a problem.

当有人搜索You searched for <term>字符串时，您可能会显示它。 现在，如果您不清理价值，那么现在就会遇到问题。

Spam/phishing emails are a common medium for this XSS attack. Of course, the bigger and more important the site, the more frequently hackers will try to hack it.

垃圾邮件/网络钓鱼电子邮件是这种XSS攻击的常见媒介。 当然，网站越大越重要，黑客就越会尝试对其进行黑客入侵。

什么是基于DOM的XSS？ (What is DOM-based XSS?)

With persistent XSS, the attacking code must be sent to the server, where it can be (and hopefully it is) sanitized. With reflected XSS, the same is true.

使用持久性XSS，必须将攻击代码发送到服务器，然后可以在服务器上进行清理(并希望将其清除)。 对于反射的XSS，同样如此。

DOM-based XSS is a kind of XSS where the malicious code is never sent to the server. It’s common for this to happen by using the fragment part of a URL, or by referencing document.URL/document.location.href. Some examples you find online don’t really work any more because modern browsers automatically escape JS in the address bar for us. They only work if you unescape it, which is kind of scary (don’t do it!).

基于DOM的XSS是一种XSS，其中恶意代码永远不会发送到服务器。 通常，这是通过使用URL的片段部分或通过引用document.URL / document.location.href 。 您在网上发现的一些示例不再有用，因为现代浏览器会自动为我们在地址栏中转义JS。 它们只有在您取消转义时才起作用，这有点吓人(不要这样做！)。

Here’s a simple working example. Say you have a page listening on http://127.0.0.1:8081/testxss.html. Your client-side JavaScript looks at the test variable passed in the fragment part of the URL:

这是一个简单的工作示例。 假设您有一个页面正在http://127.0.0.1:8081/testxss.html上监听。 您的客户端JavaScript会查看URL片段部分中传递的test变量：

http://127.0.0.1:8081/testxss.html#test=something

http://127.0.0.1:8081/testxss.html#test=something

The #test=something value is never send to the server. It’s only local. Persistent/reflected XSS would not work. But say your script accesses that value using:

#test=something值永远不会发送到服务器。 它只是本地的。 持久/反映的XSS将不起作用。 但是说您的脚本使用以下命令访问该值：

const pos = document.URL.indexOf("test=") + 5;
const value = document.URL.substring(document.URL.indexOf("test=") + 5, document.URL.length)

and you write it directly into the DOM:

然后将其直接写入DOM：

document.write(value)

All is fine, until someone calls the URL like this:

一切都很好，直到有人像这样调用URL：

http://127.0.0.1:8081/testxss.html#test=

http://127.0.0.1:8081/testxss.html#test=

Now, thanks to the automatic escaping that happens by referencing document.URL nothing should happen in this specific case.

现在，由于引用document.URL会自动转义，在这种情况下，什么也不会发生。

You’d get

你会得到

%3Cscript%3Ealert('x')%3C/script%3E

printed to the page. The value is escaped, so it’s not interpreted as HTML.

打印到页面。 该值已转义，因此不会解释为HTML。

But if for some reason you unescape the document.URL value, you have a problem now, as the JavaScript is run. Any JS can be run on your users browsers.

但是，如果由于某种原因而取消了document.URL值，那么在运行JavaScript时就会遇到问题。 任何JS都可以在您的用户浏览器上运行。

On older browser, this was a much bigger problem, since they didn’t auto-escape JS put into the address bar.

在较旧的浏览器上，这是一个更大的问题，因为它们没有自动转义进入地址栏的JS。

静态站点容易受到XSS攻击吗？ (Are static sites vulnerable to XSS?)

Yes! Any kind of site, actually. Because being static does not mean there is no information loaded from other sources. For example you might roll your own form or comments, even without a database.

是! 实际上，任何形式的网站。 因为是静态的并不意味着不会从其他来源加载任何信息。 例如，即使没有数据库，您也可以滚动自己的表单或注释。

Or, we might have a search functionality that accepts input from an HTTP GET or POST variable. You are not immune just by not having a database.

或者，我们可能具有搜索功能，该功能接受来自HTTP GET或POST变量的输入。 您没有数据库就不能幸免。

我们如何预防XSS？ (How can we prevent XSS?)

There are 3 techniques we can use:

我们可以使用3种技术：

• encoding
  编码方式
• validation
  验证
• CSP
  CSP

Encoding is done to escape the data. Doing so, the browser will not interpret the JavaScript because, for example, <script> will be encoded to %3Cscript%3E.

进行编码以转义数据。 这样做，浏览器将不会解释JavaScript，因为例如<script>将被编码为%3Cscript%3E 。

Encoding, as a general rule, should be always done.

作为一般规则，应始终进行编码。

Server-side frameworks commonly provide helper functions to provide this functionality to you.

服务器端框架通常提供帮助程序功能以向您提供此功能。

In client-side JavaScript we use a different encoding mechanism depending on the use case.

在客户端JavaScript中，我们根据用例使用不同的编码机制。

If you need to add content to an HTML element, the best way is to assign the user-generated input to that element using the textContent property. The browser will do all the escaping for you:

如果需要将内容添加到HTML元素 ，最好的方法是使用textContent属性将用户生成的输入分配给该元素。 浏览器将为您进行所有转义：

document.querySelector('#myElement').textContent = theUserGeneratedInput

If you need to create an element use document.createTextNode():

如果需要创建元素，请使用document.createTextNode() ：

const el = document.createTextNode(theUserGeneratedInput)

If you need to add content to an HTML attribute, use the setAttribute() method of the element:

如果需要向HTML属性添加内容 ，请使用元素的setAttribute()方法：

document.querySelector('#myElement').setAttribute('attributeName', theUserGeneratedInput)

If you need to add content to the URL, use the window.encodeURIComponent() function:

如果需要向URL添加内容，请使用window.encodeURIComponent()函数：

window.location.href = window.location.href + '?test=' + window.encodeURIComponent(theUserGeneratedInput)

Validation is usually done when you cannot use escaping to filter the input. A common example is a CMS that lets the user define the content of the page in HTML. You can’t escape that.

通常，当您不能使用转义来过滤输入时，通常会进行验证。 一个常见的示例是CMS，它使用户可以用HTML定义页面的内容。 你无法逃脱。

You either use a blacklisting or whitelisting strategy for validation. The difference is that with blacklisting you decide which tags you want to disallow. With whitelisting you decide which tags you want to allow. Whitelisting is safer because blacklisting is prone to errors, complex and also not future-proof.

您可以使用黑名单或白名单策略进行验证。 区别在于，通过将其列入黑名单，您可以决定要禁止哪些标签。 通过白名单，您可以决定要允许哪些标签。 白名单更安全，因为黑名单容易出错，复杂并且也不适合未来。

CSP means Content Security Policy. It’s a new standard implemented by browsers to enforce only executing JavaScript code coming from secure and trusted sources, and you can disallow running inline JavaScript in your code. The kind of JavaScript that allowed the above XSS exploits, for example.

CSP表示内容安全策略。 这是浏览器实施的新标准，用于仅执行来自安全和受信任来源JavaScript代码，并且您可以禁止在代码中运行内联JavaScript。 例如，允许上述XSS利用JavaScript类型。

CSP is enabled by the Web Server, by adding the Content‑Security‑Policy HTTP Header when serving the page.

Web服务器通过在为页面提供服务时添加Content‑Security‑Policy HTTP标头来启用CSP。

翻译自: https://flaviocopes.com/xss/

存储xss 反射xss