根据我对ASP.NET的作用以及我自己对各种XSS测试的个人测试的理解，我发现我的ASP.NET 4网站不需要任何XSS预防。
您认为ASP.NET 4.0网站是否需要添加XSS安全性而不是默认选项？我无法在我的文本字段中输入任何javascript或任何标签，然后立即将其打印到页面上。
答案 0 :(得分：10)
免责声明 - 这是基于对“可信输出”的非常偏执的定义，但是当涉及到网络安全时，我认为你不会太偏执。
取自以下链接的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文章陈旧，但仍然相关。
答案 1 :(得分：4)
对不起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相关的内容有很多其他信息。