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

我正在创build一个PHP CMS，我希望将会被公众使用。 安全是一个主要的问题，我想学习一些stream行的PHP CMS，如Wordpress，Joomla，Drupal等。他们在过去有什么样的安全漏洞或漏洞，我可以避免在我的应用程序我可以用什么策略来避免呢？ 还有什么其他的问题需要我们关注，他们可能没有把这个漏洞当作漏洞，因为他们从一开始就正确地处理了这个漏洞。 什么额外的安全特性或措施，你会包括从细微的细节到系统级别的安全方法？ 请尽可能具体。 我通常意识到大多数通常的攻击媒介，但是我想确保所有的基础都被覆盖，所以不要害怕提及明显的。 假设PHP 5.2+。

编辑 ：我正在改变这个社区维基。 尽pipeArkh的优秀答案被接受了，但是如果你有他们的话，我仍然对更多的例子感兴趣。

Answer 1

跨站请求伪造（CSRF）

说明：

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

想象一下，你知道一个CMS的网站pipe理员的电子邮件。 用他想要的东西给他发一些有趣的网页。 在此页面中，使用CMS的pipe理面板使用的数据创build一个表单，以创build一个新的pipe理员用户。 将这些数据发送到网站pipe理面板，并在网页中隐藏iframe。 Voilà，你有自己的pipe理员帐户。

如何防止它：

通常的方法是在你所有的表单中产生随机的短暂（15毫秒到1小时）随机数。 当您的CMS收到表单数据时，首先检查现时是否正常。 如果不是，则不使用数据。

CMS示例：

• CMS变得简单
• 的Joomla！
• Drupal的
• 镆铘

更多信息 ：

在维基百科页面和OWASP项目上 。

错误的密码存储

说明：

想象一下你的数据库被黑客攻击并发布在wikileak之类的东西上。 知道你的用户的很大一部分使用相同的login名和密码为很多网站，你想他们很容易得到？

不需要。如果您的数据库数据公开，您需要减轻损失。

如何防止它：

• 第一个想法是哈希他们。 这是一个坏的想法，因为彩虹表 （即使哈希不是MD5，但SHA512例如）。
• 第二个想法：在哈希之前添加一个独特的随机盐，以便黑客必须暴力破解每个密码。 问题是，黑客可以快速计算大量哈希。
• 所以，目前的想法是让密码哈希缓慢：你不关心，因为你不经常这样做。 但是当攻击者从每毫秒产生1000个散列到1时，攻击者会哭泣。

为了简化这个过程，你可以使用一些密码专家开发的库phpass 。

CMS示例：

• 的Joomla！ ：腌md5
• ModX：md5
• 错字3： 明文
• 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=<script>alert('XSS')</script>

如何防止它

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

CMS示例：

• CMS变得简单
• Mura CMS
• Drupal的
• 镆铘

更多信息 ：

你可以检查维基百科和OWASP 。 ha.ckers页面上还有很多XSS向量。

邮件头注入

说明：

邮件头由CRLF（ \r\n ）序列分隔。 当你使用一些用户数据发送邮件时（比如使用From：或To :)，他们可以注入更多的头文件。 有了这个，他们可以从您的服务器发送匿名邮件。

如何防止它：

过滤标题中的所有\n ， \r ， %0a和%0d字符。

CMS示例：

• Jetbox CMS

更多信息 ：

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

SQL注入

说明：

古典的经典。 当您使用直接用户input形成SQL查询时会发生这种情况。 如果这个input是根据需要制作的，用户可以做他想要的。

如何防止它：

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

CMS示例：

• Drupal的
• 的Joomla！
• 镆铘
• Pars CMS

更多信息 ：

维基百科和OWASP在这个主题上有非常好的网页。

Http响应分裂

说明：

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

如何防止它：

就像电子邮件一样，在将用户input作为标题的一部分使用之前，先过滤\n ， \r ， %0a和%0d字符。 你也可以urlencode你的头。

CMS示例：

• 德雷克CMS
• Plone CMS
• WordPress的

更多信息 ：

我会让你猜一点，在哪里可以find关于这种攻击的很多信息。 OWASP和维基百科 。

会话劫持

说明：

在这一个，攻击者想要使用另一个合法的（希望authentication的）用户的会话。 为此，他可以更改自己的会话cookie来匹配受害者的cookie，也可以让受害者使用他（攻击者）自己的会话ID。

如何防止它：

这里没有什么是完美的： – 如果攻击者窃取受害者的cookie，则可以检查用户会话是否与用户IP匹配。 但是，如果合法用户使用经常更改IP的代理服务器，则可能会导致您的站点无用。 – 如果攻击者让用户使用自己的会话ID，只需使用session_regenerate_id来修改用户权限变化（login，注销，进入pipe理员网站等）的会话ID。

CMS示例：

• 的Joomla！ 和Drupal
• Zen Cart

更多信息 ：

维基百科页面上的主题。

其他

