PHP CMS的历史安全漏洞？ [英] Historical security flaws of popular PHP CMS's?
问题描述
我正在创建一个PHP CMS，我希望它将被公众使用。安全是一个主要的关注，我想从一些流行的PHP CMS，如Wordpress，Joomla，Drupal等学习。他们在过去，他们有一些安全缺陷或漏洞，我可以避免在我的应用程序以及我可以使用什么策略来避免它们？什么是其他问题，我需要关心，他们可能没有面临作为一个漏洞，因为他们从一开始就正确处理它？您将包括什么额外的安全功能或措施，从细节到系统级安全方法？ 请尽可能具体。 我一般都知道大多数常见的攻击载体，但我想确保所有的基地都被覆盖，害怕提到明显的。假设PHP 5.2 +。
I'm creating a PHP CMS, one that I hope will be used by the public. Security is a major concern and I'd like to learn from some of the popular PHP CMS's like Wordpress, Joomla, Drupal, etc. What are some security flaws or vulnerabilities that they have they had in the past that I can avoid in my application and what strategies can I use to avoid them? What are other issues that I need to be concerned with that they perhaps didn't face as a vulnerability because they handled it correctly from the start? What additional security features or measures would you include, anything from minute details to system level security approaches? Please be as specific as possible. I'm generally aware of most of the usual attack vectors, but I want to make sure that all the bases are covered, so don't be afraid to mention the obvious as well. Assume PHP 5.2+.
编辑：我将此更改为社区Wiki。即使Arkh的优秀答案被接受，我仍然对进一步的例子感兴趣，如果你有他们。
Edit: I'm changing this to a community wiki. Even though Arkh's excellent answer is accepted, I'm still interested in further examples if you have them.
推荐答案
跨站点请求伪造（CSRF）
说明：
基本思想是诱骗用户访问其浏览器将向您攻击的CMS发起POST或GET请求。
Cross-Site Request Forgery (CSRF)
Description :
The basic idea is to trick a user to a page where his browser will initiate a POST or GET request to the CMS you attack.
想象您知道CMS支持的站点管理员的电子邮件。给他发电子邮件一些有趣的网页与任何你想要的。在此页面中，您将创建一个包含CMS管理面板用于创建新管理用户的数据的表单。将这些数据发送到网站管理面板，其结果是您的网页的隐藏iframe。
Voilà，您有自己的管理员帐户。
Imagine you know the email of a CMS powered site administrator. Email him some funny webpage with whatever you want in it. In this page, you craft a form with the data used by the admin panel of the CMS to create a new admin user. Send those data to the website admin panel, with the result in a hidden iframe of your webpage. Voilà, you got your own administrator account made.
通常的方式是生成所有形式的随机短命（15mn到小时）的随机数。当CMS收到表单数据时，它首先检查该现时是否正确。
The usual way is to generate random short-lived (15mn to hour) nonce in all your forms. When your CMS receive a form data, it checks first if the nonce is alright. If not, the data is not used.
- < a href =http://www.secuobs.com/secumail/btsecumail/msg19456.shtml =nofollow noreferrer> CMS简单
- Joomla！
- Drupal
- ModX
- CMS made simple
- Joomla!
- Drupal
- ModX
假设您的数据库被黑客入侵并发布在像wikileak这样的东西上。知道大部分用户对很多网站使用相同的登录名和密码，您希望他们很容易获得吗？
Imagine your database get hacked and published on something like wikileak. Knowing that a big part of your users use the same login and password for a lot of websites, do you want them to be easy to get ?
否。
- 第一个想法是对它们进行哈希。这是一个坏主意，因为彩虹表（即使哈希不是md5，但sha512为
- 第二个想法：在哈希前添加一个唯一的随机盐，以便黑客必须强制使用每个密码。问题是，黑客可以快速计算大量的哈希。
- 所以，当前的想法是让缓慢哈希密码：你不在乎，因为你不经常做。但是当攻击者从每秒生成的1000个哈希值到1时，攻击者会哭。
- A first idea is to hash them. Which is a bad idea because of rainbow tables (even if the hash is not md5 but sha512 for example).
- Second idea : add a unique random salt before hashing so the hackers has to bruteforce each password. The problem is, the hacker can compute a lot of hash fast.
- So, the current idea is to make it slow to hash the passwords : you don't care because you don't do it often. But the attacker will cry when he gets from 1000 hash generated per ms to 1.
为了简化这个过程， phpass 由某些密码大师开发。
To ease the process, you can use the library phpass developped by some password guru.
- Joomla! : salted md5
- ModX : md5
- Typo3 : cleartext
- Drupal : switched to phpass after this discussion.
这些攻击，是让你的网站显示一些脚本，将由你的合法用户执行。
The goal of these attacks, is to make your website display some script which will be executed by your legitimate user.
你有两种类型：持久或不。第一个通常来自用户可以保存的东西，另一个来自请求发送的参数。这里是一个例子，不是持久的：
You have two kind of these : persistent or not. The first one comes usually from something your user can save, the other count on parameters given by a request sent. Here is an example, not persistent :
<?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>
Now your attacker can just send links like http://www.example.com/vulnerable.php?id=<script>alert('XSS')</script>
您需要过滤您输出到客户端的所有内容。最简单的方法是使用 htmlspecialchars ，如果您不想让您的用户保存任何html。但是，当你让他们输出html（他们自己的html或一些从其他东西像bbcode生成），你必须非常小心。以下是使用img标记的onerror事件的旧示例： vBulletin漏洞 。或者您有旧的 Myspace的Samy 。
You need to filter everything you output to the client. The easiest way is to use htmlspecialchars if you don't want to let your user save any html. But, when you let them output html (either their own html or some generated from other things like bbcode) you have to be very careful. Here is an old example using the "onerror" event of the img tag : vBulletin vulnerability. Or you have the old Myspace's Samy.
- CMS made simple
- Mura CMS
- Drupal
- ModX
您可以检查维基百科和 OWASP 。您在 ha.ckers 页面上还有很多XSS向量。
You can check wikipedia and OWASP. You also have a lot of XSS vector on ha.ckers page.
邮件标题由CRLF（ \r\\\）序列。当你使用一些用户数据发送邮件（例如使用它为发件人：或To :)，他们可以注入更多的标题。
Mail headers are separated by the CRLF (\r\n) sequence. When you use some user data to send mails (like using it for the From: or To:) they can inject more headers. With this, they can send anonymous mails from your server.
过滤所有 \\\，
\r ，％0a ％0d 字符。
- Jetbox CMS
维基百科是一个很好的开始。
旧的经典。它发生在使用直接用户输入形成SQL查询时。
The old classic. It happen when you form a SQL query using direct user input. If this input is crafted like needed, a user can do exactly what he want.
简单。不要使用用户输入来形成SQL查询。使用参数化查询。
考虑不是自己编写的任何输入作为用户输入，例如来自文件系统，您自己的数据库或web服务。
Simple. Don't form SQL queries with user input. Use parameterized queries. Consider any input which is not coded by yourself as user input, be it coming from the filesystem, your own database or a webservice for example.
- Drupal
- Joomla!
- ModX
- Pars CMS
Wikipedia and OWASP have really good pages on the subject.
http头由CLRF序列分隔。
Like e-mail headers, the http headers are separated by the CLRF sequence. If your application uses user input to output headers, they can use this to craft their own.
像电子邮件一样，过滤 \\\，
\r ， 0a 和％0d 字符，然后将其用作标题的一部分。您还可以 urlencode 标头。
Like for emails, filter \n, \r, %0a and %0d characters from user input before using it as part of a header. You can also urlencode your headers.
- Drake CMS
- Plone CMS
- Wordpress
猜猜一下你可以找到很多关于这种攻击的信息。 OWASP 和维基百科。
I'll let you guess a little as to where you can find a lot of infos about this kind of attack. OWASP and Wikipedia.
在这一个中，攻击者想要使用另一个合法（并且希望已验证的）用户的会话。
为此，他可以更改自己的会话cookie以匹配受害者的会话cookie，或者他可以使受害者使用他（攻击者的）自己的会话ID。
In this one, the attacker want to use the session of another legitimate (and hopefully authenticated) user. For this, he can either change his own session cookie to match the victim's one or he can make the victim use his (the attacker's) own session id.
这里没有什么可以完美的：
- 如果攻击者窃取了受害者的cookie，您可以检查用户会话是否与用户匹配IP。但是，如果合法用户使用一些经常更改IP的代理，这可能会使您的网站无用。
- 如果攻击者使用户使用自己的会话ID，只需使用 session_regenerate_id ，以便在用户的权限更改（登录，注销，进入网站的管理部分等）时更改用户的会话ID。
Nothing can be perfect here : - if the attacker steal the victim's cookie, you can check that the user session matches the user IP. But this can render your site useless if legitimate users use some proxy which change IP often. - if the attacker makes the user use his own session ID, just use session_regenerate_id to change the session ID of a user when his rights change (login, logout, get in admin part of the website etc.).
- Joomla! and Drupal
- Zen Cart
维基百科页面。
- User DoSing：如果您通过禁用尝试的用户名阻止登录尝试的强制，而不是尝试来自的IP，任何人都可以阻止所有用户在200万。
- 使用用户输入在文件系统上执行某些操作时，请确保新的密码不会禁用旧密码。 。过滤，如果它是癌症混合辅助。这涉及使用include和require文件，其中的路径部分来自用户输入。
- 使用 eval ，系统，执行或此处的任何内容
- User DoSing : if you prevent bruteforcing of login attempt by disabling the usernames tried and not the IP the attempts come from, anyone can block all your users in 2mn. Same thing when generating new passwords : don't disable the old one until the user confirm the new one (by loging with it for example).
- Using user input to do something on your filesystem. Filter this like if it was cancer mixed with aids. This concern the use of include and require on files which path is made in part from the user input.
- Using eval, system, exec or anything from this kind with user input.
- Don't put files you don't want web accessible in web accessible directory.
You have a lot of things you can read on the OWASP page.
这篇关于PHP CMS的历史安全漏洞？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
