是否担心 XSS、CSRF、sql 注入、cookie 窃取足以覆盖网络安全？答案

【问题标题】：Is worrying about XSS,CSRF,sql injection, cookie stealing enough to cover web-security?是否担心 XSS、CSRF、sql 注入、cookie 窃取足以覆盖网络安全？
【发布时间】：2011-08-12 09:36:10
【问题描述】：

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

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

sql 注入：好的数据映射器（如 linq-to-sql）没有 sql 注入的风险（我是否天真相信这一点？）
CSRF：每个表单帖子都使用进行验证（这是存储在 cookie 中并在服务器上验证的 asp.net mvc 环境中的令牌）
XSS：每一个允许发布html的表单都会被转换，只允许bb代码，其余的都是编码的。所有可能的保存操作都是通过发布事件完成的，因此流氓 img 标签应该没有效果
cookie 窃取：https

我现在是否可以免受基于网络的黑客攻击（如果实施得当）？还是我在网络开发中遗漏了其他一些安全问题？（除了操作系统平台或其他软件中可能存在的漏洞）

【问题讨论】：

仅仅担心它可能是不够的。 :)
有专门的地方发这种问题：security.stackexchange.com

标签： security cookies xss sql-injection csrf

【解决方案1】：

关于你没有提到的：

您错过了 MVC 框架中的危险攻击：Over Posting Attack

您还错过了最烦人的威胁：Denial of Service

你也应该足够关注file uploads（如果有的话......）等等......

关于你提到的：

XSS 真的很浪费，而且更烦人。有几种类型的编码，包括Html Encoding、Javascript Encoding、CSS Encoding、Html Attribute Encoding、Url Encoding、...

它们中的每一个都应该在适当的地方执行到适当的内容 - 即在所有情况下仅对内容进行 Html 编码是不够的。

而 XSS 最烦人的地方在于，在某些情况下您应该执行组合编码（即首先 JavascriptEncode 然后 HtmlEncode...!!!）

看看下面的链接，更加熟悉一个叫做 XSS 的噩梦......！！！

XSS Filter Evasion Cheat Sheet - OWASP

【讨论】：

【解决方案2】：

绝对不够！在开发 Web 应用程序时，您还必须牢记其他几个安全问题。要获得概览，您可以使用OWASP Top-Ten

我认为在考虑网络安全时，这是一篇非常有趣的文章：What should a developer know before building a public web site? 有一个关于安全性的部分包含了您在开发 Web 应用程序时面临的大多数威胁的良好链接。

在考虑安全性时要牢记的最重要的一点是： 永远不要相信用户输入！

[我正在回答这个“老”问题，因为我认为它始终是一个实际的话题。]

【讨论】：

【解决方案3】：

我现在是否可以免受基于网络的黑客攻击？

因为，无论你多么优秀，每个人都会犯错，所以答案是否定的。您几乎可以肯定忘记清理某些输入，或使用一些防伪令牌。如果您现在还没有，您或其他开发人员会随着您的应用程序变得更大。

这是我们使用框架的原因之一 - 例如，MVC 将自动生成反 CSRF 令牌，而 LINQ-to-SQL（如您所述）将清理数据库的输入。所以，如果你还没有使用一个框架来让 anti-XSS 和 anti-CSRF 衡量默认，你现在应该开始了。

当然，这些可以保护您免受这些特定威胁的侵害，但永远不可能保护您免受所有威胁。例如，如果您有一个不安全的 SQL 连接密码，那么有人可能会暴力破解您的数据库密码并获得访问权限。如果你不保持你的 .Net/SQL-Server/everything 版本是最新的，你可能会成为在线蠕虫的受害者（即使你这样做了，它仍然可能是零日） em>。

甚至还有一些您无法通过软件解决的问题：脚本小子可以对您的网站进行 DDOS。您的服务器公司可能会破产。一个阴暗的竞争对手可以简单地把对冲快船带到你的互联网线上。你的仓库可能会被烧毁。开发人员可以将源代码出售给俄罗斯的公司。

重点是，您永远无法防范一切 - 您只能防范特定威胁。

【讨论】：

【解决方案4】：

简单的答案是“不，你不是无懈可击的 - 没有人是！”

这是一个好的开始，但您还可以做一些其他事情。您没有提到的主要是针对白名单验证不受信任的数据，这很重要，因为它跨越了多个漏洞，例如 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 security analyser 将您的 web.config 放入，这将有助于为您指明正确的方向。

另一种 CSRF 防御——尽管会影响可用性——是 CAPTCHA。显然，您希望谨慎使用它，但如果您有任何想要保护的非常关键的功能，这将很快阻止它。更多内容请参见OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF)。

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

【讨论】：

【解决方案5】：

This 是 Web 攻击的权威指南。另外，我建议您针对您的网络应用使用Metasploit。

【讨论】：