我应该了解哪些常见的 Web 漏洞？[关闭]

这三个是最重要的：

• 跨站点请求伪造
• 跨站点脚本
• SQL注入

最常见的可能是数据库注入攻击和跨站点脚本攻击;主要是因为这些是最容易完成的（这可能是因为这些是程序员最懒惰的）。

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}   

你甚至可以在这个网站上看到，你所关注的最具破坏性的事情涉及代码注入到你的应用程序中，所以XSS（跨站点脚本）和SQL注入（@Patrick的建议）是你最关心的问题。 基本上，你要确保，如果你的应用程序允许用户注入任何代码，它就会受到监管和测试，以确保只有你确定要允许的东西（html链接、图像等）才会被传递，而没有其他任何内容被执行。

这也是 wordpress 的核心开发人员之一关于安全性的简短介绍。

wordpress 中的安全性

它涵盖了 Web 应用程序中的所有基本安全问题。

SQL 注入。跨站点脚本。

SQL注入攻击。它们很容易避免，但太常见了。

NEVER EVER EVER（我提到过“曾经”吗？）信任从表单元素传递给您的用户信息。如果你的数据在传递到应用程序的其他逻辑层之前没有经过审查，你不妨把你网站的密钥交给街上的陌生人。

你没有提到你在哪个平台上，但如果在 ASP.NET，请从优秀的 Scott Guthrie 和他的文章“提示/技巧：防范 SQL 注入攻击”开始。

之后，您需要考虑允许用户提交到您的数据库并最终提交出您的数据库的数据类型。如果允许插入 HTML，然后稍后再显示，则很容易受到跨站点脚本攻击（称为 XSS）。

这是我想到的两个，但是我们自己的杰夫·阿特伍德（Jeff Atwood）在Coding Horror上发表了一篇很好的文章，评论了《软件安全的19宗罪》一书。

使用存储过程和/或参数化查询将大大有助于保护您免受 sql 注入的影响。此外，不要让 Web 应用以 sa 或 dbo 身份访问数据库 - 设置标准用户帐户并设置权限。

至于 XSS（跨站点脚本），ASP.NET 有一些内置的保护措施。最好的办法是使用验证控件和正则表达式过滤输入。

OWASP 列出了值得关注的 10 大 Web 攻击，此外还有大量其他有用的 Web 开发安全信息。

我不是专家，但从我目前了解到的情况来看，黄金法则是不要信任任何用户数据（GET、POST、COOKIE）。常见的攻击类型以及如何自救：

1. SQL 注入攻击：使用准备好的查询
2. 跨站点脚本：在不先过滤/转义的情况下不向浏览器发送任何用户数据。这也包括存储在数据库中的用户数据，这些数据最初来自用户。

这里的大多数人都提到了 SQL 注入和 XSS，这有点正确，但不要被愚弄 - 作为 Web 开发人员，您需要担心的最重要的事情是 INPUT VALIDATION，这是 XSS 和 SQL 注入的根源。

例如，如果你有一个只接受整数的表单字段，请确保你在客户端和服务器端都实现了一些东西来清理数据。

检查并仔细检查任何输入数据，尤其是当它最终出现在 SQL 查询中时。我建议构建一个转义函数，并将其包装在查询中的任何内容周围。例如：

$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";

同样，如果您要在网页上显示任何用户输入的信息，请确保您已经剥离了任何 <script> 标签或任何其他可能导致 Javascript 执行的内容（例如标签上的 onLoad= onMouseOver= 等属性）。

我在这里发布了 OWASP Top 2007 缩写列表，这样人们就不必查看另一个链接，以防来源出现故障。

跨站点脚本 （XSS）

• 每当应用程序获取用户提供的数据并将其发送到 Web 浏览器而不首先验证或编码该内容时，就会发生 XSS 缺陷。XSS 允许攻击者在受害者的浏览器中执行脚本，这些脚本可以劫持用户会话、破坏网站、可能引入蠕虫等。

注塑缺陷

• 注入缺陷，尤其是 SQL 注入，在 Web 应用程序中很常见。当用户提供的数据作为命令或查询的一部分发送到解释器时，就会发生注入。攻击者的恶意数据诱使解释器执行意外命令或更改数据。

恶意文件执行

• 易受远程文件包含 （RFI） 攻击的代码允许攻击者包含恶意代码和数据，从而导致毁灭性攻击，例如完全破坏服务器。恶意文件执行攻击会影响 PHP、XML 和任何接受用户文件名或文件的框架。

