是的，有几个这样的库。库的选择取决于您使用的语言/Web 编程框架。

首先，您需要从阅读 XSS 开始。我推荐以下文件：

• OWASP XSS（跨站点脚本）预防备忘单

接下来，一旦您熟悉了这一点，我可以向您指出一些提供经过良好测试的转义功能的库：

• OWASP ESAPI
• 微软反 XSS

但是，让我警告您，正确使用这些功能需要开发人员的知识，并且可能容易出错。有许多不同的解析上下文可能会将动态数据注入 HTML、CSS 或 Javascript 内容中；每个解析上下文可能需要应用不同的转义函数（或转义函数序列）。开发人员每次将动态数据注入此类内容时都需要确保应用正确的转义函数。这需要了解 XSS 风险以及如何防御它们。

这种方法（在任何使用它的地方手动转义数据）也容易出错。很容易忘记应用转义函数。如果您在文档中有 100 个包含动态数据的位置，那么在 99 个位置中很容易记住并且在不经意间忘记在其中一个位置进行转义。我们只是人类，这类错误很容易犯。转义函数库并不能帮助开发人员避免这个问题。

更好的解决方案是使用帮助开发人员避免此问题的 Web 编程框架。最先进的是上下文相关的自动清理。这对于提供 HTML 模板系统的框架特别有效。在这样的系统中，模板引擎负责自动转义插入到模板中的所有非静态数据。因为模板引擎可以识别动态插入数据的解析上下文，所以模板引擎可以自动选择并应用适当的转义函数。

上下文相关的自动清理的主要问题是目前只有少数 Web 编程框架支持它。一些支持上下文相关自动清理的 Web 框架：Google Cte​​mplate（闭包模板）、GWT、Google Clearsilver。

有关此主题的更多信息，我强烈推荐以下研究论文：

• A Systematic Analysis of XSS Sanitization in Web Application Frameworks，发表于 ESORICS 2011。

而不是使用上下文感知转义（可能有各种 PHP 库试图这样做）我建议使用完整的 HTML XSS 感知解析器，它将创建一个文档树并且只允许选择的白名单元素、属性等。

采用这种方法的项目是HTMLPurifier和Wibble。例如，微博：

• 将所有 HTML 输入转换为 HTML 安全的 UTF-8
• 将 HTML 加载到 DOMDocument 对象中
• 将一个或多个过滤器（DOM 操纵器）应用于 HTML DOM
• 从 DOM 中提取过滤后的 HTML 并应用 HTML Tidy (ext/tidy)
• 将最终的 HTML 转换为用户选择的字符编码（如果不是 UTF-8）

来自几乎有效的 HTML 语法的恶意代码无处可通过。如果 HTML 有任何问题，很可能是您的不完整白名单（或一些奇怪的 html/tidy 攻击向量，但我对此表示怀疑）。

更新： 如果您不需要成熟的 HTML 解析器，另一种选择是使用默认安全的模板引擎。我知道的唯一具有上下文感知转义的 PHP 项目是Nette Latte模板引擎，不过我没有使用它。其他引擎也有不同的转义技术，但你需要自己指定上下文（如果你省略一次上下文，你就会受到 XSS 攻击）。例如Twig或Smarty。您可以从那些代码中取出转义代码，以便在模板引擎之外使用它。

对抗 XSS 的最佳解决方案是让程序员了解数据的危险性，并在输出数据时使用上下文感知转义。总是。让程序员更多地思考他们在做什么，并为您提供更强大的程序。我认为这种方法没有问题:-)

有两件事要记住：

1. 总是在输出时转义，而不是在输入时。
2. 如果您担心性能，可以缓存转义的输出。

HTML Purifier 很好，但它对使用它的上下文视而不见。以下代码易受攻击：

<input type="text" name="test" value="<?php echo $hp->purify($_GET['foo']); ?>" />

概念证明： /?foo=test%22%20onload%3D%22alert(%27XSS%27)%3B

上下文感知转义通常是您只能通过模板引擎获得的东西。最普遍的情况：

• 您需要允许 HTML 吗？
  • 是：使用 HTMLPurifier 或 Stauros。（更多内容如下。）
  • 否：与;一起使用 htmlentities()ENT_QUOTES指定字符集（例如'UTF-8'）。

如果您担心在每个请求上通过 HTMLPurifier 运行用户提供的数据的性能，请试一试 Stauros XSS 库。（自述文件说它仍然是实验性的，但我还没有找到绕过它的方法。）