5 reasons to NOT use csrf_protection in Codeigniter
I just wanted to tell a small funny story as an introduction of the reasons why to not use csrf_protection in Codeigniter. If you though just want to read the reasons why, go straight away to 5 simple reasons for why not to use csrf_protection of Codeigniter…
For the other users just keep reading …
A small story first
You are using PHP Codegniter Framework and you are really happy about the tools that it offers to you.You have created a whole website in just few days and you are really proud of it. Last time there was an article about security in Codeigniter? With a quick google search you just found csrf_protection has to be set to true for hacks attacks. They also mentioned that you have to use form_open for your forms.
WOW! This is not a problem for you as you already use form_open and form_close for the set_rules. So really happy that your website is also secure now, you tweet it , you write it on facebook, you also tell it to your customer that the system now it is even more secure for future hack attacks…
and the problems just started… an unexpected error out of nowhere!!!
Next day, your customer called you angry and telling you about a weird error in his screen.
Then you realize that you cannot understand where the problem is. After lot of searching you realized that the csrf_protection doesn’t support AJAX forms. As always … google search and yes you finally find an article (eg. AJAX with CSRF Protection in Codeigniter 2.0) that tell you about the cookies and other stuff like this. You don’t really understand why it will work like this, so… you just copy the code to your project and TADA it works!
It’s been a while that your customer didn’t tell anything and everything seems to works fine. Then the same customer again realized that some users that using internet explorer (not the old one, the new IE9) they have the same error.
And then you realize that the csrf_protection has the problem. You also mentioned that even some forms in the backend system didn’t work properly but at least the customer didn’t know it, so that’s fine. So after 1 day researching you understood that you cannot find a solution for all the forms and you just set csrf_protection back to false as you didn’t understand at the first place what hack attacks you could prevent.
There are 5 simple reasons…
1. You don’t prevent hack attacks. Only some automated bots.
2. It works fine only for simple forms. It is unstable for AJAX forms.
3. It doesn’t work when the cookies are disabled.
4. There is a general error (The action you have requested is not allowed.) that a simple user cannot understand what is going on and neither the developer can understand where the problem is!
5. It is not IE 7 and Opera compatible for AJAX requests as far as I tested
I will not explain further my reasons as I think that I will have long discussions with people that don’t have the same opinion with me and this is not the point of this article. I will try to give some small solutions of what to do instead of setting csrf_protection to true.
I liked an article that I have read about crsf protection Protect a CodeIgniter Application Against CSRF . At the end of the article they say that:
Alternatively, as of CodeIgniter v2.0, protection against CSRF attacks is now built into the framework!
but I prefer to use this one as it use session rather than the $_COOKIE of Codeigniter default one. You can even understand the logic and create your own hook for csrf protection.
First of all let’s start of what is the Cross-Site Request Forgery protection and why you should protect your forms from attacks:
What is the CSRF protection?
An attacker could create a bogus form on his site – for example a search form. This form could have hidden inputs that contain malicious data. Now the form isn’t actually sent to the attacker’s site to perform the search; in reality, the form points to your site! Since your website will trust that the form is genuine, it goes through and executes the requested (and perhaps malicious) actions.
Imagine that a user is logged into your site, and is redirected to the attacker’s site for some reason (phishing, XSS, you name it). The attacker’s form could point to your account deletion form on your site. If the user performs a “search” on the attackers site, his account will then be deleted without him knowing!
For more read the full article here
Don’t expect to have just one line of code and have all the security that is needed. Even the most powerful PHP frameworks need time to improve the security. The knownledge of security is very important and it prevents you from long term problems. Also as many things you really know about security the better. So my advice is to read the article of Application Against CSRF or similar articles for form protections and learn what is going on and then create your own custom hook.
In my experience is more important to actually make things work rather than block every form with the risk of not sending the message to the admin or user and doesn’t even realize it.
So general advices for the forms to be more secure:
- Log your forms. Just log all the requests of the forms in the database or in files.
- Don’t name your admin controller admin or administrator.
- Use a captcha authorisation for all your frontend forms unless the user is logged in.
- Use your own custom security library for the forms to prevent attacks.
- Don’t have dump passwords neither on testing mode. Passwords such as password,123456, admin, e.t.c. can cause big problems if you have by mistake a dump password on production mode without realizing it.
- Always escape your input values and be careful to validate and trim any data that comes from the frontend website.
- Always try to use tokens for your forms to check if the submit is coming from your site or not. For example a hidden input.
I think with those small security advices you can prevent the most hack attacks from the frontend website.
And don’t forget :
$config<span class="GINGER_SOFATWARE_correct">[</span>'csrf_protection'] = FALSE;
IF YOU WANT CSRF PROTECTION ENABLED AT AJAX CALLS.
If you use CodeIgniter (CI) like me, you’ve probably read/heard about the CSRF protection that comes built into this great framework. I typically kept ajax functionality (form submissions in this case) to a minimum as I wanted to focus more on development and finishing a project than prettying it up with ‘Web 2.0′ stuff.
Well in a couple of my last projects I’ve ran smack into CSRF protection and how it impacts AJAX (as well as many other things like Paypal payment gateway responses, etc).
If you found this page when searching for Codeigniter CSRF Ajax, then you’re in luck, as here is the easiest way to add CSRF protection to your ajax calls:
The magic really here is the following entry in the data I am sending back to my controller:
The `get_csrf_token_name()` gets you your token name from the security class (first set in your config), and the `get_csrf_hash();` simply outputs the secure hash from the security class. Simple enough.
If you have timeout issues (say your ajax page sits too long, you may increase the token a bit, test for best fit).