不安全的直接对象引用

• 当开发人员将对内部实现对象（如文件、目录、数据库记录或键）的引用公开为 URL 或表单参数时，就会发生直接对象引用。攻击者可以在未经授权的情况下操纵这些引用来访问其他对象。

跨站点请求伪造 （CSRF）

• CSRF 攻击会强制登录受害者的浏览器向易受攻击的 Web 应用程序发送预身份验证请求，然后强制受害者的浏览器执行敌对操作，以使攻击者受益。CSRF 可以像它攻击的 Web 应用程序一样强大。

信息泄露和错误处理不当

• 应用程序可能会无意中泄露有关其配置、内部工作的信息，或者通过各种应用程序问题侵犯隐私。攻击者利用此漏洞窃取敏感数据，或进行更严重的攻击。

身份验证和会话管理中断

• 帐户凭据和会话令牌通常没有得到适当的保护。攻击者会破坏密码、密钥或身份验证令牌，以冒充其他用户的身份。

不安全的加密存储

• Web 应用程序很少正确使用加密函数来保护数据和凭据。攻击者使用保护较弱的数据进行身份盗窃和其他犯罪，例如信用卡欺诈。

不安全的通信

• 当需要保护敏感通信时，应用程序经常无法加密网络流量。

限制 URL 访问失败

• 通常，应用程序仅通过阻止向未经授权的用户显示链接或 URL 来保护敏感功能。攻击者可以利用此漏洞，通过直接访问这些 URL 来访问和执行未经授权的操作。

开放式 Web 应用程序安全项目

-亚当

每个人都会说“SQL注入”，因为它是听起来最可怕的漏洞，也是最容易理解的漏洞。跨站点脚本 （XSS） 将排在第二位，因为它也很容易理解。“输入验证不佳”不是漏洞，而是对安全最佳实践的评估。

让我们从不同的角度尝试一下。以下是在 Web 应用程序中实现时可能会搞砸您的功能：

• 动态 SQL（例如，UI 查询生成器）。到现在为止，你可能知道，在 Web 应用中使用 SQL 的唯一可靠安全的方法是使用参数化查询，即将查询中的每个参数显式绑定到变量。我看到 Web 应用程序最常违反此规则的地方是恶意输入不是明显的参数（如名称），而是查询属性。一个明显的例子是您在搜索网站上看到的类似iTunes的“智能播放列表”查询构建器，其中where-clause运算符之类的东西直接传递到后端。另一个需要翻转的好石头是表列排序，你会看到像 DESC 这样的东西在 HTTP 参数中公开。

• 文件上传。文件上传会让人们感到困惑，因为文件路径名看起来很像 URL 路径名，而且因为 Web 服务器只需将 URL 对准文件系统上的目录即可轻松实现“下载”部分。在我们测试的 10 个上传处理程序中，有 7 个允许攻击者访问服务器上的任意文件，因为应用程序开发人员认为对文件系统“open（）”调用应用的权限与应用于查询的权限相同。

• 密码存储。如果您的应用程序可以在我丢失原始密码时将原始密码发回我，那么您就失败了。对于密码存储，有一个安全可靠的答案，那就是 bcrypt;如果你使用的是 PHP，你可能想要 PHPpass。

• 随机数生成。对 Web 应用程序的经典攻击：重置另一个用户的密码，并且由于该应用程序使用的是系统的“rand（）”函数，该函数不是加密强的，因此密码是可预测的。这也适用于您进行加密的任何地方。顺便说一句，你不应该这样做：如果你在任何地方依赖加密货币，你很可能很脆弱。

• 动态输出。人们过于相信输入验证。清理所有可能的元字符的用户输入的机会很低，尤其是在现实世界中，元字符是用户输入的必要部分。更好的方法是采用一致的制度来过滤数据库输出并将其转换为 HTML 实体，如 quot、gt 和 lt。Rails 会自动为你完成此操作。

• 电子邮件。许多应用程序都实现了某种出站邮件功能，使攻击者能够创建匿名帐户或根本不使用任何帐户，从而将攻击者控制的电子邮件发送到任意电子邮件地址。

除了这些功能之外，您在应用程序中可能犯的 #1 错误是在某处公开数据库行 ID，以便用户 X 只需将数字从“5”更改为“6”即可查看用户 Y 的数据。