我和我的同事一直在争论如何最好地保护自己 来自XSS攻击，但仍保留输入的HTML字符 进入我们软件的领域。
对我而言，理想的解决方案是接受数据（关闭ASP .NET 请求验证）当用户输入它时，将其丢入数据库 正如他们进入它一样。然后，每当你在上面显示数据 网页，HTML编码。这种方法的问题在于有一个 有一天某个地方的开发人员很可能会忘记 HTML编码某处值的显示。巴姆！ XSS漏洞。
提出的另一个解决方案是关闭请求验证 并删除任何HTML用户在存储到数据库之前输入的内容 使用正则表达式。开发者仍然需要对事物进行HTML编码以进行显示， 但是既然你已经删除了任何HTML标签，即使开发人员忘记了，我们也是如此 认为这样会安全。这样做的缺点是用户无法进入 HTML标记到描述，字段和事物中，即使它们也是如此 显然想要，或者他们可能不小心粘贴在电子邮件地址中 被＆包围＆GT;并且正则表达式不会捡起来......无论如何。它 螺钉与数据，这是不理想的。
我们必须记住的另一个问题是系统已经存在 建立在对围绕此任何一种策略的承诺的恐惧之上。和 有一次，一些开发者在它之前写了一些HTML编码数据的页面 进入数据库。所以一些数据可能已经是HTML 在数据库中编码，一些数据不是 - 这是一团糟。我们做不到 真正相信来自数据库的任何数据都是安全的 在浏览器中。
我的问题是：如果你是理想的解决方案 从头开始构建一个ASP .NET Web应用程序，这将是一件好事 根据我们的情况，我们的方法是什么？
答案 0 :(得分：2)
使用正则表达式去除html很容易失败，很难弄清楚。如果要清理HTML输入，最好使用actual parser来强制执行严格的XML合规性。
在这种情况下，我要做的是在数据库中存储两个字段：clean和raw用于数据。当用户想要编辑其内容时，您将向他们发送原始数据。提交更改后，您将对其进行清理并将其存储在clean字段中。然后，开发人员在将内容输出到页面时只使用clean字段。我甚至会指出原始字段dangerousRawContent的名称，因此显然在引用该字段时必须小心。
此技术的另一个好处是，您可以在以后使用改进的解析器重新清理原始数据，而不会丢失原先预期的内容。
答案 1 :(得分：1)
假设您继续将HTML直接存储在数据库中，在ASP.NET / MVC Razor中，HTML编码是自动完成的，因此您的疏忽开发人员必须真正超越责任的要求才能引入XSS。使用标准的webforms（或webform视图引擎），您可以强制开发人员使用<%:语法，这将完成同样的事情。 （虽然开发人员会有更多的疏忽风险）
此外，您可以考虑仅选择性地禁用请求验证。 真的是否需要支持每个请求？据推测，绝大多数请求都不需要保留（或允许）HTML。