然而，我以后是一个像思想一样的黑客检查表。完成开发后，您应该仔细阅读的简单操作列表，以确保解决方案安全。
(更新：我最感兴趣的是一个黑匣子清单 – “去一个页面，尝试这样的”这样的事情，但是一个白盒检查表也可能是感兴趣的。)
这是我到目前为止已经提出的一些事情：
安全BlackBox清单
>提交不正确/恶意的数据(这里的示例)，以确保通过javascript验证输入的类型，长度，格式和范围。
>关闭客户端验证并重复上述步骤，以确保
>您不仅可以使用javascript进行检查，还可以在服务器端进行验证
>输入在服务器上验证类型，长度，格式和范围
>免费表单输入被消毒
包含输入的输出用HtmlEncode和UrlEncode进行编码
>根据http://www.example.com/foo?bar=HugeAmountOfData在查询字符串中插入非常大量的数据，以确保约束输入并执行边界检查。
>通过GET访问POST操作，以确保“表单提交”操作仅限于POST。
>如果适用，请上传不正确的尺寸/格式的文件(巨大的文件，空文件，可重命名的扩展名等)，以确保正确处理上传。
>(如何从UI检查？)确保绝对URL用于导航。
>以不具有正确权限的用户身份访问URL，以确保通过操作/控制器属性显式测试权限。
>访问提供不存在的详细信息的URL(如不存在的产品ID，您无权访问的项目等)，以确保返回正确的错误(404或403等)。
>通过HTTP访问敏感页面，以确保它仅通过HTTPS提供。
安全白箱清单
Web层。
>在调试模式下，打破代码，使其抛出异常，以确保其安全失败。确保您捕获异常并记录详细的消息，但不会向客户端泄漏信息。
>如果适用，请确保MVC操作仅限于POST / GET，特定用户角色以及其他任何操作。
>确保POST操作伴随着[ValidateAntiForgeryToken]属性，以防止跨站点请求伪造攻击。
>确保Response.Write(直接或间接)从未用于显示用户输入。
>确保敏感数据不会在查询字符串或表单字段中传递。
>确保您的安全决策不依赖于HTTP头信息。
服务层。
>在调试模式下，打破代码，使其抛出异常，以确保其安全失败。确保您捕获异常并记录详细的消息，但不会向客户端泄漏信息。
>确保如果更新在事务中操作的数据库中的任何内容。
数据库层。
>确保检索存储过程不使用SELECT *，但始终明确指定列的列表。
>确保更新/删除存储过程在事务中(通过@@ TRANCOUNT等)运行，并显式提交/回滚它。
注释？更正？缺少步骤？
使其成为社区wiki，随时可以随意编辑。
解决方法
黑色：DoS攻击 – 使用tinyget或类似的模拟DoS攻击，看看你的应用程序的作用。
黑色：规范化攻击。提到一点，可能是特殊的焦点可以在一个目录遍历攻击的情况下下载。
白色：敏感信息使用Cookie？请参阅Cookie不用于敏感数据，并且不会在意图间隔内本地持久存储。
黑色：在临时IE / XYZ文件夹中嗅探Cookie。
黑色：再次使用scripted tinyget或尝试手动查看是否强力密码猜测可以工作，或者您的应用程序有智能延迟/拒绝密码猜测攻击。
黑色：进行任何攻击，看看管理员是否自动通知攻击，或者只有攻击者才知道攻击。
“确保您的安全决策不依赖于HTTP标头信息” – http标头用于ntml / kerberos身份验证？可能只是不要愚蠢地使用它们，不要发明或依靠引用者等等？
一般：使用商业黑/白箱安全扫描仪，可能是昂贵的，但可能很难做安全回归测试，否则。
