流行的 PHP CMS 的历史安全缺陷？

Question

我正在创建一个 PHP CMS，我希望它能够被公众使用。安全性是一个主要问题，我想学习一些流行的 PHP CMS，如 Wordpress、Joomla、Drupal 等。它们过去有哪些安全缺陷或漏洞，我可以在我的应用程序中避免我可以使用什么策略来避免它们？还有哪些其他问题是我需要关注的，而他们可能不会因为他们从一开始就正确处理而没有面临这些问题？您将包括哪些额外的安全功能或措施，从微小的细节到系统级安全方法？ 请尽可能具体。我通常了解大多数常见的攻击媒介，但我想确保涵盖所有基础，所以不要'也不要害怕提及显而易见的事情。假设 PHP 5.2+。

编辑：我正在将其更改为社区 wiki。尽管 Arkh 的出色答案已被接受，但我仍然对更多示例感兴趣（如果您有）。

Answer 1

跨站请求伪造 (CSRF)

描述：

基本思想是诱骗用户访问一个页面，在该页面上，他的浏览器将向您攻击的 CMS 发起 POST 或 GET 请求。

假设您知道 CMS 支持的站点管理员的电子邮件。通过电子邮件给他发送一些有趣的网页，其中包含您想要的任何内容。在此页面中，您使用 CMS 管理面板使用的数据制作一个表单，以创建新的管理员用户。将这些数据发送到网站管理面板，结果会生成网页的隐藏 iframe。
瞧，您已经创建了自己的管理员帐户。

如何防止它：

通常的方法是在所有表单中生成随机的短期（1500 万到小时）随机数。当您的 CMS 收到表单数据时，它首先检查随机数是否正确。如果不是，则不使用该数据。

CMS 示例：

• CMS 变得简单
• Joomla！
• Drupal
• ModX

更多信息：

在 wikipedia< /a> 页面和 OWASP 项目。

错误的密码存储

描述：

想象一下您的数据库被黑客攻击并发布在维基解密等网站上。知道您的大部分用户在许多网站上使用相同的登录名和密码，您是否希望它们很容易获得？

不可以。如果您的数据库数据公开，您需要减轻所造成的损失。

如何防止：

• 第一个想法是对它们进行哈希处理。这是一个坏主意，因为 rainbow 表 （即使散列不是 md5 而是 sha512 ）。
• 第二个想法：在散列之前添加唯一的随机盐，这样黑客就必须暴力破解每个密码。问题是，黑客可以快速计算大量哈希值。
• 因此，当前的想法是减慢哈希密码的速度：您不在乎，因为您不经常这样做。但是，当攻击者从每毫秒生成 1000 个哈希值减少到 1 时，他会哭泣。

为了简化该过程，您可以使用库 phpass 由一些密码大师开发。

CMS 示例：

• Joomla! : salted md5
• ModX : md5
• Typo3 : cleartext
• Drupal : 切换到此讨论之后的 phpass。

更多信息：

phpass 页面。

跨站脚本 (XSS)

描述

这些攻击的目标是让您的网站显示一些将由您的合法用户执行的脚本。

你有两种：持久的或不持久的。第一个通常来自用户可以保存的内容，另一个则依赖于发送的请求给出的参数。这是一个非持久性的示例：

<?php
if(!is_numeric($_GET['id'])){
  die('The id ('.$_GET['id'].') is not valid');
}
?>

现在您的攻击者可以发送类似 http://www.example.com/vulnerable.php?id=的链接

如何防止它

您需要过滤输出到客户端的所有内容。如果您不想让用户，最简单的方法是使用 htmlspecialchars保存任何 html。但是，当你让他们输出 html（无论是他们自己的 html 还是从其他东西（如 bbcode）生成的一些）时，你必须非常小心。下面是一个使用 img 标签的“onerror”事件的旧示例：vBulletin 漏洞。或者您有旧的 Myspace 的 Samy。

CMS 示例：

• CMS 变得简单
• Mura CMS
• Drupal
• ModX

更多信息：

您可以查看 wikipedia 和 OWASP。 ha.ckers 页面上也有很多 XSS 向量。

邮件标头注入

描述：

