PHP: 10 Security Mistakes & Oversights

In my years as a web developer, there are many security issues with which I have had to become familiar. There are a lot of people out their with malicious intent. One of them could come across your site and expose a flaw that allows them access to crucial information, or the entire site itself. Don’t let this happen! Below are the 10 most common errors programmers make that could prove fatal.

1. SQL Injection

SQL injection is the act of maliciously adding SQL code that is then processed along with SQL code. This happens when the programmer neglects to properly check user input or query string variables before using it in SQL statements.

For example:

$id = $_GET['id'];
$result = mysql_query("SELECT * FROM tblComments WHERE fldCommentID = $id");

You may be asking yourself, “What’s wrong with the above code?” Plenty… just enough for any hacker to exploit it. What would happen if the visitor entered in the URL page.php?id=0 UNION SELECT * FROM tblAdminUsers ? Because the $id variable is not properly checked for injected code, it is added to the SQL query and processed. Here is what the resulting SQL query would look like:

SELECT * FROM tblComments WHERE fldCommentID = 0 UNION SELECT * FROM tblAdminUsers

It is a common enough table naming convention to give it a try, and the results would be damaging, exposing information you never intended to become public. Knowing that $id is supposed to be an integer, one approach to preventing injection is to get the integer value of the variable.

$id = intval($_GET['id']);

The above code would then only return a number, and therefore be safe.

There are many other methods of injection, however, so keep your eyes open for any possible vulnerabilities!

2. Cross-Site Scripting

Cross-site scripting, or XSS, is the act of inputting HTML or JavaScript code such that it is called and then run. Failing to properly check for HTML tags will allow this to happen. A good example is if you echo a variable taken from the query string. If the user altered the query string such that it included JavaScript code, the possibilities would be endless for hacking and other mischief.

page.php?something=<script>alert("hello");</script>

Visiting the above URL could potentially run the script, as it could be echoed in its entirety. Once that doorway is open, anything is then possible. Suppose the visitor is posting a comment and include JavaScript in his comment. Without proper checking, it would affect anybody viewing the page on which the comment then appears.

One possible solution would be to escape all tag brackets (< and >) with their HTML entity equivalent (< and >) or, if there is no reason for anybody to be using such characters, replace them with nothing at all.

3. GET Variable Manipulation

If a site has a form on it that sends to another page via GET method (like PayPal does), it quite possible to go through all the hard work of constructing a URL and altering a variable or two in the process. Consider the following code:

<p>Checkout below!</p>
<form action="checkout.php" method="get">
<input type="hidden" name="grandtotal" value="1234.00" />
<input type="submit" value="Checkout" />
</form>

If the visitor simply clicked on the Checkout button, she would then be taken to checkout.php?grandtotal=1234.00 where, presumable, the site would then deduct $1,234.00 from a stored credit card or account balance of some sort, and so forth. One method of simple hacking would involve examining the form code, and then manually entering in a new URL: checkout.php?grandtotal=5.00 where the visitor would then only have to pay $5.00. Such oversights could prove extremely costly.

To fix such a mistake, the grand total could be stored in a database or session variable, or passed via POST instead of GET; however, a better solution would be to double-check the grand total sent to checkout.php, comparing it to what it should be. It is well worth the extra effort and work to prevent losing thousands or even millions of dollar in revenue.

4. System Calls

The exec(), passthru() and system() functions all allow you to execte system commands from within your PHP code. Failing to check the commands processed by these functions can potentially result in hackers accessing private information by altering the input. Two function exist to assist in your fight against malicious destruction: escapeshellarg() and escapeshellcmd().

The escapeshellarg() function removes potentially harmful parts of user input by adding single quotes around the string and escaping any single quotes within. It would be used like so:

$command_fixed = escapeshellarg($command);

The escapeshellcmd() function is similar to the former, except that it only escapes characters that have a special meaning to the operating system at hand.

5. File Uploads

When uploading content to a site, PHP creates a file but does not automatically check the validity of the file name, the file type, or the size. A user could create his own form specifying some other file to upload instead.

The functions move_uploaded_file() and is_uploaded_file() are useful to assist in solving this problem, but it is best to check the $_FILES global array to ensure the file size and type are allowable for your application.

6. Includes

PHP allows you to include external files as if it were within the page itself, and is useful for code that is used extensively, class definitions, and for better organization of your site. However, if the included files are dependent upon user input, this could prove to be a big mistake if not properly checked. If the user visits index.php?p=article, let’s say our index.php page runs the following:

include_once($_GET['p'].'php');

Then a page called article.php would be called up and run. If, however, the user visits index.php?p=http://mysite.com/mycode, then the code would include http://mysite.com/mycode.php, which could potentially contain malicious and destructive code. The code from that page would be run as though it were running on the site’s own server, which is never a good idea.

Even if you restricted all included files to begin with something like “include-” (so that include-articles.php would be called up instead), any hacker could go through the trouble of registering a domain name beginning with “include-” and doing the same thing as before.

The only solution is to check the query string variable for illegal characters, such as slashes, colons, and even periods.

NOTE: Make sure all included files end in the proper extension, whether it’s .php for PHP or .aspx/.asp for ASP. Otherwise, if a visitor somehow finds out what files you are including, they could view a file such as lib.inc, as opposed to lib.inc.php, which would not expose the PHP code within.

7. Unrestricted Access and Permissions

If your site has an administration section, it is best to only allow certain IP addresses (ones you know you will be on when logging in). Another good idea an Apache .htaccess file with a username and password. This is a common mistake not native to PHP; it could happen to anybody.

On a similar note, never EVER back up PHP files by changing or adding an extension. This will most likely result in the PHP code being displayed in its raw format, exposed to the entire world, rather than parsed by the server. Servers usually only recognize certain extensions for certain languages (like .php for PHP, etc.) and any other extension wil display as an ASCII text file. NOT a good idea.

8. Session IDs

It is very easy for any hacker to hijack another user’s session, if they know that user’s session ID, and potentially see information that they really shouldn’t. While not completely avoidable, there are steps you can take to increase security.

One solution is to regenerate the session ID upon login using the session_regenerate_id() function. A hacker could try to set her own session ID prior to login; regenerating the session ID would prevent this action from doing anything significant.

9. Error Reporting

Before your site goes live, you should get rid of all display_errors() functions, as well as set the display_errors variable in your php.ini file to 0. Errors that are displayed could reveal crucial information about your database structure, connection string, and other credentials.

If you still want to be able to view errors, you can set the error_log variable in php.ini to 1 and check your PHP error log frequently for caught errors. You can also create your own code to handle errors.

10. Unvalidated Access to Protected Areas

I’ve been guilty of this once before. If your site has an administration or members-only area, each and every single page that should be available to members only, should be protected properly.

At the top of every protected page, make sure that their login credentials are validated, and that the session or cookie variable you use for logging in users is still flagged and active. Otherwise, users would be able to view certain information without ever logging in. Nobody should be able to view any protected pages by bypassing the login screen.

Conclusion

There are so many ways that people can hack into your code and your site. The above covers just a handful of mistakes you could make in your code that would expose vulnerabilities and crucial information. Be safe, be informed, and be cautious!