Cross-site scripting is one of the most common and popular web attacks.

跨站点脚本是最常见和流行的Web攻击之一。

It allows an attacker to inject client-side code into web applications screens that are then viewed by the victims.

它允许攻击者将客户端代码注入Web应用程序屏幕，然后由受害者查看。

Consequences and impact can vary depending on the type of attacks and context in which the attack is launched.

后果和影响可能会有所不同，具体取决于攻击的类型和发起攻击的环境。

XSS can be classified as:

XSS可以分类为：

• Self-XSS / Reflected XSS / Non-persistent XSS / Type-II XSS
  自XSS /反射XSS /非持久XSS / II型XSS
• Persistent XSS / Stored XSS / Type-I XSS
  永久XSS /已存储XSS / I型XSS
• DOM based XSS
  基于DOM的XSS

自我XSS (Self-XSS)

Let’s suppose we have the following PHP code - PHP just to pick (a legible) one:

假设我们有以下PHP代码-PHP仅是选择(清晰)的一个：

Textbook XSS: The victim opens a link that looks like

XSS教科书：受害者打开一个看起来像的链接

GET https://my-website.com/page.php?id=%22%3B%20alert(1)%3B%20var%20a%20%3D%20%22(GET https://my-website.com/page.php?id=”; alert(1); var a = “)

and, magically, the code above, after being rendered by PHP and sent to the victims browser, will look like

神奇的是，上面的代码在被PHP渲染并发送到受害者浏览器后，看起来像

In this case we’re just opening a popup and displaying “1” inside of it, but an attacker could get much more creative: he could make an AJAX call and send document.cookie to his server (provided the application didn’t set a HTTP-Only flag to the session cookie).

在这种情况下，我们只是打开一个弹出窗口并在其中显示“ 1”，但是攻击者可能会更有创造力：他可以发起AJAX调用并将document.cookie发送到他的服务器(只要应用程序未设置会话cookie的仅HTTP标志)。

It’s called reflected XSS since you’re sending a malicious request and getting some malicious response back.Bear in mind: the victim would need to open a maliciously crafted link (which could also be shortened using third party link shortners sites)

由于您正在发送恶意请求并获得一些恶意响应，因此将其称为“反射XSS”。请注意：受害者需要打开恶意制作的链接(也可以使用第三方链接缩短程序站点来缩短链接)

持久XSS (Persistent XSS)

Similar to a Self-XSS, but different workflow: the $id in this case has been stored into a database (or other persistent storage) and then read from it at a later time by the victim(s).

与Self-XSS相似，但工作流程不同：在这种情况下，$ id已存储到数据库(或其他持久性存储)中，并在以后由受害者从中读取。

A classic example here would be a platform that allows users to post content that is then displayed to other users (i.e. Medium): an attacker would be able to write some JS into a post and any user reading that post would automatically (perhaps silently) run the malicious JS code.

这里的经典示例是一个平台，该平台允许用户发布随后显示给其他用户的内容(即中型)：攻击者将能够在帖子中编写一些JS，而任何阅读该帖子的用户将自动(也许默默地)运行恶意的JS代码。

You can see how that can go very wrong very quickly, making persistent XSS a much more dangerous sub-category of this sort of attack.

你可以看到如何可以去非常错误的速度非常快，使得持续性XSS这种攻击的一个更加危险的子类。

基于DOM的XSS (DOM based XSS)

Firstly described by Amit Klein in 2005, DOM based XSS is less known variant and occurs whenever the XSS is a direct result of modifying the DOM context in which the regular client-side code runs, so that the execution results in an “unexpected” behaviour.

基于DOM的XSS最早由Amit Klein于2005年描述，它是鲜为人知的变体，每当XSS是修改运行常规客户端代码的DOM上下文的直接结果时，就会发生这种情况，因此执行将导致“意外”行为。

Normally this HTML page would be used for welcoming the user:

通常，此HTML页面将用于欢迎用户：

GET http://my-website.example.com/welcome.html?name=Michele

however a request such as:

但是，诸如以下的请求：

GET http://my-website.example.com/welcome.html?name=<script>alert(document.cookie)</script>

would result in an XSS condition.

将导致XSS条件。

