javascript 如何避免“跨站脚本攻击”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3439663/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to avoid "Cross-Site Script Attacks"
提问by Latze
How do you avoid cross-site script attacks?
如何避免跨站脚本攻击？
Cross-site script attacks(or cross-site scripting) is if you for example have a guestbook on your homepage and a client posts some javascript code which fx redirects youto another website or sends your cookies in an email to a malicious useror it could be a lot of other stuff which can prove to be real harmful to you and the people visiting your page.
跨站点脚本攻击（或跨站点脚本）是，例如，如果您的主页上有一个留言簿，并且客户端发布了一些 javascript 代码，该代码将您重定向到另一个网站或将您的 cookie 通过电子邮件发送给恶意用户或它可能是很多其他的东西，可以证明对你和访问你页面的人真的有害。
I'm sure it can be done fx. in PHPby validating formsbut I'm not experienced enough to fx. ban javascript or other things which can harm you.
我确定它可以完成 fx。在PHP 中通过验证表单，但我没有足够的经验来 fx。禁止 javascript 或其他可能伤害您的东西。
I hope you understand my question and that you are able to help me.
我希望你理解我的问题并且你能够帮助我。
回答by bobince
I'm sure it can be done fx. in PHP by validating forms
我确定它可以完成 fx。在 PHP 中通过验证表单
Not really. The input stage is entirely the wrong place to be addressing XSS issues.
并不真地。输入阶段完全是解决 XSS 问题的错误地方。
If the user types, say <script>alert(document.cookie)</script>into an input, there is nothing wrong with that in itself. I just did it in this message, and if StackOverflow didn't allow it we'd have great difficulty talking about JavaScript on the site! In most cases you want to allow any input(*), so that users can use a <character to literally mean a less-than sign.
如果用户<script>alert(document.cookie)</script>输入，比如输入，那么这本身没有任何问题。我只是在这条消息中做到了，如果 StackOverflow 不允许，我们将很难在网站上谈论 JavaScript！在大多数情况下，您希望允许任何输入 (*)，以便用户可以使用<字符来表示小于号的字面意思。
The thing is, when you write some text into an HTML page, you must escape it correctly for the context it's going into. For PHP, that means using htmlspecialchars()at the output stage:
问题是，当您将一些文本写入 HTML 页面时，您必须为它进入的上下文正确地转义它。对于 PHP，这意味着htmlspecialchars()在输出阶段使用：
<p> Hello, <?php echo htmlspecialchars($name); ?>! </p>
[PHP hint: you can define yourself a function with a shorter name to do echo htmlspecialchars, since this is quite a lot of typing to do every time you want to put a variable into some HTML.]
[PHP 提示：您可以使用较短的名称为自己定义一个函数 do echo htmlspecialchars，因为每次您想将变量放入某些 HTML 时，都要进行大量输入。]
This is necessary regardless of where the text comes from, whether it's from a user-submitted form or not. Whilst user-submitted data is the most dangerous place to forget your HTML-encoding, the point is really that you're taking a string in one format (plain text) and inserting it into a context in another format (HTML). Any time you throw text into a different context, you're going to need an encoding/escaping scheme appropriate to that context.
无论文本来自何处，无论是否来自用户提交的表单，这都是必要的。虽然用户提交的数据是忘记 HTML 编码的最危险的地方，但关键是您正在以一种格式（纯文本）获取字符串并将其插入到另一种格式（HTML）的上下文中。每当您将文本放入不同的上下文时，您都需要适合该上下文的编码/转义方案。
For example if you insert text into a JavaScript string literal, you would have to escape the quote character, the backslash and newlines. If you insert text into a query component in a URL, you will need to convert most non-alphanumerics into %xxsequences. Every context has its own rules; you have to know which is the right function for each context in your chosen language/framework. You cannot solve these problems by mangling form submissions at the input stage—though many na?ve PHP programmers try, which is why so many apps mess up your input in corner cases and still aren't secure.
例如，如果您将文本插入到 JavaScript 字符串文字中，则必须对引号字符、反斜杠和换行符进行转义。如果将文本插入到 URL 的查询组件中，则需要将大多数非字母数字转换为%xx序列。每个上下文都有自己的规则；您必须知道对于您选择的语言/框架中的每个上下文，哪个函数是正确的。您无法通过在输入阶段修改表单提交来解决这些问题——尽管许多初级 PHP 程序员尝试过，这就是为什么如此多的应用程序在极端情况下弄乱了您的输入并且仍然不安全的原因。
(*: well, almost any. There's a reasonable argument for filtering out the ASCII control characters from submitted text. It's very unlikely that allowing them would do any good. Plus of course you will have application-specific validations that you'll want to do, like making sure an e-mail field looks like an e-mail address or that numbers really are numeric. But this is not something that can be blanket-applied to all input to get you out of trouble.)
(*: 嗯，几乎所有。从提交的文本中过滤掉 ASCII 控制字符有一个合理的论据。允许它们有任何好处的可能性很小。另外，当然你会有你想要的特定于应用程序的验证做，例如确保电子邮件字段看起来像电子邮件地址，或者数字确实是数字。但这不是可以一揽子应用于所有输入的东西，以使您摆脱麻烦。）
回答by danben
Cross-site scripting attacks (XSS) happen when a server accepts input from the client and then blindly writes that input back to the page. Most of the protection from these attacks involves escaping the output, so the Javascript turns into plain HTML.
当服务器接受来自客户端的输入然后盲目地将该输入写回页面时，就会发生跨站点脚本攻击 (XSS)。大多数针对这些攻击的保护都涉及对输出进行转义，因此 Javascript 会变成纯 HTML。
One thing to keep in mind is that it is not only data coming directly from the client that may contain an attack. A Stored XSSattack involves writing malicious JavaScript to a database, whose contents are then queried by the web application. If the database can be written separately from the client, the application may not be able to be sure that the data had been escaped properly. For this reason, the web application should treat ALL data that it writes to the client as if it may contain an attack.
要记住的一件事是，不仅直接来自客户端的数据可能包含攻击。一个存储的XSS攻击需要编写恶意的JavaScript到一个数据库，其内容，然后由Web应用程序查询。如果数据库可以与客户端分开编写，应用程序可能无法确定数据是否已正确转义。出于这个原因，Web 应用程序应该将它写入客户端的所有数据视为可能包含攻击。
See this link for a thorough resource on how to protect yourself: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
有关如何保护自己的完整资源，请参阅此链接：http: //www.owasp.org/index.php/XSS_(Cross_Site_Scripting) _Prevention_Cheat_Sheet
