除了以下内容之外，还需要验证哪些内容？这是我的问题。
对网站的任何输入进行适当验证非常重要：
文本框等 - 使用.NET验证器（如果验证器不合适，则使用自定义代码）
Querystring或Form值 - 使用手动验证（转换为特定类型，边界检查等）
这与XSS可以揭示的问题有关。
基本上，您必须验证某人可能会篡改的任何输入：
表单回发（主要是.NET控件 - 这些可以通过.NET验证控件进行验证。如果您在所有页面上启用了请求验证，这样可以降低风险）
QueryString值
Cookie值
HTTP标头
Viewstate（只要您启用了ViewState MAC，就会自动为您完成）
Javascript（可以查看和更改所有JS，因此需要确保JavaScript不会处理任何关键功能 - 即始终启用服务器端验证）
答案 0 :(得分：5)
Web应用程序可能出现很多问题。你的清单非常全面，虽然它是重复的。 http规范只声明，GET，POST，Cookie和Header。有许多不同类型的POST，但它们都在请求的同一部分。
对于你的列表，我还会添加与文件上传有关的所有内容，这是一种POST。例如，文件名，mime类型和文件的内容。我会启动一个像Wireshark这样的网络监控应用程序，请求中的所有内容都应该被认为是有害的。
永远不会有一个适合所有验证功能。如果你正在合并sql注入和xss卫生功能，那么你可能遇到麻烦。我建议使用自动化测试您的网站。像Sitewatch这样的免费服务或像skipfish这样的开源工具会检测您错过的攻击方法。
另外，请注意。使用MAC和/或加密传递视图状态是对密码术的严重滥用。当没有其他解决方案时，密码术是使用的工具。通过使用MAC或加密，您可以为攻击者打开强制此值或使用oracle padding攻击等利用您的权利打开大门。视图状态应由服务器跟踪，故事期末。
答案 1 :(得分：1)
我建议用一种不同的方式来看待与你在这里所拥有的问题正交的问题（因此并不是不相容的，因为没有理由你无法检查它以防万一与你错过的另一个）。
在任何验证中重要的两件事是：
现在，你提到的大部分内容都适用于第一个类别。您忽略的Cookie适合第二个，查询和如果您使用Server.Execute或类似的方式传递给另一个处理程序，则发布信息。
第二类是最有争议的。
一方面，如果给定的处理程序（.aspx页面，IHttpHandler等）忽略了将来某个时候可能被另一个处理程序使用的cookie，那么它主要取决于其他处理程序验证它。
另一方面，假设其他层有安全漏洞并且您不应该信任它们是正确的，即使您自己编写它们（特别是如果您写的话），总是很好他们自己！）
中间位置，如果有可能存在5个不同的状态，则某些持久性数据可以有效地存在，但只有3个在某个特定代码被命中时才有意义，它可能会验证它是否属于其中一个3个州，即使这不会对该特定代码构成风险。
完成后，我们将专注于第一类。
Querystrings，表单数据，回发，标题和cookie都属于来自用户的相同类别（无论他们是否知道）。实际上，他们有时会以不同的方式看待同一件事。
其中，有一个我们将以任何方式实际工作的子集。
其中，每个此类项目都有一系列合法价值。
其中，整个项目有一系列合法的价值组合。
验证因此成为：
现在，当我们来到这里时，通常最好不要尝试捕捉某些攻击。例如，避免将'传递给SQL的值不太好。相反，我们有三种可能性：
在值中包含'无效，因为它不属于那里（例如，某个值只能是＆＃34; true＆＃34;或＆＃ 34; false＆＃34;，或者来自其中没有一个包含'的值的集合列表。在这里，我们发现它不属于合法价值观的事实，而忽略了攻击的确切性质（因此也受到我们甚至不知道的其他攻击的保护！）。
它作为人类输入有效，但不是我们将使用的。这里的一个例子是大量的（在某些文化中'用于分隔数千）。在这里，我们将两者都标准化为＆＃34; 123,456,789＆＃34;和＆＃34; 123＆＃39; 456＆＃7; 789＆＃34;到123456789，并且在此之前不要关心它是什么样的，只要我们能够有意义地这样做（输入不是＆＃34;鱼＆＃34;或者数字超出范围手头案件的合法价值）。
它的有效输入。如果你的应用程序在名称字段中阻止撇号以试图阻止SQL注入，那么它就会有错误，因为那里有撇号的实名。在这种情况下，我们考虑＆＃34; d＆＃39; Eath＆＃34;和＆＃34;格雷迪＆＃34;通过正确转义（理想情况下，通过使用API为我们执行此操作的数据访问）来处理有效输入并处理'在SQL中具有重要意义的事实。
使用ASP.NET的第三点的经典示例是阻止＆＃34;可疑＆＃34;使用<和>输入 - 这会导致大量ASP.NET页面错误。当然，通过不恰当地接受它来阻止不恰当的错误比错误更好，但默认情况是那些没有考虑过验证并试图阻止他们自己伤害太多的人。由于 正在考虑验证，因此您应该考虑是否适合关闭自动验证，然后以适合您的方式处理<和>给予使用。
另请注意，我还没有说过javascript。我没有验证javascript（除非我实际上接收它），我忽略它。我假装它不存在然后我不会错过它的验证可能被篡改的情况。假装你的这一层也不存在。最终，客户端验证是为了拯救好人犯下诚实错误的时间，而不是贬低坏人。
出于类似的原因，最好不要通过浏览器进行测试。使用Fiddler构建命中符合要检查的验证点。这样，所有客户端验证都被绕过，并且您以与攻击者相同的方式查看服务器。
最后，请记住，100％完美验证的页面不一定安全。例如。如果你的验证是完美的，但你的身份验证很差，那么有人可以发送＆＃34;有效＆＃34;它的代码只是 - 或许更多 - 作为更经典的SQL注入XSS代码而讨厌。除了这里讨论的验证只是这个难题的一部分之外，其他问题也会出现在其他问题上。