So you’ve mastered the ifs thens and whiles, you’re the king of loops and you can honestly call MySQL your bitch, but what’s the point if everything you code is insecure and full of holes? PHP security is something not many people are worried about and even less know how to implement it. This artile will attempt to describe a few common mistakes and ways to work a round them…
Data Filtering
Data filtering is one of the cornerstones of secure application development. It involves the mechanism by which you determine the validity of data that is entering and exiting the application, and a good software design can help developers to:
- Ensure that data filtering cannot be bypassed
- Ensure that invalid data cannot be mistaken for valid data, and
- Identify the origin of data.
The Dispatch method
One method is to have a single PHP script available to the web and have every other module included with the include or require functions. This method usually calls for a GET variable to be passed with every URL that identifies the task. This method uses the GET variable to ‘dispatch’ or send the page to the desired location. Two main reasons this method is popular is because it allows the developer to implement global security measures on one single script and ensure that it cannot be bypassed. Second, one could easily see that data filtering takes place when necessary, by focusing on the control flow of a specific task. It should be noted that if this method were combined with mod_rewrite, the user wouldn’t even know that such a method was in action, for example, http://www.sleepingawake.net/index.php?do=printcould end up looking like http://www.sleepingawake.net/app/print
The Include Method
The second approach is to have a single include that is responsible for the security of each document. This module is included at the top of each script that’s accessiblr through the web.
With either of these methods, it’s important to remember to filter all data that comes from the user. Be sure that the submitted email is in fact an email address, be sure that every integer variable returns an interger, and if there’s a finite list of possibilities for a variable (perhaps from a dropdown list or a Yes/No) that only one such possibility is returned. This not only strengthens security but also improves overall accuracy of the data.
Form Processing
Spoofed Form Submissions
One common practice for hackers is to view the source of your forms and copy them elsewhere where they can easily be manipulated. They can change limited possibility dropdown lists into textboxes, where they’d then be able to submit any content they want to your site using an absolute URL in the action attribute.
Spoofed HTTP Requests
Another more advanced (and therefore less used) method is Spoofed HTTP requests. These requests can be sent from a telnet source or via a PHP script and basically does the same as the method above. For a more detailed description of HTTP Requests, visit the HTTP Request section over at W3.org and/or the articleUnderstanding HTTP by Perlfect Solutions.
Databases and SQL
Exposed Access Credentials
A VERY common mistake (one that I was guilty of for a while) is to provide your database access credentials in one single .inc file in the root directory. Although this method is quite simple, it’s full of more holes than swiss cheese. You see, .inc files by nature are displayed as plaintext in browsers so if someone bychance found out the file path to it your database security would be compromised. One common remedy is to rename your .inc file, for example, from db.inc to db.inc.php. This simple practice hides the content of the file from showing via a browser. Another even more secure method is to place the file in a folder that is not accessable via a browser and calling the actual filepath in the PHP scripts. For more advanced information on this subject visit Exposed Access Credentials in the PHP Security Guide
SQL Injection
SQL injection attacks are extremely simple to defend against, but many applications are still vulnerable. This is another one I was guilty of for a long time. Using variables directly from forms with no data filtering in place can cause horrible problems. A sneaky user can go so far as to send multiple queries to the database server in a single call. Worse still, a user can potentially terminate the existing query with a semicolon and follow this with a query of the user’s choosing. The good news is that Data Filtering as explained above can prevent or even eliminate the possibility if this happening. Another useful tidbit is to put single quotes around all values in your SQL statements, regardless of the data type. That and escaping your data using mysql_escape_string() or addslashes() will also help prevent unwanted SQL results.
Sessions
Session Fixation
Session security is a fairly advanced topic, which is why it’s widely exploited. Mose session attacks involve impersonation, where an attacker gains access to someones session identifier. There are three common methods used to obtain a valid session identifier:
- Prediction
- Capture
- Fixation
Early in this article I raved about the simplicity of using include. Well there’s yet another step you can take to ensure your site’s safety with regards to these include files. The script below (graciously taken from the folks over at phpfreaks.com) will stop your files being directly accessed. Place This At The Begging Of The File Your Going To Include:
<?php
For example, say the file with the above code is now in is called menu.php, we have to specify IN_VALID so you can include it:
if ( !defined(’IN_VALID’) )
{ die("<Center><B>Error: This File Cannot Be Accessed Directly</B><BR>To Return To The Main Site <a href=\"#\">Click Here</a></Center>");
}
?><?php
Ultimately the user will not know what’s required in order to view the include
and therefore allows the contents of it to remain hidden
define(’IN_VALID’, true);
include("menu.php");
?>
I hope this wasn’t too confusing to read, if you have any questions regarding this post let me know and I will do my best to make it easier to understand. I’d like to thank PHPFreaks, The W3C, the PHP Security Consortium and Perlfect Solutions for their (albeit unintentional) participation in the making of this article.




All Content Copyright ©2008 SleepingAwake.net.