我看了很多有关XSS攻击的文章，
但是让我感到困惑的一件事是，脚本注入实际上是如何工作的吗
？ >作为输入，为什么它可以永久保留在浏览器中，并且每个访问网站的用户都可以看到警报。
从我的理解中，在攻击者的输入之后，将以有效载荷＆lt; script＆gt; arter（'tactact！'）＆lt;/script＆gt; 发送发布请求。同时，＆lt; header＆gt; 标签或＆lt; script＆gt; 仅应在客户端源代码/Web服务器上操纵。
如何工作？
I have watched lots of articles about XSS attack,
but one thing that make me confused is that, how the script injection works actually?
For example, if attackers enter something like <script>alert('Attack!')</script>as the input, why it can stay in the browser permanantly and every user visiting the website can see the alert.
From my understanding, after attackers's input, a POST request will be sent with payload <script>alert('Attack!')</script>. Meanwhile the <header> tag or <script> should only be manipulated on Client Side Source Code/Web Server.
How can it work?
发布评论
评论（2）
理解经典XSS机制的最简单方法：
如果没有安全性介绍，则攻击者将脚本输入到文章下的评论部分的文本框中，然后将其发送给。这种方式在服务器数据库中获取脚本存储。每当有人访问该页面时，请注释部分，脚本将加载在访问者的客户端。
为了补充消毒输入，逃脱输出并使用。
The easiest way to understand the classic XSS mechanism:
If there are no security mesurements, an Attacker inputs the script into a comment section's textbox under an article and then sends it in. This way the script gets stored in the server's database. Every time someone visits that page with the comment section the script will be loaded on the visitor's client side.
To remediate that sanitize input, escape output and use Content-Security-Policy.
XSS漏洞有几种类型。
我假设您在谈论持久性XSS，因为那是与您的问题有关的一种类型。
在持续的XSS漏洞中，您可以发布一个请求，然后将其存储在应用程序的服务器端后端（即数据库）中。
例如，数据库中存储文章评论部分的表。
当应用程序的其他客户端请求该页面时，服务器使用相关文章HTML页面响应，包括注释部分，攻击者的有效负载存在。然后，每个接收该HTML页面的客户端还将收到一个恶意
＆lt; script＆gt; poryload＆lt;/script＆gt;脚本的评论。从这里开始，客户端的浏览器会自动呈现HTML 并执行
＆lt; script＆gt;标签作为从服务器接收的合法JS代码。。
由于此代码是由攻击者注入的，并在客户端的浏览器中运行，因此可能是有害的 - 窃取客户端的cookie，会话键等，并将其发送到远程服务器。
There are several types of XSS vulnerabilities.
I'll assume you are talking about a persistent-XSS since that's one type related to your question.
In a persistent-XSS vulnerability, you can POST a request which is then stored in the server-side backend of the application (i.e. a database).
For example, a table in a database storing the comments sections of an article.
When other clients of the application then request that page, the server responds with the related article HTML page including the comments section, where the attacker's payload exists. Then, each client receiving that HTML page, will also receive a comment with a malicious
<script>payload</script>script.From here, the client's browser automatically renders the HTML and executes
<script>tags as legitimate JS code received from the server.Since this code was injected by an attacker, and runs in the clients' browsers, it can be harmful - stealing the client's cookies, session keys, etc. and sending them to a remote server.