我已阅读 OWASP 网站中有关 xss 的页面，1 2
但我很好奇一个问题。
是否存在使用 html purifier 或 esapy 不可能吗？某种类型的限制。如果有的话我想了解一下具体情况。
如果存在这些情况，手动转义（输出编码）将是防止 xss 的唯一选择？
谢谢
I've read the pages about xss in OWASP website, 1 2
But i am curious about a question.
Is there any situation where the use of a framework like html purifier or esapy are not possible ? Some type of limitation. If so, I would like to know the situations.
If these situations exist, the manual escaping (output encoding) will be the only alternative to prevent xss ?
Thanks
发布评论
评论（1）
一旦您在非 HTML 上下文中使用数据，这些工具就毫无用处。将用户数据直接内联到 JavaScript 块中是一个相对常见的错误。
另外，任何其他非 HTML 上下文都会给您带来类似的问题，例如：将数据放入某些 CSS 代码中、放入 SMTP 信封中的电子邮件地址中，或者使用 PDF 文档中的数据。
了解相应的注入上下文和代码非常重要。您在 OWASP 链接到的 XSS 预防备忘单应该有助于引导您采用这种思维方法。永远不要认为“一刀切”在任何地方都适用。始终考虑将不受信任的数据放在哪里以及它们如何被滥用。
此外，这些库并不完美，并且正在不断改进和修复错误。例如，HTMLPurifier 有 2 个 XSS 漏洞最近在 2010 年。随着 HTML 5 得到更广泛的支持，事情也会发生变化，因为它引入了许多新的注入向量。
As soon as you use the data in a non-HTML context those tools are useless. Inlining user-data directly into a javascript block would be a relatively common mistake.
Additionaly any other non-HTML context would open you to similar problems For example: putting the data into some CSS code, in an email address in a SMTP envelope, or using the data in a PDF document.
It is important to understand the injection context and code accordingly. The XSS prevention cheat sheet you link to at OWASP should help to point you towards this method of thinking. Never assume that any "one size fits all" is going to work everywhere. Always think about where you are putting untrusted data and how it can be abused.
Additionally these libraries aren't perfect and are under constant improvement and bug fixing. For example HTMLPurifier had 2 XSS vuls recently in 2010. Things will also change now that HTML 5 is being more widely supported, as that introduces a number of new injection vectors.