One of the major reasons why PHP frameworks benefit us has to do with the inexperienced (or even average) developer's lack of security knowledge. PHP (especially database driven PHP) is riddled with loopholes and opportunities to a malicious user to get the best of you, unless you know what you're doing.

Luckily, CodeIgniter handles a lot of these concerns for you, and gives you the tools to handle the rest. In this section of the CI tutorial, we'll take a look at many common security threats, including how CI handles them and what you need to do to make sure your CI driven web apps aren't being threatened by them.

Direct Scripting

A pretty common threat to security involves a malicious either navigating directly to your PHP page (by typing in "blahblahblah.com/system/application/controllers/something.php") or making a script to do that. If this is done, the user has been granted access to your application directory which is where the juice of your web app is stored. This is dangerous, because it means he has bypassed anything you put in place before that page is meant to be reached. For example, if he can reach a model which contains database functions, he could run a deleteBlog() function for i=1 to 100000, effectively deleting your whole blog database.

CI handles this one pretty gracefully. It requires that every request to your site be routed through the index.php page at the web root. EVERYTHING. When you download a fresh CI package, and check out the default controller (welcome.php), notice how it says something like this at the top of the page:

One of the things which the base index.php does is defines a BASEPATH before routing to whatever page is to be displayed. If that BASEPATH is not defined, CI knows that the request did not go through index.php, which must mean somebody is up to some direct scripting non-goodness. So it will stop the execution of that page and stick the message there for all the evil people to see.

You need to stick that line of code at the very beginning of EVERY controller, model, view, library, hook, etc. that you create in CodeIgniter. That way, each of those files are protected against direct scripting.

NOTE: Often malicious users will try and cause an error message because some sites leave error reporting to a level at which it will output the path to the error. This would notify the user that you were using CI because he might recognize the system->application->controller folder structure. Therefore, when your site goes live, change error_reporting to "0" in index.php to prevent this.

ANOTHER NOTE: A popular alternative to the BASEPATH method is to move the entire system folder out of the web root. For example, all of my web content on my host is in the public_html folder. I could move my system folder out of that folder so that it would be a sibling to public_html rather than a child. Then, I would update index.php to tell it where to look for the system folder (this is easily done, just read the comments in index.php). The benefit of this is that it is impossible for anyone to direct script to your goods because they aren't even located on your web directory. The only way anyone could reach them is if their script was running on your own server (which is how index.php is able to reach them). This is a really slick method and I like it alot. Check it out.

Directory Access

Most web applications store important stuff in directories, stuff like music, videos, pictures, or anything else that is copyrighted and valuable. If a user could access these directories and view their contents, those valuable things would be as good as his.

This is a pretty easy fix. CodeIgniter just sticks an index.html file in there with a 403 Forbidden message. So basically, if you have an "img" folder (and have added CI's index.html file to that folder), and somebody navigates their browser to that folder, they'll get a big fat DENIED message, because we all know that index files are loaded by default when a directory is opened. If you haven't added CI's index.html, the directory will be easily viewable/downloaded/sold on ebay.

CI has already included index.html in all of the folders there by default, such as your controllers and models, so you only have to worry about adding it to any image, css, js, or other folders which you add manually.

SQL Injection

NOTE: Normally, we would use CI's Active Record (as talked about in part three of this tutorial) for DB queries, but I'm going to handwrite them here for the sake of better understanding the nature of SQL injection.

Now we're getting to the big boys. SQL injection is one of the sneakiest and most powerful security threats around, and any true l33t h4x0r can tell you all about it. Here's an example. Say that you've got a login form to the administration section of your site, with a username input and a password input. After submission, your SQL looks something like this:

Normally, this will end up looking like this:

So how can this be screwed around with? Say a malicious user entered something like admin'; -- , meaning the new SQL looks like:

That's actually completely valid, because a "--" in SQL means the start of a comment, so anything after that gets trimmed off, leaving only:

As long as the user is able to pick the right username, he has access (and a huge about of administrative usernames are just "admin" or "Admin"). So what can we do to help this? Just escape the entered strings. This will also solve the problem or the user entering something like "O'Bryan", which would normally cause a SQL error.

CI has its own functions for this. One is the simple $this->db->escape($string) function, which can be inserted directly into the SQL statement as follows:

That pretty much solves that one. CI also includes another way of doing the same thing, using question marks in place of variables. Check this out:

As you can see, the query() function has a little known optional second parameter of an array of variables to stick into the SQL. CI will automatically escape those variables for you so you don't have to worry about the escape() function. Plus, it's nice and readable. I like it!

Cross Site Scripting (XSS)

Here's another big papa of PHP security threats. XSS is a threat to any web page which involes user generated content (which is basically all of web 2.0). Basically, it involves a user entering some some script (usually javascript) into a comment box or forum post or wiki page or whatever else you can think of. This javascript can then do whatever the malicious user wants it to. For example, a user could post on a forum a small bit of JS which would redirect any viewer of that page to a competitor's forum. Or a user could include the following bit of code to a blog comment:

That would take the contents of a viewer's cookie (which often contains the login information to the site the script is on) and post them to another site, where they may be stolen and logged. See what I mean? This is tough stuff. There are really endless opportunties for hackers to screw you up with cross site scripting.

CI is all over this one. The input class (which is automatically loaded so you don't have to autoload it yourself) includes the function xss_clean() which will automatically remove any XSS threats from a string. You can manually do this to anything you want (usually something from $this->input->post()), or you can tell CI to automatically do it anytime anything is input form the user. To do it globally, open up config.php and set $config['global_xss_filtering'] = TRUE;. I like to do it globally because I can't notice a slowdown and it gives me peace of mind.

Well that's about it for CI and PHP security. Hopefully you learned a few things and even if you don't use CI, you will be mindful of these things in your future web apps. There's nothing worse than creating the perfect site only to have it hacked. So watch it. And remember, CI loves you!

This entry was posted on Sunday, June 1st, 2008 at 12:51 pm and is filed under CodeIgniter, PHP. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.