• 用户拒绝：如果您通过禁用尝试的用户名而不是尝试来自的IP来阻止login尝试，任何人都可以在2mn内阻止所有用户。 生成新密码时也是如此：在用户确认新密码之前不要禁用旧密码（例如通过login）。
• 使用用户input在文件系统上执行某些操作。 如果是癌症与艾滋病混合，过滤这个样子。 这涉及到使用包含和要求的文件path是由用户input的一部分。
• 使用eval ， system ， exec或其他任何types的用户input。
• 不要把你不希望网页访问的文件放到网页可以访问的目录中。

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

Answer 2

我记得phpBB的一个相当有趣的。 自动logincookie包含一个包含userId和encryption密码（无盐）的序列化数组。 将密码更改为值为true的布尔值，您可以以任何你想要的身份login。 你不喜欢弱语言吗？

phpBB的另一个问题是在正则expression式中突出显示带有callback的search关键字（带有e modifier ），这使得您可以执行自己的PHP代码 – 例如，在不安全的系统上进行系统调用或输出configuration文件来获取MySQLlogin名/密码。

所以总结这个故事：

• 注意PHP被弱化（ md5( "secretpass" ) == true ）。
• 请注意所有可用于callback的代码（或者更糟，eval）。

当然，在我之前已经提到了其他问题。

Answer 3

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

换句话说，一个pipe理员帐户显示链接到用户pipe理页面。 但用户pipe理页面只检查用户是否login，而不是用户login和pipe理。 普通用户然后login，手动inputpipe理页面URI，然后对用户pipe理页面具有完全的pipe理访问权限，并将他们的帐户变为pipe理员帐户。

即使在可以查看用户CC数据的购物车应用程序中，您也会惊讶地发现有多less次这样的事情。

Answer 4

这么多人似乎忘记或没有意识到的最大的一个是，任何人都可以发布任何数据到您的脚本，包括cookie和会话等。不要忘记，仅仅因为用户login，并不意味着他们可以做任何行动。

例如，如果你有一个处理添加/编辑评论的脚本，你可能会这样做：

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

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

---

在向其他人提供软件时要记住的另一件事是服务器的设置变化很大。 当数据发布时，您可能想要这样做，例如：

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

Answer 5

太多了..

这里列出了许多答案，列出了他们记住的特定vuls或通用的“我在编写webapp时所担心的事情”，但是如果您希望历史上发现大多数已报告漏洞的合理可靠列表，那么您将不会做得比search国家漏洞数据库

在Joomla或Joomla插件中有582个漏洞报告，199个用于Wordpress，345个用于Drupal，供您消化。

对于通用webapp vuls的通用理解， OWASP Top Ten项目最近已经被更新，并且是任何web开发者必不可less的阅读。

• A1：注射
• A2：跨站点脚本（XSS）
• A3：破坏的身份validation和会话pipe理
• A4：不安全的直接对象引用
• A5：跨站请求伪造（CSRF）
• A6：安全性错误configuration
• A7：不安全的密码存储
• A8：未能限制URL访问
• A9：传输层保护不足
• A10：未经validation的redirect和转发

Answer 6

我心中有四个大的东西：

• 使用不可信的数据/代码（或一般）
• 包括来自远程URL的文件以供本地执行
• 启用注册全局variables，以便获取和发布variables获取自动分配的variables值。
• 不逃避数据库input的数据/允许SQL注入攻击（通常发生在不使用DB API层时）

Answer 7

禁止从其他域/ IP的POST所以僵尸无法login/提交表单。

Answer 8

人 ，是最大的安全屁股，是人类的 愚蠢 。 信任 ， 审查代码。 你需要一个特殊的团队，它会审查你的应用程序中添加的任何代码，cms的问题是外包，包括WordPress，Drupal，Joomla和其他stream行的cms，比如默认安装，它们真的是非常好点安全。 当你离开人们在你的应用程序中添加额外的代码，没有一个好的评论（或者更好的，没有渗透testing）的时候，问题就来了。 这是WordPress和Joomla有弱点的地方，还有那么多的插件n主题开发者，有这么多的批准，数百个过时的插件n主题outhere ….所以，如果你能够build立一个强大的团队，一个很好的安全计划，训练你的贡献者，并学习他们如何编码安全，以及在我之前的所有其他评论，然后你将能够继续说：嗨嗨，这是我的CMS，它是一个更安全一点比网上的所有其他cms;）

Answer 9

特别是对于论坛pipe理员来说，这是一个潜在的隐患，也包括任何使用下拉select器对表单进行编码的人，但是不会validation发布的响应实际上是可用选项之一。

在大学里，我意识到phpBB中用户的'国家'select器没有这样的validation。

在我们的学校论坛上，不pipe是“美国”还是“阿富汗”，我的国家都可能是任何事情，不pipe多么愚蠢或肮脏。 我需要的只是一个HTML POST表单。 我的同class同学花了几天的时间才弄清楚我是怎么做到的，但不久之后，所有“酷儿”都有了一些有趣的短语，而不是用户名下面显示的国家。

去一个怪胎学院真棒。 ：d