Again - you could escalate this: send the cookies to a malicious server - potentially holding session info (i.e. session cookie) and take over an account.

再次-您可以升级：将cookie发送到恶意服务器-可能持有会话信息(即会话cookie)并接管一个帐户。

At the core, an XSS vulnerability is present whenever an application accepts untrusted (anything the application receives from the outside — usually user input data) data and displays it without correctly escaping it depending on its context.

从根本上讲， 每当应用程序接受不受信任的数据 (应用程序从外部接收的任何数据，通常是用户输入数据) 并显示数据时 ，都会出现XSS漏洞，而不会根据其上下文正确地转义数据 。

Context is a fundamental word in that sentence and that is also why an XSS isn’t much different from a SQL or XML/HTML injection.

上下文是该语句中的一个基本词，这也是为什么XSS与SQL或XML / HTML注入没有太大区别的原因。

攻击者可以做什么？ (What can an attacker do?)

Generally speaking, if an attacker manges to perform an XSS attack, he could be able to basically do one or more of the following:

一般而言，如果攻击者设法执行XSS攻击，则他基本上可以执行以下一项或多项操作：

Ad-Jacking — Inject his ads in it to make moneyClick-Jacking — Create a hidden overlay on a page to hijack clicks of the victim to perform malicious actions.Session Hijacking — HTTP cookies can be accessed by JavaScript if the HTTP ONLY flag is not present in the cookies.Content Spoofing — JavaScript has full access to client side code of a web app and hence he could use it show/modify desired content.Credential Harvesting — He could use a fancy popup to harvest credentials: WiFi firmware has been updated, re-enter your credentials to authenticate.Forced Downloads — So the victim isn’t downloading his malicious flash player from absolutely-safe.com? No problem: he could just try to force a download from the trusted website the victim is visiting.Crypto Mining — He could use the victim’s CPU to mine some bitcoin (or altcoin)Bypassing CSRF protection — He could collect and submit CSRF tokens to perform POST operations elsewhere on the site.Keylogging — Self-explanatoryRecording Audio, Taking pictures, Geo-location — It requires authorization from the user but he could access victim’s camera, microphone and location. Thanks to HTML5 and JavaScript.Stealing HTML5 web storage data — A website can store data in the browser for later use and, of course, JavaScript can access that storage via window.localStorage() and window.webStorage()Fingerprinting — Very easy to find your browser name, version, installed plugins and their versions, your operating system, architecture, system time, language and screen resolution.Network Scanning — Victim’s browser can be abused to scan ports and hosts with Javascript.Crashing Browsers — Why not?! :-)Stealing Information — Grab information from the webpage and send it to his malicious server.Redirecting —Self-explanatoryTabnapping — Fancy version of redirection: when no keyboard or mouse events have been received for more than a minute, it could mean that the user is afk and he can sneakily replace the current webpage with a fake one.Capturing Screenshots — Thanks to HTML5 again, now you can take screenshot of a webpage. Blind XSS detection tools have been doing this before it was cool.Perform Actions — He is controlling the browser

顶广告-在其中注入广告以赚钱。 顶广告 -在页面上创建隐藏的叠加层，以劫持受害者的​​点击以执行恶意操作。 会话劫持 —如果Cookie中没有HTTP ONLY标志，则JavaScript可以访问HTTP cookie。 内容欺骗-JavaScript可以完全访问Web应用程序的客户端代码，因此他可以使用它显示/修改所需的内容。 凭据收集 -他可以使用精美的弹出窗口来获取凭据：WiFi固件已更新，请重新输入凭据进行身份验证。 强制下载 -受害者是否没有从absolute-safe.com下载其恶意Flash Player？ 没问题：他可以尝试强迫受害者访问的受信任网站进行下载。 加密采矿 -他可以使用受害者的CPU来挖掘某些比特币(或山寨币)，从而绕过CSRF保护 -他可以收集并提交CSRF令牌，以执行站点上其他位置的POST操作。 键盘 记录 -自解释式录音，拍照，地理位置定位 -需要用户授权，但他可以访问受害者的摄像头，麦克风和位置。 感谢HTML5和JavaScript。 窃取HTML5 Web存储数据 -网站可以将数据存储在浏览器中以供以后使用，当然，JavaScript可以通过window.localStorage()和window.webStorage()访问该存储。 指纹识别 -非常容易找到您的浏览器名称，版本，已安装的插件及其版本，您的操作系统，体系结构，系统时间，语言和屏幕分辨率。 网络扫描 -可以滥用受害者的浏览器来使用Java扫描端口和主机。 崩溃的浏览器 -为什么不呢？ :-) 窃取信息 -从网页中获取信息，并将其发送到他的恶意服务器。 重定向 -不言自明的跳转 - 精美的重定向版本：当超过一分钟未收到键盘或鼠标事件时，这可能意味着用户很烦，他可以用伪造的网页来轻松地替换当前网页。 捕获屏幕截图 -再次感谢HTML5，现在您可以获取网页的屏幕截图。 盲XSS检测工具一直在这样做，然后才变酷。 执行动作 -他正在控制浏览器

