39

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

编辑:我将其更改为社区 wiki。即使接受了 Arkh 的出色答案,如果您有更多示例,我仍然对它们感兴趣。

4

9 回答 9

59

跨站请求伪造 (CSRF)

描述 :

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

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

如何预防:

通常的方法是在所有形式中生成随机的短期(1500 万到小时)随机数。当您的 CMS 收到表单数据时,它会首先检查 nonce 是否正常。如果不是,则不使用数据。

CMS 示例:

更多信息 :

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

密码存储错误

描述 :

想象一下,您的数据库被黑客入侵并发布在类似 wikileak 的网站上。知道您的大部分用户在许多网站上使用相同的登录名和密码,您是否希望它们易于获取?

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

如何预防:

  • 第一个想法是散列它们。这是一个坏主意,因为彩虹表(例如,即使哈希不是 md5 而是 sha512)。
  • 第二个想法:在散列之前添加一个唯一的随机盐,这样黑客就必须暴力破解每个密码。问题是,黑客可以快速计算大量哈希。
  • 所以,目前的想法是让哈希密码变慢:你不在乎,因为你不经常这样做。但是当攻击者从每毫秒生成的 1000 个哈希值增加到 1 个时,他会哭。

为了简化这个过程,您可以使用一些密码大师开发的库phpass

CMS 示例:

更多信息 :

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>

如何预防

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

CMS 示例:

更多信息 :

您可以查看wikipediaOWASP您在hackers页面上也有很多 XSS 向量。

邮件头注入

描述 :

邮件标头由 CRLF ( \r\n) 序列分隔。当您使用一些用户数据发送邮件时(例如将其用于 From: 或 To:),它们可以注入更多标头。有了这个,他们可以从您的服务器发送匿名邮件。

如何预防:

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

CMS 示例:

更多信息 :

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

SQL 注入

描述 :

老经典。当您使用直接用户输入形成 SQL 查询时,就会发生这种情况。如果此输入是按需要制作的,则用户可以完全按照自己的意愿进行操作。

如何预防:

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

CMS 示例:

更多信息 :

WikipediaOWASP在这个主题上有非常好的页面。

Http响应拆分

描述 :

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

如何预防:

就像电子邮件一样,过滤器、过滤器\n\r用户%0a输入%0d的字符在将其用作标题的一部分之前。您还可以对标题进行urlencode 。

CMS 示例:

更多信息 :

我会让你猜测一下,你可以在哪里找到关于这种攻击的大量信息。OWASP维基百科

会话劫持

描述 :

在这个例子中,攻击者想要使用另一个合法(并且希望是经过身份验证的)用户的会话。为此,他可以更改自己的会话 cookie 以匹配受害者的 cookie,也可以让受害者使用他(攻击者)自己的会话 id。

如何预防:

这里没有什么是完美的: - 如果攻击者窃取了受害者的 cookie,您可以检查用户会话是否与用户 IP 匹配。但是,如果合法用户使用一些经常更改 IP 的代理,这可能会使您的网站变得无用。- 如果攻击者让用户使用他自己的会话 ID,只需使用session_regenerate_id在用户的权限更改(登录、注销、进入网站的管理部分等)时更改用户的会话 ID。

CMS 示例:

更多信息 :

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

其他

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

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

于 2010-06-01T17:44:59.890 回答
12

我记得一个相当有趣的来自 phpBB 的。自动登录 cookie 包含一个包含用户 ID 和加密密码(无盐)的序列化数组。将密码更改为值为 true 的布尔值,您就可以以您想成为的任何人身份登录。你不喜欢弱类型语言吗?

e modifierphpBB的另一个问题是在正则表达式中突出显示具有回调的搜索关键字(带有获取 MySQL 登录名/密码。

所以总结一下这个故事:

  • 注意 PHP 被弱类型化 ( md5( "secretpass" ) == true)。
  • 小心所有可以在回调(或更糟,eval)中使用的代码。

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

于 2010-06-01T17:53:14.540 回答
3

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

例如,如果您有一个脚本来处理评论的添加/编辑,您可能会这样:

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

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


向他人提供软件时要记住的另一件事是服务器设置差异很大。发布数据时,您可能希望这样做,例如:

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];
于 2010-06-02T13:41:39.157 回答
3

这么多..

这里的一些答案是列出他们记得的特定 vuls 或通用的“我在编写 web 应用程序时担心的事情”,但如果你想要一个合理可靠的历史上发现的大多数报告漏洞的列表,那么你不会做得比搜索国家漏洞数据库

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

对于常见的 webapp vuls 的一般理解,OWASP 十大项目最近已更新,是任何 Web 开发人员的必备读物。

  • A1:注射
  • A2:跨站脚本(XSS)
  • A3:损坏的身份验证和会话管理
  • A4:不安全的直接对象引用
  • A5:跨站请求伪造(CSRF)
  • A6:安全配置错误
  • A7:不安全的加密存储
  • A8:未能限制 URL 访问
  • A9:传输层保护不足
  • A10:未经验证的重定向和转发
于 2010-06-02T11:53:17.380 回答
3

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

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

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

于 2010-06-01T17:44:20.437 回答
2

我心目中的四大:

  • 在不受信任的数据/代码(或一般情况下)上使用 exec
  • 包含来自远程 URL 的文件以供本地执行
  • 启用寄存器全局变量,以便 get 和 post 变量自动分配变量值。
  • 不转义数据库输入的数据/允许 SQL 注入攻击(通常在不使用数据库 API 层时发生)
于 2010-06-01T17:37:31.323 回答
1

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

于 2010-06-01T17:45:15.553 回答
0

,最大的安全漏洞,是人类的 愚蠢信任审查代码。你需要一个特别的团队,他们会审查在你的应用程序中添加为额外代码的任何内容,cms 的问题是外包、传入、WordPress、Drupal、Joomla 和其他流行的 cms,就像默认安装一样,它们真的很好点安全。当您让人们在您的应用程序中添加额外代码而没有经过良好审查(或者更好,没有渗透测试)时,问题就来了。这就是 WordPress 和 Joomla 的弱点,有这么多的插件和主题开发者,有这么多的批准,数百个过时的插件和主题......所以恕我直言,如果你能够建立一个强大的团队,一个好的安全计划,培训你的贡献者,并学习他们如何编码安全,以及我之前的所有其他评论,然后你就可以继续说:ei hi that's my cms,

于 2017-07-22T00:09:09.440 回答
-2

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

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

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

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

于 2011-01-18T04:54:01.597 回答