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.
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 :
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 :
To ease the process, you can use the library phpass developped by some password guru.
CMS examples :
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 :
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 :
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,%0aand%0dcharacters in your headers.CMS examples :
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 :
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,%0aand%0dcharacters from user input before using it as part of a header. You can also urlencode your headers.CMS examples :
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 :
More information :
Wikipedia page on the subject.
Other
You have a lot of things you can read on the OWASP page.