Not all is lost, cross-site scripting can be prevented!

并非全部丢失，可以防止跨站点脚本编写！

该怎么办？ (What can be done?)

Unfortunately there’s no silver bullet. You could be:

不幸的是，没有灵丹妙药。 你可能是：

• using a Web Application Firewall (and hope for the best: they can block some/most common attacks but not all)
  使用Web应用程序防火墙(并希望最好：他们可以阻止某些/最常见的攻击，但不能阻止所有攻击)

• using X-XSS-PROTECTION that stops pages from loading when the browser detects reflected cross-site scripting (deprecated IE feature)

  使用X-XSS-PROTECTION可以在浏览器检测到反映的跨站点脚本(停止使用IE功能)时停止加载页面

• using Content Security Policy, X-FRAME-OPTIONS, (etc..) headers to limit impact

  使用Content Security Policy ， X-FRAME-OPTIONS等标题来限制影响

but again, none of the above (or a combination) are solutions to the actual problem. If anything they might give you a false sense of security.

但是，以上(或两者结合)都不是解决实际问题的方法。 如果有的话，它们可能会给您带来虚假的安全感。

The real solution is to write non vulnerable code 😃.

真正的解决方案是编写非脆弱代码😃。

As said earlier:

如前所述：

At the core, an XSS vulnerability is present whenever an application accepts untrusted (anything the application receives from the outside — usually user input data) data and displays it without correctly escaping it depending on its context.

从根本上讲， 每当应用程序接受不受信任的数据 (应用程序从外部接收的任何数据，通常是用户输入数据) 并显示数据时 ，都会出现XSS漏洞，而不会根据其上下文正确地转义数据 。

So, the solution is to correctly escape content based on the context they are live in: in a generic HTML context <,> have special meanings so they should be coverted into their HTML code equivalents (&lt;&gt); in a HTML attribute context, instead, double quotes (or single quotes) have a special meaning so they should be converted into their HTML code equivalents (&quot;), etc…

因此，解决方案是根据内容所处的上下文正确地对内容进行转义：在一般HTML上下文中，<，>具有特殊含义，因此应将其隐藏在等效HTML代码中(＆lt;＆gt;)； 相反，在HTML属性上下文中，双引号(或单引号)具有特殊含义，因此应将其转换为HTML代码等效项(“”)，依此类推…

In Javascript, instead, depending on the specific area in which the untrusted input is injected, it can be a bit trickier to understand what characters have special meaning - so, in that instance, it’s easier to escape all non-alphanumeric characters with their hex equivalent (i.e. double quote becomes \x22, $ becomes \x24, etc…).

相反，在Javascript中，根据注入不受信任的输入的特定区域，了解具有特殊含义的字符可能会有些棘手-因此，在这种情况下，使用十六进制转义所有非字母数字字符会更容易等价的(即双引号变成\ x22，$变成\ x24，依此类推)。

Don’t roll your own security: you should instead rely on whatever your language-of-choice / framework provides for this.

不要自己承担安全性：您应该依靠自己的选择语言/框架提供的一切。

I’ll try and list a few per language.

我会尝试列出每种语言的几种。

Is your language/framework not in this list?Feel free to leave a comment / recommendations and I’ll amend the list!

您的语言/架构不在此列表中吗？请随时发表评论/建议，我将对其进行修改！

Sharing is caring, eh? 😄

