在 Web 编程方面，我仍然很年轻，我大部分时间都花在客户端应用程序上。所以我很好奇我应该在我的网站中害怕/测试的常见漏洞。
Brian Leahy
问问题
11934 次
13 回答
35
我在这里发布了OWASP Top 2007 缩写列表，这样人们就不必查看另一个链接，以防万一来源失效。
跨站脚本 (XSS)
- 每当应用程序获取用户提供的数据并将其发送到 Web 浏览器而不首先验证或编码该内容时，就会出现 XSS 缺陷。XSS 允许攻击者在受害者的浏览器中执行脚本，该脚本可以劫持用户会话、破坏网站、可能引入蠕虫等。
注塑缺陷
- 注入缺陷，尤其是 SQL 注入，在 Web 应用程序中很常见。当用户提供的数据作为命令或查询的一部分发送到解释器时，就会发生注入。攻击者的恶意数据诱使解释器执行意外命令或更改数据。
恶意文件执行
- 易受远程文件包含 (RFI) 影响的代码允许攻击者包含恶意代码和数据，从而导致破坏性攻击，例如整个服务器受损。恶意文件执行攻击会影响 PHP、XML 和任何接受用户文件名或文件的框架。
不安全的直接对象引用
- 当开发人员将对内部实现对象（例如文件、目录、数据库记录或键）的引用公开为 URL 或表单参数时，就会发生直接对象引用。攻击者可以操纵这些引用以在未经授权的情况下访问其他对象。
跨站请求伪造 (CSRF)
- CSRF 攻击迫使登录的受害者的浏览器向易受攻击的 Web 应用程序发送预认证请求，然后迫使受害者的浏览器执行恶意操作以使攻击者受益。CSRF 可以像它所攻击的 Web 应用程序一样强大。
信息泄露和错误处理不当
- 应用程序可能会无意中泄漏有关其配置、内部工作的信息，或通过各种应用程序问题侵犯隐私。攻击者利用此弱点窃取敏感数据，或进行更严重的攻击。
损坏的身份验证和会话管理
- 帐户凭据和会话令牌通常没有得到适当的保护。攻击者会破坏密码、密钥或身份验证令牌以冒用其他用户的身份。
不安全的加密存储
- Web 应用程序很少正确使用加密功能来保护数据和凭证。攻击者使用受保护较弱的数据进行身份盗用和其他犯罪，例如信用卡欺诈。
不安全的通信
- 当需要保护敏感通信时，应用程序经常无法加密网络流量。
未能限制 URL 访问
- 通常，应用程序仅通过阻止向未经授权的用户显示链接或 URL 来保护敏感功能。攻击者可以利用此弱点通过直接访问这些 URL 来访问和执行未经授权的操作。
-亚当
于 2008-09-07T00:09:50.323 回答
10
bool UserCredentialsOK(User user)
{
if (user.Name == "modesty")
return false;
else
// perform other checks
}
于 2008-08-22T18:25:39.307 回答
10
每个人都会说“SQL 注入”，因为它是听起来最可怕的漏洞，也是最容易引起你注意的漏洞。跨站点脚本 (XSS) 将排在第二位，因为它也很容易理解。“输入验证不佳”不是漏洞，而是对安全最佳实践的评估。
让我们从不同的角度尝试一下。以下是在 Web 应用程序中实现时可能会搞砸的功能：
动态 SQL（例如，UI 查询构建器）。到目前为止，您可能知道在 Web 应用程序中使用 SQL 的唯一可靠安全的方法是使用参数化查询，其中您将查询中的每个参数显式绑定到一个变量。我看到网络应用程序最常违反此规则的地方是恶意输入不是明显的参数（如名称），而是查询属性。一个明显的例子是您在搜索网站上看到的类似 iTunes 的“智能播放列表”查询构建器，其中诸如 where 子句运算符之类的内容直接传递到后端。另一个需要解决的问题是表列排序，您将在其中看到诸如 DESC 之类的内容暴露在 HTTP 参数中。
上传文件。文件上传会让人们感到困惑，因为文件路径名看起来很像 URL 路径名，并且因为 Web 服务器只需将 URL 指向文件系统上的目录就可以轻松实现“下载”部分。我们测试的 10 个上传处理程序中有 7 个允许攻击者访问服务器上的任意文件，因为应用程序开发人员假设文件系统“open()”调用的权限与查询的权限相同。
密码存储。如果您的应用程序可以在我丢失原始密码时将其寄回给我，那么您就失败了。密码存储有一个安全可靠的答案，那就是 bcrypt；如果您使用的是 PHP，您可能需要 PHPpass。
随机数生成。对 Web 应用的经典攻击：重置另一个用户的密码，并且，由于该应用正在使用系统的“rand()”函数，该函数不是加密强的，因此密码是可预测的。这也适用于您进行加密的任何地方。顺便说一句，你不应该这样做：如果你在任何地方依赖加密，你很可能很容易受到攻击。
动态输出。人们过于相信输入验证。您清除所有可能元字符的用户输入的机会很低，尤其是在现实世界中，元字符是用户输入的必要部分。更好的方法是使用一致的机制过滤数据库输出并将它们转换为 HTML 实体，如 quot、gt 和 lt。Rails 会自动为您执行此操作。
电子邮件。许多应用程序实现了某种出站邮件功能，使攻击者能够创建一个匿名帐户，或者根本不使用任何帐户，将攻击者控制的电子邮件发送到任意电子邮件地址。
除了这些功能之外，您在应用程序中可能犯的第一个错误是在某处公开数据库行 ID，以便用户 X 只需将数字从“5”更改为“6”即可查看用户 Y 的数据。
于 2008-09-10T21:33:26.360 回答
3
SQL 注入攻击。它们很容易避免，但太常见了。
从未有过（我提到过“曾经”吗？）信任从表单元素传递给您的用户信息。如果您的数据在传递到应用程序的其他逻辑层之前没有经过审查，那么您不妨将站点的密钥交给街上的陌生人。
您没有提及您在哪个平台上，但如果在 ASP.NET 上，请从优秀的 Scott Guthrie 和他的文章“提示/技巧：防范 SQL 注入攻击”开始。
之后，您需要考虑您将允许用户提交到并最终从您的数据库中提交出的数据类型。如果您允许 HTML 被插入然后再呈现，那么您就很容易受到跨站脚本攻击（称为 XSS）的攻击。
这就是我想到的两个，但我们自己的 Jeff Atwood 在Coding Horror上有一篇很好的文章，其中评论了“软件安全的 19 条致命罪”一书。
于 2008-08-22T18:31:50.150 回答
3
这里的大多数人都提到了 SQL 注入和 XSS，这是正确的，但不要被愚弄 - 作为 Web 开发人员，您需要担心的最重要的事情是 INPUT VALIDATION，这就是 XSS 和 SQL 注入的来源。
例如，如果您有一个只接受整数的表单字段，请确保您在客户端和服务器端都实现了一些东西来清理数据。
检查并仔细检查任何输入数据，特别是如果它最终会出现在 SQL 查询中。我建议构建一个转义函数并将其包裹在任何进入查询的内容中。例如：
$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";
同样，如果您要在网页上显示任何用户输入的信息，请确保您已剥离任何 <script> 标签或任何其他可能导致 Javascript 执行的标签（例如 onLoad= onMouseOver= 等标签上的属性）。
于 2008-08-23T11:03:30.393 回答
1
于 2008-08-22T18:27:52.470 回答
0
最常见的可能是数据库注入攻击和跨站点脚本攻击；主要是因为这些是最容易完成的（这可能是因为那些是程序员最懒惰的）。
于 2008-08-22T18:24:17.720 回答
0
您甚至可以在此站点上看到，您将要处理的最具破坏性的事情涉及将代码注入到您的应用程序中，因此 XSS（跨站点脚本）和 SQL 注入（@Patrick 的建议）是您最关心的问题。基本上，您将要确保如果您的应用程序允许用户注入任何代码，它会受到监管和测试，以确保只有您确定要允许的内容（html 链接、图像等） ) 被传递，并且不执行任何其他操作。
于 2008-08-22T18:26:10.493 回答
0
SQL 注入。跨站脚本。
于 2008-08-22T18:28:50.313 回答
0
使用存储过程和/或参数化查询将大大有助于保护您免受 sql 注入。也不要让您的网络应用程序以 sa 或 dbo 身份访问数据库 - 设置标准用户帐户并设置权限。
AS for XSS（跨站点脚本） ASP.NET 有一些内置保护。最好的办法是使用验证控件和正则表达式过滤输入。
于 2008-08-22T18:33:56.013 回答