为了防止这些安全问题,有以下补救措施
> sql注入：一个好的数据映射器(比如linq-to-sql)没有sql注入的风险(我真的相信这个吗？)
> CSRF：每个表单帖子都使用<％：Html.AntiForgeryToken()％>进行验证. (这是asp.net mvc环境中的一个令牌,存储在cookie中并在服务器上验证)
> XSS：允许发布html的每个表单都被转换,只允许bb代码,其余的都是编码的.所有可能的保存操作都是通过post事件完成的,因此rogue img标签应该没有任何效果
> cookie偷窃：https
我现在无法进行基于网络的黑客攻击(正确实施时)？或者我是否在Web开发中遗漏了一些其他安全问题？(OS平台或其他软件中可能出现的漏洞除外)
解决方法
这是一个良好的开端,但您还可以做其他一些事情.您未提及的主要问题是针对白名单验证不受信任的数据,这很重要,因为它跨越多个漏洞,例如sqli和XSS.请查看OWASP Top 10 for .NET developers part 1: Injection,特别是“所有输入必须根据可接受的值范围的白名单进行验证”部分.
接下来,您应该将最小特权原则应用于连接到sql Server的帐户.请参阅上一个链接中此名称下的标题.
鉴于您正在使用ASP.NET,请确保请求验证保持打开状态,如果您绝对需要禁用它,请在页面级别执行此操作.更多关于这一点在Request Validation,DotNetNuke and design utopia.
对于输出编码,主要是确保您对正确的上下文进行编码. HTML编码！= JavaScript编码！= CSS编码.更多关于OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS).
对于cookie,只使它们成为HTTP,如果可能的话,只允许它们安全地提供(如果你很乐意只运行HTTPS).尝试将您的web.config放入web.config security analyser,这将有助于您找到正确的方向.
另一个CSRF防御 – 虽然具有可用性影响 – 是CAPTCHA.显然你想要谨慎使用它,但是如果你有任何你想要保护的关键功能,那么它就会非常迅速地停止.更多在OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF).
除此之外,听起来你已经意识到许多重要的原则.它不会让你无懈可击,但它是一个好的开始.
