Tag Archives: sql

4 PHP Security Pitfalls to Avoid

For PHP developers of both newbie and veteran status, there are always new ways in which hackers exploit our carefully-crafted scripts. We have to keep tabs on newly discovered security holes in our scripts, as well as minding how we construct our pages so that people can’t just inject a bunch of code into our websites, all so that our sites will run the way we want them to, and so our users’ data will be protected.

Thus, I bring to your attention the following 4 PHP pitfalls, which are vitally important for us to be aware of as we build our sites. (Incidentally, this post started out as a “PHP tricks” post, but when I saw just how many blog posts are out there already with that premise (and how many of them advocate unsafe code), I thought it best to research PHP security problems instead. And boy, did I ever discover some doozies!)

#4: Exposing Your Filepaths to Users

Most users won’t care much if the paths to various files on your site are easy to guess (or easily viewable in their address bars). A few users, however, may choose to take advantage of that–not just for hotlinking your images, scripts, etc., but for stealing data that is supposed to be secure! Yikes! If you’re running any kind of site with
logins and passwords, especially an e-commerce site, easily-visible filepaths are BAD!

So, how to fix this? Thankfully, there are fairly easy PHP scripts that can disguise a file’s real path on your server with variables, making it much more difficult for hackers to guess where a file is. For instance, motov.net has an example script that is only 13 short lines of PHP code!

#3: Not Securing Your Databases

As mentioned in #4, MySQL databases with logins, passwords, credit card info, etc. are very juicy targets for hackers. If you don’t build in protections for all this sensitive data, your site could end up being victimized, leaving you with very angry users!

PHP.net has a series of articles on how to design your database for better security, how to securely connect to such a database, and more. Layering database security, just like layering clothes before you go out in the cold, can really help protect your users’ data! (Also, WebmasterWorld’s forums has a post about securing database connections which may be of further use.)

#2: Leaving Your PHP Sessions Open to Hijacking

Any time you have users logging in to a site, you are most likely incorporating a PHP session ID, a unique number that tracks them around the site so they don’t have to keep logging in every time they go to a new page. Unfortunately, hackers can get hold of those numbers if they’re easily guessed or stored in an insecure location (see #3). You might not think somebody could wreak much havoc with just a PHP session ID number, but a hacker could end up stealing somebody else’s whole account with just such a number!

To keep your users’ session ID numbers safe(r), consider some of the tactics suggested on this StackOverflow topic, including SSL connections, randomly-generated ID numbers (instead of incrementally increasing numbers), and sessions that expire within shorter time frames.

#1: Leaving Your Site Vulnerable to SQL Injections

When we PHP developers, especially newbie developers like myself, write MySQL queries pointing to our databases, sometimes we forget that malicious users exist for a minute. We forget to keep our very PHP script files safe from “SQL injections”–that is, targeted code attacks that fiddle with our SQL queries just enough to dig up data from the database, rewrite it, or even delete it all!

To keep your SQL/MySQL code from being fiddled with or just plain overridden, PHP.net has an excellent reference article which explains several code tactics you can use, such as connecting to your database with a user specifically limited to the task you’re trying to complete, checking that the inputted data is the right type, etc. This StackOverflow topic about preventing SQL injections may also be helpful as you tackle this tricky issue.

Summary

All of these precautions may seem unnecessary, especially to newbie PHP developers, but these are all giant security holes that can cause us a lot more headaches and frustration (not to mention user anger). Nip these problems in the bud, and you’ll be saving yourself a lot of time and trouble later!