Historical security flaws of popular PHP CMS's?

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.

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.

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.