security - 担心 XSS、CSRF、sql 注入(inject)、cookie 窃取是否足以覆盖网络安全？

Question

未受攻击的计算机上的 Web 应用程序在不安全的 WiFi 环境中容易受到 XSS、CRSF、sql 注入(inject)攻击和 cookie 窃取。

为了防止这些安全问题，有以下补救措施

• sql注入(inject):一个好的datamapper(比如linq-to-sql)不存在sql注入(inject)的风险(我天真的相信这一点吗？)
• CSRF:每个表单帖子均使用 <%:Html.AntiForgeryToken() %> 进行验证(这是 asp.net mvc 环境中的 token ，存储在 cookie 中并在服务器上进行验证)
• XSS:所有允许发布html的表单都会被转换，只允许bb代码，其余的都是编码的。所有可能的保存操作都是通过 post 事件完成的，因此流氓 img 标签应该不会产生任何效果
• cookie 窃取:https

我现在是否不会受到基于网络的黑客攻击(正确实现时)？或者我是否遗漏了网络开发中的一些其他安全问题？(操作系统平台或其他软件中可能存在的漏洞除外)

Answer 1

简单的答案是“不，你并非刀枪不入 - 没有人是刀枪不入!”

这是一个好的开始，但您还可以做一些其他的事情。您没有提到的主要问题是根据白名单验证不受信任的数据，这一点很重要，因为它涉及 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) .

除此之外，听起来您还了解许多重要原则。它不会让你刀枪不入，但这是一个好的开始。