我可以信任多少ASP.NET Web页面/ WebMatrix与XSS请求验证？

我已经阅读（而且即将达成协议）事实上，没有解决方案可以100％有效地抵御XSS攻击。看起来，我们希望的最好的办法就是停止“最”XSS攻击途径，并且可能会有很好的恢复和/或合法计划。最近，我一直在努力寻找一个良好的参考框架，以确定哪些不应该是可接受的风险。我可以信任多少ASP.NET Web页面/ WebMatrix与XSS请求验证？

看了这篇文章，由Mike Brind后（一篇很好的文章，顺便说一句）：

http://www.mikesdotnetting.com/Article/159/WebMatrix-Protecting-Your-Web-Pages-Site

我可以看到，使用HTML清洁剂，也可以在降低XSS的途径非常有效如果您需要用户输入未验证的攻击。

但是，在我的情况下，情况恰恰相反。我有一个（非常有限）CMS与Web界面。用户输入（被URL编码后）被保存到一个JSON文件中，然后在可查看的页面上被拾取（解码）。我在这里停止XSS攻击的主要方式是，您必须成为少数注册成员之一才能更改内容。通过记录注册用户，IP地址和时间戳，我觉得这种威胁大部分被缓解了，但是，我想使用try/catch语句来捕获由asp.net的默认请求验证器生成的YSOD，除了之前上述方法。

我的问题是：我可以信任这个验证程序多少？我知道它会检测标签（这部分CMS没有设置为接受任何标签，从逻辑上讲，所以我很好，如果检测到任何标签，就会抛出错误）。但是，这个天生的验证器检测到了什么（如果有的话）？

我知道XSS可以在没有触及角括号（或者完全标签，就此而言）的情况下实现，因为可以保存，编辑html源并随后从客户端计算机运行只是增加了一个额外的“onload ='BS XSS ATTACK'”给一些随机标签。

只是好奇，如果一个人确实希望将它用作其反XSS计划的一部分（很显然带有try/catch，所以用户看不到YSOD），这个验证程序可以被信任多少。这个验证器是否相当不错，但并不完美，或者这只是一个“最好的猜测”，即任何有足够知识的人都可以知道XSS，完全可以拥有足够的知识，证明这个验证并不重要。

-----------------------编辑---------------------- ---------

在这个网站...：http://msdn.microsoft.com/en-us/library/hh882339(v=vs.100).aspx

...我发现这个例子的网页页面。

var userComment = Request.Form["userInput"]; // Validated, throws error if input includes markup 

Request.Unvalidated("userInput"); // Validation bypassed 
Request.Unvalidated().Form["userInput"]; // Validation bypassed 

Request.QueryString["userPreference"]; // Validated 
Request.Unvalidated().QueryString["userPreference"]; // Validation bypassed;

每注释：“//验证，将引发错误，如果输入包括标记”我认为验证如果字符串包含被视为标记任何抛出一个错误。现在这个问题（对我来说）真的变成了：什么被认为是标记？通过测试我发现，一个尖括号不会引发错误，但如果有的话（我迄今已检测）谈到这个角度支架后，如

"<l"

似乎错误。然而，我确信它会做更多的检查，而且我希望看到请求验证程序眼中的内容是否有资格作为标记。

来源

2013-02-20 VoidKing

@All，我也发现了这个非常有用的链接（不回答原来的问题，但可以帮助其他未来的观众为防止对XSS一般）。 https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting))_Prevention_Cheat_Sheet – VoidKing 2013-02-20 19:43:35

我不完全明白你的观点。如果输入验证失败，您可以设置自定义错误页面让用户访问。你所说的“ysod”实际上只是用于开发，而不是用于生产，默认情况下，IIS和web.config配置为不显示它用于发布配置。 – Candide 2013-02-21 15:28:59

@Cideide是的，我明白你的意思了，当我想到它时，我不必使用try/catch。只是这种方法适用于我设置的当前页面。我也知道（除非在web.config中另行通知）YSOD不会向远程机器显示代码，但它仍然很丑，我不希望用户以这种方式看到错误（即，在YSOD上屏幕）。 – VoidKing 2013-02-21 18:25:08

我相信ASP.NET请求验证是相当值得信赖的，但不应该单靠它。对于某些项目，我可以让它提供一个额外的安全层。一般来说，最好使用广泛测试/使用的解决方案，而不是自己制作一个解决方案。如果“YSOD”（或自定义错误页面）成为我的客户端的问题，我通常只是禁用页面的.NET请求验证功能。

一旦这样做，我会小心确保我的输入已经过消毒，但更重要的是，我的输出编码为。因此，在我将用户输入的内容（或Web服务等 - 任何来自第三方的内容）推送给用户的任何地方，它都会被包装在Server.HtmlEncode（）中。这种方法现在已经运行了很多年了。

你微软的文档中提供的链接是相当不错的。要回答你关于什么被认为是标记的问题（或什么应该被视为标记）戴上你的黑客帽子，并检查出OWASP XSS逃避秘籍。

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#HTML_entities

来源

2013-02-21 15:20:15 mikey

这是另一个具有.NET请求验证的实际规避技术的链接。 http://www.securitysift.com/xss-and-cross-site-scripting-with-a-little-help-from-asp-net-and-ie9/ – mikey 2013-02-21 15:25:25

是Server.HtmlEncode（）方法的一种C＃方法（真的是asp.net的一部分，我敢肯定），它几乎可以将“＆”转换为“&”，“<”转换为“<”？此外，还有一个问题：网站的构建方式（这可能需要更改）JavaScript负责将第三个pary数据实际写入页面，因此其中包含将“>”编码为“>”的功能“等等。这可能是安全风险，因为这种编码是在客户端处理的？（就我而言，这不是一个大问题，因为只有少数注册用户可以访问）。 – VoidKing 2013-02-21 18:21:47

上的HTMLEncode，是的，看到http://msdn.microsoft.com/en-us/library/w3te6wfz%28v=vs.100%29.aspx – mikey 2013-02-21 18:41:15

我可以信任多少ASP.NET Web页面/ WebMatrix与XSS请求验证？

回答

相关问题