我已经阅读（并且正在接受）这样一个事实，即没有任何解决方案可以 100% 有效地抵御 XSS 攻击。似乎我们所能期望的最好的结果就是阻止“大多数” XSS 攻击途径，并且可能有良好的恢复和/或法律计划。最近，我一直在努力寻找一个好的参考框架，以确定什么应该和不应该是可接受的风险。
阅读完 Mike Brind 的这篇文章后（一篇非常好的文章，顺便说一句）：
http://www.mikesdotnetting.com/Article/159/WebMatrix-Protecting-Your-Web-Pages-Site
我可以看到，如果您需要未经验证的用户输入，使用 html sanitizer 也可以非常有效地降低 XSS 攻击的途径。
但是，就我而言，情况恰恰相反。我有一个（非常有限的）带有 Web 界面的 CMS。用户输入（经过 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"
似乎出错了。但是，我确信它会做更多的检查，而且我很想看看在请求验证器的眼中什么可以作为标记，什么不可以作为标记。