我建议采用以下四步程序，您首先选择低垂的果实，以便在您处理更大的问题时给您一些最低限度的保护。

1.激活客户端过滤

1.1 设置 X-XSS-Protection 标头

设置以下 HTTP 响应标头将打开内置 XSS 保护的浏览器：

X-XSS-Protection: 1; mode=block

这绝不是防水的，它只有助于对抗反射型 XSS，但它是一些东西。一些旧版本的 IE（惊喜，惊喜）有一个错误的过滤器，实际上可能会使事情变得更糟，所以你可能想要过滤掉一些用户代理。

1.2 设置内容安全策略

如果您不在应用程序中使用内联 JavaScript，CSP可以提供很大帮助。设置script-src 'self'将 (a) 将脚本标签限制为仅包含来自您自己域的脚本，以及 (b) 禁用内联脚本。所以即使攻击者可以注入<img onerror="alert('XSS')">浏览器也不会执行脚本。您必须根据自己的用途定制用于标头的值，但链接的 MDN 资源应该可以帮助您。

但同样，这不是防水的。它对使用未实现 CSP 的浏览器的用户没有任何帮助（请参阅此处）。如果您的源代码中充斥着内联脚本，您将不得不在清理它或放弃使用 CSP 之间做出选择。

2.激活服务器端过滤

John Wu在评论中有一个很好的建议：

此外，由于这是 .NET，一个非常快速和简单的更改可以打开ASP.NET 请求验证，它可以捕获各种 XSS 攻击（但不是 100%）。

如果您使用其他语言工作，则可以考虑使用Web 应用程序防火墙（如xehpuk所建议的那样）。为您配置 WAF 的难易程度取决于您要保护的应用程序。如果您正在做的事情本来就很难过滤（例如在 GET 或 POST 参数中传递 HTML），那么配置一个可能不值得。

但是同样，虽然 WAF 可能会有所帮助，但它仍然不防水。

3.扫描并修复

使用自动 XSS 扫描程序查找现有漏洞并修复这些漏洞。作为补充，您可以运行自己的手动测试。这将帮助您将宝贵的时间集中在修复容易发现的漏洞上，从而在早期阶段为您带来最大的收益。

但是第三次​​，这不是防水的。无论你扫描和测试多少，你都会错过一些东西。所以，不幸的是，这个列表有第四点......

4.清理你的源代码

是的，您将“必须阅读每一页”。浏览源代码并使用某种框架或模板库重写所有输出数据的代码，这些框架或模板库以理智的方式处理 XSS 问题。（您可能应该选择一个框架并开始将其用于您在 #3 下所做的修复。）

这将花费大量时间，并且会很痛苦，但是需要完成。从好的一面来看——你有机会在你做一些额外的重构的时候。最后，您不仅会解决安全问题 - 您还将拥有更好的代码库。

缺点是没有简单的解决方案。我在底部有一个“简单”解决方案的建议，但请记住它有很多警告，我将在这里讨论。不过，首先，让我们从大局开始，一路向下。

根据我的经验（曾使用过许多遗留系统）“安全性长期以来一直不是优先事项”意味着您的系统中可能隐藏着许多安全问题。我敢肯定，XSS 只是一个问题。因此，除非您知道有人已经在这些之上，否则我会担心：

1. 密码安全。我怀疑您是否根据现代安全标准进行散列，这是一个很容易被忽视的关键问题。
2. 信用卡安全。我希望您符合 PCI 标准并且不在现场存储信用卡。我见过很多存储信用卡的遗留系统，即使你不应该这样做。
3. SQLi 可能是一个真正的问题，如果您在数据库中不安全地存储密码或信用卡，则尤其危险。
4. XSS 漏洞！

这些数字并不意味着优先级：它们都是首要任务。

起点

最重要的是“从制度上”解决这个问题。这将是最难做到的，但也是最关键的。如果您花费几周时间修复所有 XSS 漏洞，但安全性仍然是最底层的优先事项，那么下次开发人员将未经过滤的数据输出到浏览器时，问题就会再次出现。

针对 XSS 漏洞的最佳保护措施是让开发人员知道要认真对待安全性，并使用能够为您正确处理 XSS 转义的模板引擎。要记住的关键是，使用 XSS，您必须过滤输出，而不是输入。很容易将其视为单向问题“当用户数据进入输入时清理它，然后你就很好了”。但这并不能抵御所有攻击媒介，尤其是通过 SQLi 添加的 XSS。但总的来说，如果 XSS 保护是您的开发人员必须记住每次都要做的事情，它最终会被遗忘。这就是为什么最好的选择是将 XSS 保护内置到系统中的原因。这就是模板引擎的用武之地。任何有能力的模板系统默认自动应用 XSS 过滤，不过滤 XSS。

我敢肯定，重构您的系统以包括专门用于处理 XSS 漏洞的模板引擎可能不会发生，但同样重要的是要了解，如果您不采取措施解决允许这种情况发生的制度问题如果一开始就发生了，问题就会再次出现，而您花费数周时间来解决这个问题将被浪费掉。

第一个实际步骤

@Anders 在他的回答中有一些很好的起点。CSP 和 XSS-header 的工作方式相同：通过告诉浏览器启用 XSS 保护客户端。请记住（正如@Anders 提到的），这些是依赖于浏览器的，尤其是对于旧版浏览器，可能根本不受支持。特别是 IE 对 CSP 的支持非常少，甚至一直到 IE11 ( https://stackoverflow.com/questions/42937146/content-security-policy-does-not-work-in-internet-explorer-11 )

结果是，虽然这些步骤是很好的起点，但您绝对不能将它们作为您的主要安全措施：您仍然必须最终解决问题。获得一个好的自动扫描工具绝对是最好的入门方式。它会给你一些即时的行动项目。

部分解决方案

您可能有的另一个选择是在您的应用程序中全面放置 XSS 过滤。我通常不推荐这个，但我认为对你来说最好的选择是多层次的反应。这里的想法是您向应用程序引导过程添加一些代码，以检查从客户端传入的所有数据（url 数据、POST 数据、cookie、REQUEST 标头等）。然后您执行一些过滤以检测常见的 XSS 有效负载，如果发现则一起拒绝请求。

黑名单过滤的问题在于它可能非常不可靠。如果您阅读了OWASP XSS 过滤器规避备忘单，您会很好地了解可靠过滤 XSS 漏洞的难度。但是，这是一种针对每个请求获得一些保护的快速方法，因此在您的情况下可能是值得的。但是要记住的一个重要问题是，这通常会阻止所见即所得编辑器的工作。这对你来说可能是也可能不是问题。