Historical security flaws of popular PHP CMS's

问题:

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+.

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.

回答1:

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.

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.

How to prevent it :

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.

CMS examples :

• CMS made simple
• Joomla!
• Drupal
• ModX

More information :

On the wikipedia page and on the OWASP project.

Bad password storing

Description :

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 ?

No. You need to mitigate the damages done if your database datas become public.

How to prevent it :

• 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.

To ease the process, you can use the library phpass developped by some password guru.

CMS examples :

• Joomla! : salted md5
• ModX : md5
• Typo3 : cleartext
• Drupal : switched to phpass after this discussion.

More information :

The phpass page.

Cross Site Scripting (XSS)

Description

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');
}
?>

Now your attacker can just send links like http://www.example.com/vulnerable.php?id=<script>alert('XSS')</script>

How to prevent it

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 examples :

• CMS made simple
• Mura CMS
• Drupal
• ModX

More information :

You can check wikipedia and OWASP. You also have a lot of XSS vector on ha.ckers page.

Mail header injection

Description :

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.

How to prevent it :

Filter all the \n, \r, %0a and %0d characters in your headers.

CMS examples :

• Jetbox CMS

More information :

Wikipedia is a good start as usual.

SQL Injection

Description :

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.

How to prevent it :

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.

CMS example :

• Drupal
• Joomla!
• ModX
• Pars CMS

More information :

Wikipedia and OWASP have really good pages on the subject.

Http response splitting

Description :

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.

How to prevent it :

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.

CMS examples :

• Drake CMS
• Plone CMS
• Wordpress

More information :

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.

Session hijacking

Description :

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.

How to prevent it :

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.).

CMS examples :

• Joomla! and Drupal
• Zen Cart

More information :

Wikipedia page on the subject.

Other

• 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.

回答2:

I remember a rather funny one from phpBB. The autologin cookie contained a serialized array containing a userId and encrypted password (no salt). Change the password to a boolean with value true and you could log in as anyone you wanted to be. Don't you love weaktyped languages?

Another issue that phpBB had was in an regular expression for the highlighting of search keywords that had a callback (with the e modifier), which enabled you to execute your own PHP code - for example, system calls on unsecure systems or just output the config file to get the MySQL login/password.

So to sum this story up:

• Watch out for PHP being weaktyped ( md5( "secretpass" ) == true ).
• Be careful with all code that could be used in a callback (or worse, eval).

And of course there are the other issues already mentioned before me.

回答3:

Another application level security issue that I've seen CMSes deal with is insufficiently authorizing page or function level access. In other words, security being set by only showing links when you are authorized to view those links, but not fully checking that the user account is authorized to view the page or use the functionality once they are on the page.

In other words, an admin account has links displayed to go to user management pages. But the user management page only checks that the user is logged in, not that they are logged in and admin. A regular user then logs in, manually types in the admin page URI, then has full admin access to the user management pages and makes their account into an admin account.

You'd be surprised how many times I've seen things like that even in shopping cart applications where user CC data is viewable.

回答4:

The biggest one that so many people seem to either forget or not realise is that anyone can post any data to your scripts, including cookies and sessions etc. And don't forget, just because a user is logged in, doesn't mean they can do any action.

For example, if you had a script that handles the adding/editing of a comment, you might have this:

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

Can you see what's wrong? You checked that the user is logged in, but you didn't check if the user owns the comment, or is able to edit the comment. Which means any logged-in user could post a comment ID and content and edit others' comments!

---

Another thing to remember when providing software to others is that server set ups vary wildly. When data is posted you may want to do this, for example:

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

回答5:

So so many..

A number of answers here are listing specific vuls they remember or generic "things i worry about when writing a webapp", but if you want a reasonably reliable list of a majority of reported vulnerabilities found historically, then you wouldn't do much worse than to search the National Vulnerability Database

There are 582 vulnerabilities reported in Joomla or Joomla addons, 199 for Wordpress and 345 for Drupal for you to digest.

For generic understanding of common webapp vuls, the OWASP Top Ten project has recently been updated and is an essential read for any web developer.

• A1: Injection
• A2: Cross-Site Scripting (XSS)
• A3: Broken Authentication and Session Management
• A4: Insecure Direct Object References
• A5: Cross-Site Request Forgery (CSRF)
• A6: Security Misconfiguration
• A7: Insecure Cryptographic Storage
• A8: Failure to Restrict URL Access
• A9: Insufficient Transport Layer Protection
• A10: Unvalidated Redirects and Forwards

回答6:

Four big ones in my mind:

• using exec on untrusted data/code (or in general)
• include-ing files from remote URL's for local execution
• enabling register globals so that get and post variables get variable values automatically assigned.
• not escaping db entered data/ allowing SQL injection attacks (usually happens when not using a DB API layer)

回答7:

Disallow POST from other domain/IP So Bots cant login/submit forms.

回答8:

People, is of the answers, the biggest security breech, is the human stupidity. Trust, review code. You need a special team, which will review anything that added as an extra code in your application, cms's problem are the outsource, the incomings, WordPress, Drupal, Joomla, and other popular cms, like default installations, they are really in a very good point secure. The problem is coming when you leave people to add extra code in your application, without a good review (or better, without penetration testing). This is the point where WordPress and Joomla have the weakness, there re so many plugin n theme devs, there are so many approvals,hundreds of outdated plugins n themes outhere.... So imho, if you are able to build a strong team, a good security plan, train your contributors, and learn them how to code secure, and with all the other comments before mine, then you will be able to move on and say :ei hi that's my cms, and it's a bit more secure than all the other cms on the net ;)

回答9:

Here's a potential pitfall for forum admins especially, but also anyone who codes up a form with a dropdown selector but doesn't validate that the posted response was actually one of the available options.

In college, I realized that the user's 'country' selector in phpBB had no such validation.

In our school forum, Instead of 'United States' or 'Afganistan', my country could be ANYTHING, no matter how silly, or filthy. All I needed was an html POST form. It took my classmates a few days to figure out how I had done it, but soon, all the 'cool kids' had funny phrases instead of countries displayed under their usernames.

Going to a geek college was awesome. :D