This is a topic that everyone who writes scripts should be familiar with, and yet only within the past month I’ve worked with two custom scripts that were vulnerable to basic SQL injection attacks.
What is an SQL injection attack?
Any information that you gather from your website’s visitors via HTML forms is usually stored in a database. It’s a simple & efficient way to get this information in and out. So a script on your site takes the data from your HTML form (your customer’s name, e-mail, address, etc) and puts it in a database.
HOWEVER – What if we entered database commands instead of our e-mail address into that HTML form? We can then potentially play around with the data that we’re not supposed to see or edit. Sneaky, eh.
If the script doesn’t check for this, anyone who visits your site can have a free reign on your data.
This doesn’t stop there. The same can apply to dynamically built pages as well. For example, things like www.yoursite.com/index.php?customer=57
In the above case ’57’ is the input that’s supposed to be the ID of the customer. Malicious minded people may substitute that ’57’ for an arbitrary database command and have it wreak havoc on all your records.
How can it affect me?
If your scripts are vulnerable, anyone with enough knowledge can
- View your data, even if they are not supposed to
- Modify it. This includes deleting the entire database.
How you can protect yourself
If you are coding the script yourself, you may find these resources useful:
General guidelines are:
- Only accept the input that you expect, nothing else. So if you want to enter customer’s name into the database, make sure your script checks that they only enter letters in the field. if you’re expecting their e-mail, check that what they entered is in a proper e-mail format, and so on. See this page for more examples. Some will argue that sanitizing is more effective, but this point is important for other vulnerabilities as well. They both should be used. Which brings me to the next point.
- Sanitize the rest of the data to catch characters you might have missed in the above procedure.
- Use different databases for different scripts. So if one script gets ‘broken into’, your other information is safe
- Only store as much information online as you can afford to. Besides SQL injections, someone may break in and steal/read your information using other vulnerabilities
If you’re hiring someone to write a script that will communicate with a database, you should ask what steps they’ve taken to protect it against an SQL injection attack.
You shouldn’t panic, however. Most commercial & open source scripts are already protected against well known attacks and keep getting patched as new things are discovered.