邮件标头由 CRLF (\r\n) 序列分隔。当您使用某些用户数据发送邮件时（例如将其用于发件人：或收件人：），它们可以注入更多标头。这样，他们就可以从您的服务器发送匿名邮件。

如何防止：

过滤您的文件中的所有 \n、\r、%0a 和 %0d 字符标头。

CMS 示例：

• Jetbox CMS

更多信息：

维基百科 像往常一样是一个好的开始。

SQL注入

描述：

老经典。当您使用直接用户输入形成 SQL 查询时，就会发生这种情况。如果这个输入是根据需要精心设计的，用户就可以完全按照他的意愿去做。

如何预防：

很简单。不要使用用户输入形成 SQL 查询。使用参数化查询。
考虑任何不是由您自己编码为用户输入的输入，例如来自文件系统、您自己的数据库或 Web 服务。

CMS 示例：

• Drupal
• Joomla！
• ModX
• Pars CMS

更多信息：

Wikipedia 和 OWASP 在这个主题上有非常好的页面。

HTTP 响应拆分

描述：

与电子邮件标头一样，http 标头由 CLRF 序列分隔。如果您的应用程序使用用户输入来输出标头，他们可以使用它来制作自己的标头。

如何防止：

像电子邮件一样，过滤 \n、\r、%0a 和 %0d 字符在将其用作标头的一部分之前从用户输入中获取。您还可以urlencode您的标头。

CMS 示例：

• Drake CMS
• 克隆 CMS
• Wordpress

更多信息：

我会让您猜测一下在哪里可以找到有关此类攻击的大量信息。 OWASP 和 维基百科。

会话劫持

描述：

在这种情况下，攻击者想要使用另一个合法（并且希望经过身份验证）用户的会话。
为此，他可以更改自己的会话 cookie 以匹配受害者的会话 cookie，也可以让受害者使用他（攻击者）自己的会话 id。

如何预防：

这里没有什么是完美的：
- 如果攻击者窃取了受害者的cookie，您可以检查用户会话是否与用户IP匹配。但如果合法用户使用某些经常更改 IP 的代理，这可能会使您的网站变得毫无用处。
- 如果攻击者让用户使用自己的会话 ID，只需使用 session_regenerate_id< /a> 当用户的权限发生变化时（登录、注销、进入网站的管理部分等），更改用户的会话 ID。

CMS 示例：

• Joomla! 和 Drupal
• Zen Cart

更多信息：

有关该主题的维基百科页面。

其他

• 用户 DoSing：如果您通过禁用尝试的用户名而不是尝试来自的 IP 来防止暴力登录尝试，那么任何人都可以在 200 万内阻止您的所有用户。生成新密码时也是如此：在用户确认新密码之前不要禁用旧密码（例如使用它登录）。
• 使用用户输入在文件系统上执行某些操作。过滤这个就像癌症与艾滋病混合一样。这涉及到文件上 include 和 require 的使用，其中路径部分来自用户输入。
• 使用 eval，系统, exec 或此类带有用户输入的任何内容。
• 不要将您不希望通过网络访问的文件放在可通过网络访问的目录中。

您可以在 OWASP 页面上阅读很多内容。

Answer 2

我记得 phpBB 上的一篇相当有趣的文章。自动登录 cookie 包含一个序列化数组，其中包含用户 ID 和加密密码（无盐）。将密码更改为值为 true 的布尔值，您就可以以任何您想要的身份登录。你不喜欢弱类型语言吗？

phpBB 的另一个问题是用于突出显示具有回调的搜索关键字的正则表达式（使用 e 修饰符），这使您能够执行自己的 PHP 代码 - 例如，系统调用不安全的系统或只是输出配置文件来获取 MySQL 登录名/密码。

总结一下这个故事：

• 注意 PHP 的弱类型（ md5( "secretpass" ) == true ）。
• 请小心所有可在回调（或更糟糕的是 eval）中使用的代码。

当然，还有我之前已经提到的其他问题。

Answer 3

我见过 CMS 处理的另一个应用程序级安全问题是页面或功能级访问授权不足。换句话说，通过仅在您有权查看链接时显示链接来设置安全性，但不会完全检查用户帐户是否有权查看页面或在页面上使用该功能。

