- Feb 20, 2012
0- by A2 Marketing Team
The most commonly exploited vulnerabilities are usually the ones easiest to avoid. That is to say, most of the exploits an attacker might use to gain unintended access to your site or database result from bad coding practices rather than bugs in the software platform (such as a LAMP stack). Let’s focus on some practices PHP developers can adopt to combat some of the most common attack vectors. These are really simple and hopefully advanced developers are already living by them.
Don’t use eval
It’s a tempting tool that allows you to do lots of neat tricks, and it exists in JavaScript and other languages as well. Regardless of the language; don’t use eval. It is the #1 most common attack vector for finding vulnerabilities in PHP code. Sure, you can in theory use eval safely, but we’re all human and we all make mistakes. Whether you’re in a rush, up too late writing code or both, it only takes one slip up with eval to create a giant security hole in your software. Not only do you need to worry about your own code, but what’s worse is trusting code others have written using eval, especially if it’s encoded and you can’t verify for yourself. It’s best to just have it disabled and not use it at all. When we run into software using eval, we contact the developers and request they accomplish the task another way.
Use a framework, PDO or prepared MySQL statements. This one is easy to skip over when you’re in a hurry, but it’s how you can avoid the other most common security vulnerability; MySQL injections. You might think you’re safe simply using mysql_real_escape_string, but it’s not enough. To truly protect yourself from MySQL injections, you should be using either a class which creates prepared statements and sanitizes inputs for you, or at least preparing your own statements before execution.
Validate all user input
Have specific constraints of what kind of data you’re willing to accept from user input, and make sure the values of those variables matches what you’re expecting. Not only for values you are expecting the user to supply, but also for values the user is *capable* of changing, those you aren’t expecting such as GET and POST fields. You might think it’s safe to simply read “./sections/$_REQUEST[‘section].tpl”, process it and output the result, but if a malicious user supplies an unexpected value such as “../config/dbconfig.php; “, you have a serious vulnerability. Make sure any values that can be supplied by the user conform to expectations before using them.
These are just three very simple tips for avoiding common attack vectors, but there’s much more out there. Make sure you’re up to date on the current Best Practices and employ them in your code. Don’t wait until after your site is compromised to start worrying about these issues.
If you’re looking for a PHP host who cares about site security just as you do, visit A2 Hosting now!
