ASP.NET 4 网站是否需要额外的 XSS 安全性？答案

【问题标题】：Do I need extra XSS security for ASP.NET 4 websites?ASP.NET 4 网站是否需要额外的 XSS 安全性？
【发布时间】：2011-08-01 20:28:10
【问题描述】：

根据我对 ASP.NET 所做的了解以及我自己对各种 XSS 测试的个人测试，我发现我的 ASP.NET 4 网站不需要任何 XSS 预防。

您认为 ASP.NET 4.0 网站是否需要比其默认选项添加任何 XSS 安全性？我无法在我的文本字段中输入任何 javascript 或任何标签，然后立即打印到页面上。

【问题讨论】：

标签： asp.net security xss

【解决方案1】：

免责声明 - 这是基于对“可信输出”的非常偏执的定义，但在网络安全方面，我认为您不能过于偏执。

取自链接到下面的 OWASP 页面： 不受信任的数据最多通常来自 HTTP 请求的数据，以 URL 的形式参数、表单字段、标题或 cookie。但是来自的数据数据库、Web 服务和其他来源经常不受信任从安全的角度来看。也就是说，它可能并不完美验证。

在大多数情况下，如果您从任何来源获取输入并将其输出到 HTML，则确实需要更多保护。这包括从文件、数据库等中检索到的数据——不仅仅是您的文本框。您可以拥有一个完全被锁定的网站，并让某人通过其他工具直接访问数据库并能够插入恶意脚本。

即使您从只有受信任的用户才能输入数据的数据库中获取数据，您也永远不知道该受信任的用户是否会无意中从网站复制并粘贴一些恶意脚本。

除非您绝对肯定地信任将在您的网站上输出的任何数据，并且脚本不可能无意中（或在攻击者或心怀不满的员工的情况下恶意地）将危险数据放入系统中，否则您应该清理所有输出。

如果您还没有，请熟悉这里的信息：https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

并检查网站上的其他已知威胁。

如果您错过了它，Microsoft.AntiXss 库是一个非常好的工具供您使用。除了 HtmlEncode 函数的更好版本之外，它还具有诸如 GetSafeHtmlFragment() 之类的不错的功能，当您希望在输出中包含不受信任的 HTML 并对其进行清理时。这篇文章展示了正确的用法：http://msdn.microsoft.com/en-us/library/aa973813.aspx 这篇文章很旧，但仍然相关。

【讨论】：

是的，那么清理的最佳方法是什么，我觉得 ASP.NET 已经清理了来自文本框的所有输入，所以我不知道为什么我需要做任何额外的事情。那我该怎么办， Html.Encode() 所有文本框数据都打印在页面上？我以为 ASP.NEt 已经这样做了。
我在您输入评论时添加了另一段 - 该段回答了问题。
ASP.NET 不会清理来自文本框的数据 - 它会过滤可能进入的内容。当输出从服务器返回给用户时，消毒就完成了。
有人说 microsoft AntiXSS 有点矫枉过正，在本网站的另一个页面上是不必要的，因为使用 HtmlEncode 等进行过滤的标准方法已经足够了。
我不同意 - 有充分的理由 - 在此处查看我对该主题的问题的回答：stackoverflow.com/questions/1608854/…

【解决方案2】：

抱歉，Dexter，ASP.NET 4 网站确实需要 XSS 保护。您可能认为内置的请求验证就足够了，虽然它做得很好，但它并不是万无一失的。根据可接受值的白名单验证所有输入仍然很重要。

另一件事是请求验证仅对反射型 XSS 有任何好处，即嵌入在请求中的 XSS。它对持久性 XSS 完全没有帮助，因此如果您有其他数据源的输入验证不那么严格，那么您就有风险了。因此，您总是需要对您的输出进行编码和，以便为正确的标记上下文（HTML、JavaScript、CSS）进行编码。 AntiXSS 非常适合这个。

在OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS) 中有更多与 ASP.NET 相关的具体信息。

【讨论】：

如果 AntiXSS 不是一个选项怎么办？
如果 AntiXSS 不是一个选项，请使用 Server.HtmlEncode()。它不如 Microsoft.Applicaiton.Security.AntiXss.HtmlEncode() 灵活和强大，但它是朝着正确方向迈出的一步。
正如 David 所说，但也请记住，没有本地 .NET 方法可以为 JavaScript 或 CSS 进行编码，因此根据您的上下文，您可能会遇到问题。但是为什么 AntiXSS 不是一种选择呢？
inbuilt request validation .. whilst it does an excellent job, it's not foolproof - 你能举个例子来证明你的主张吗？我测试了各种组合，.net 都拒绝了它们？（而且我不是在谈论您回答的第二部分关于来自其他数据源的数据或直接入侵数据库的人）
当然，这是一个例子：portcullis-security.com/184.php 请记住，有很多很多 XSS 向量，其中很多不是“有效”的 HTML，它们在不同的浏览器中表现不同。这里有一些很好的例子：ha.ckers.org/xss.html