IT Blog

PHP Security

Hiring a PHP Programmer: Part #1, SQL Security

PHP is a fantastic web development language if for no other reason than its low learning-curve to create dynamic, database-driven web sites quickly. For this reason and others, there has been an obvious influx of web developers ready to hire-on to create your company’s next web application or site. Just like any other employee, contractor or otherwise, you want to be sure that the work being done isn’t just quickly thrown together by a novice, but that there is consideration with regard to appropriate programming practices and security being thought of during development.
Update: Read Part #2 here and Part #3 here.
While it’s impossible to give a black-and-white answer as to whether code you may be looking at is ‘good’ or ‘bad’, there are a few things to keep an eye out for to at least ask your developer appropriate questions about the work they are doing. Over the next few posts we will be detailing some helpful information that you can utilize to be an informed employer and make sure your money is being well spent.
SQL Injection Security
While you’ve no doubt heard the phrase ‘SQL Injection’ you may be unsure how this topic relates directly to PHP and what ‘secure’ versus ‘insecure’ programming practices may look like. The largest part of security-minded SQL programming is to always ensure the data being given to a database query has been scrutinized in some way so that ‘malicious SQL’ doesn’t ever have access to your data in a way that you didn’t intend. For instance, consider this example:
$query = "SELECT firstName FROM users WHERE user = '" . $_GET['user'] . "'";

The issue with this code is that whatever a user passes to their web browser for the ‘user’ value will be passed directly to your SQL database query. In the below example an attacker would be able to simply output a desired user’s password to the screen rather than the expected first name.' UNION SELECT password FROM users WHERE user = '1
Questions to Ask Your Developer:

  1. What database framework do you utilize?
  2. How do you prevent SQL Injection?
  3. Do you validate all input (GET/POST) data?
  4. Do you use parameterized/placeholder SQL statements?

Related to point #1 above, database frameworks like PEAR::MDB2 are trusted and heavily reviewed. Generally speaking, there should be little need for a developer to use a ‘custom’ framework. Often times these ‘custom’ frameworks will be very lacking in basic security features. By sticking to a common database framework you will have extremely well-tested code by competent developers helping to ensure your database security.
Another complement to your database security is to use a database firewall such as GreenSQL which will force all SQL queries to pass through a series of checks to verify that they aren’t malicious. While this sort of software adds a layer of complexity to your deployment of applications it can be a huge safety-net for insecure code.
Remember, your database contents aren’t just your data, it’s often the Publicly Identifiable Information (PII) of your customers or worse, their financial or healthcare data. Strong database security is an important first step for any business to consider when deciding to deploy a web application, be sure that your developers are well versed in the above methods of security before proceeding.

Looking for some help?

Expert Linux server consulting, security services, 24×7 monitoring and management is where we shine. Give us a call at 888-877-7118 or click here to request a proposal.

3 thoughts on “Hiring a PHP Programmer: Part #1, SQL Security”

  1. I wouldn’t even consider myself proficient enough to do even the most menial PHP development job. I have always taken preventative measure against SQL injection, even before I knew the concept existed. Validating input just seems natural.

  2. hiimleath, thanks for the response. Unfortunately your dedication to scrutinizing data before passing it along is not the common line of thought for many contract programmers out there! Implementing basic functionality like prepared statements takes little effort but often developers get used to doing things a certain way and never evolve their practices to include security enhancements.
    Another consideration is that as a programmer grows they may realize previous attempts to sanitize data may not have been effective enough. For instance, some developers may try to prevent SQL injection on ‘GET’ variables but completely ignore ‘POST’ variables because they don’t realize that an attacker can simply write a custom form and submit the data manually.
    Just like buffer overflows in application code that can be checked for data size easily, developers often still forget or ignore doing basic tasks because they assume their code won’t be attacked or they’ve had some other system in place to ‘prevent’ those attacks. A layered and complete defense is the only chance for better-than-average code security. We hope more businesses take a look and encourage the developers they hire to adhere to more professional security practices!

Comments are closed.