分享很贴心，是吗？ 😄

Since you’re interested in security and common vulnerabilities, you may also want to read about SQL injections and how to prevent them in your application.

小号因斯你感兴趣的安全性和常见漏洞，你可能还需要了解SQL注入以及如何防止他们在您的应用程序 。

本机— C＃(ASP.NET) (Native — C# (ASP.NET))

The Razor engine used in MVC automatically encodes all output sourced from variables. You could also use JavaScriptEncoder to encode variables in Javascript context.

MVC中使用的Razor引擎会自动对所有源自变量的输出进行编码。 您还可以使用JavaScriptEncoder在Javascript上下文中对变量进行编码。

本机— Go(Golang) (Native — Go (Golang))

golang.org/pkg/html#EscapeString escapes special characters (<>&’ ”) to their HTML code equivalents

golang.org/pkg/html#EscapeString将特殊字符(<>＆' )转义为等效HTML代码

golang.org/pkg/html/template gives you more control and better escaping functionality for CSS/JS/HTML.

golang.org/pkg/html/template为CSS / JS / HTML提供了更多控制权和更好的转义功能。

本机— Java (Native — Java)

OWASP provides AntiSamy (an API for ensuring user-supplied HTML/CSS is in compliance within an application’s rule)

OWASP提供AntiSamy (用于确保用户提供HTML / CSS符合应用程序规则的API)

OWASP also provides Java-HTML-Sanitizer that pretty much does the same thing but in a different way. HTML-Sanitizer is fast and simpler to use but less flexible.

OWASP还提供Java-HTML-Sanitizer ，它几乎可以做同样的事情，但方式不同。 HTML-Sanitizer快速，易于使用，但灵活性较差。

OWASP also used to provide ESAPI but that’s now a defunct project.

OWASP也曾经提供过ESAPI，但是现在这已经是一个不可行的项目了。

本机— PHP (Native — PHP)

htmlentities will convert all applicable characters to HTML entities, but that’s not the best way to prevent XSS.

htmlentities将所有适用的字符转换为HTML实体，但这不是防止XSS的最佳方法。

HTMLPurifier will by default strip malicious code, but you can configure it to escape it instead.

HTMLPurifier默认情况下会剥离恶意代码，但您可以对其进行配置以转义它。

本机— Python (Native — Python)

The html package allows you to convert &<> (and “ ‘ if requested) to their HTML-code equivalents.

html包允许您将＆<>(和“”(如果要求))转换为其等效HTML代码。

角2,3,4,5,6,7,8,9 — JS (Angular 2,3,4,5,6,7,8,9 — JS)

Angular treats all values as untrusted by default. When a value is inserted into the DOM from a template, via property, attribute, style, class binding, or interpolation, Angular sanitizes and escapes untrusted values.

默认情况下，Angular将所有值视为不可信。 当通过属性，属性，样式，类绑定或插值将值从模板插入DOM时，Angular会清理并转义不受信任的值。

Django-Python (Django — Python)

If you use Django templates you are protected against the majority of XSS attacks. However, it’s not foolproof: Django templates escape specific characters which are particularly dangerous to HTML but it won’t protect you from HTML attribute based attacks for instance.

如果使用Django模板，则可以防止大多数XSS攻击。 但是，这并非万无一失： Django模板会转义特定字符 ，这对于HTML来说尤其危险，但是它不能保护您免受基于HTML属性的攻击。

烧瓶-Python (Flask — Python)

Flask configures Jinja2 to automatically escape all values by default.

Flask 将Jinja2配置为默认情况下自动转义所有值 。

Laravel-PHP (Laravel — PHP)

In Laravel ≥5 , the default {{ }} should escape all output

在Laravel≥5中，默认{{}}应该转义所有输出

React — JS (React — JS)

React automatically escapes variables for you, but there are a few gotchas. More about that here.

React自动为您转义变量，但有一些陷阱。 更多关于这里 。

Symfony-PHP (Symfony — PHP)

Symfony applications are safe by default because they perform automatic output escaping

默认情况下，Symfony应用程序是安全的，因为它们执行自动输出转义

Follow Infosec Write-ups for more such awesome write-ups.

关注 Infosec文章， 以获得更多此类出色的文章。