换句话说，管理员帐户会显示用于转至用户管理页面的链接。但用户管理页面只检查用户是否登录，而不检查用户是否登录和管理。然后，普通用户登录，手动输入管理页面 URI，然后拥有对用户管理页面的完全管理员访问权限，并将其帐户设置为管理员帐户。

您可能会感到惊讶，即使在可以查看用户 CC 数据的购物车应用程序中，我也多次看到类似的情况。

Answer 4

很多人似乎忘记或没有意识到的最大问题是任何人都可以将任何数据发布到您的脚本中，包括 cookie 和会话等。并且不要忘记，仅仅因为用户登录，并不意味着他们可以做任何动作。

例如，如果您有一个处理评论添加/编辑的脚本，您可能会遇到这样的情况：

if ( userIsLoggedIn() ) {
    saveComment( $_POST['commentid'], $_POST['commenttext'] )
}

您能看出问题所在吗？您检查了用户是否已登录，但没有检查用户是否拥有该评论，或者是否能够编辑该评论。这意味着任何登录用户都可以发布评论 ID 和内容并编辑其他人的评论！

---

向他人提供软件时要记住的另一件事是服务器设置差异很大。发布数据时您可能想要执行此操作，例如：

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];

Answer 5

这么多..

这里的许多答案列出了他们记得的特定漏洞或通用的“编写网络应用程序时我担心的事情”，但是如果您想要一份历史上发现的大多数报告漏洞的相当可靠的列表，那么您就不会'没有比搜索国家漏洞数据库更糟糕的

了Joomla 或 Joomla 插件报告了 582 个漏洞，Wordpress 报告了 199 个漏洞，Drupal 报告了 345 个漏洞供您消化。

为了对常见的 webapp 漏洞有一个大致的了解，OWASP 十大项目最近已被评选为已更新，是任何 Web 开发人员的必读之作。

• A1：注入
• A2：跨站脚本 (XSS)
• A3：身份验证和会话管理失效
• A4：不安全的直接对象引用
• A5：跨站请求伪造 (CSRF)
• A6：安全配置错误
• A7：不安全的加密存储
• A8：限制 URL 失败访问
• A9：传输层保护不足
• A10：未经验证的重定向和转发

Answer 6

我想到的四大问题：

• 对不受信任的数据/代码（或一般情况）使用 exec
• 包含来自远程 URL 的文件以进行本地执行，
• 启用寄存器全局变量，以便获取和发布变量
  获取自动分配的变量值。
• 不转义数据库输入的数据/允许 SQL 注入攻击
  （通常在不使用 DB API 层时发生）

Answer 7

禁止来自其他域/IP 的 POST，因此机器人无法登录/提交表单。

Answer 8

人，最大的安全漏洞，就是人的愚蠢。 信任、审查代码。你需要一个特殊的团队，它将审查在你的应用程序中作为额外代码添加的任何内容，cms 的问题是外包、传入、WordPress、Drupal、Joomla 和其他流行的 cms，就像默认安装一样，它们实际上处于非常糟糕的状态。好点安全。当你让人们在你的应用程序中添加额外的代码而没有经过良好的审查（或者更好的是，没有渗透测试）时，问题就来了。这就是 WordPress 和 Joomla 的弱点，有这么多的插件和主题开发者，有这么多的批准，数百个过时的插件和主题......所以恕我直言，如果你能够建立一个强大的团队，一个良好的安全计划，培训您的贡献者，并学习他们如何安全地编码，并且在我之前的所有其他评论中，您将能够继续并说：ei hi，这是我的 cms，它更安全一点比网上所有其他 cms ;)

Answer 9

这对于论坛管理员来说尤其是一个潜在的陷阱，但对于任何使用下拉选择器编写表单但未验证发布的响应实际上是可用选项之一的人来说也是一个潜在的陷阱。

在大学里，我意识到 phpBB 中用户的“国家”选择器没有这样的验证。

在我们学校的论坛上，我的国家不是“美国”或“阿富汗”，而是任何东西，无论多么愚蠢或肮脏。我所需要的只是一个 html POST 表单。我的同学花了几天时间才弄清楚我是如何做到的，但很快，所有“酷孩子”的用户名下都显示了有趣的短语，而不是显示国家/地区。

去极客大学真是太棒了。 ：D