Databases are one of the most valuable assets in any form of online business or activity. Depending on the purpose they’re used for, databases can withhold user credentials (possibly unencrypted), social security numbers, credit card information, login history, and tons of other valuable information that can be used in malicious ways. Therefore, finding your way into a victim’s database can be on par with breaking into a bank’s safe.
That’s why databases continue to remain one of the most coveted targets of malicious actors. Though there are many techniques that enable hackers to gain access to database servers, the most popular method remains SQL injection (SQLi), a vulnerability that has achieved notoriety for its effectiveness and ease of exploitation.
Here’s what you need to know about SQLi attacks and how you can protect yourself against them.
What is SQL injection?
In a nutshell, SQLi is carried out by entering malicious SQL commands in a webserver HTTP requests in order to trick it into executing custom commands, possibly churning out valuable data, or worse, carrying out malicious actions on the targeted server. This is one of the oldest and most basic tricks hackers use, and yet it remains effective to this day.
SQL, or Structured Query Language, is the programming language used to retrieve or manipulate data in databases, or to define and change data structures. In a total simplification of the mechanism, whenever you type in a value in a web form and submit it, a SQL command string is formulated, in which your custom value is added, and executed against the database server. For instance, when you type in your name and password in a login form and attempt to enter a website, a SQL command is sent to the database server which checks whether the combination you’ve submitted exists in the table where user information is stored (it can actually be much more complicated and involve hashing and salting and other parameters – this is an oversimplification).
By knowing the basics and rules of the SQL language, you can modify your input value to change the behavior of the SQL command, and thus the web application you’re interacting with. That is the essence of SQL injection attacks.
For instance, the simplest SQLi attack can bypass the login entry form by entering the following famous string in the username field and an arbitrary string in the password field:
‘ or 1=1 –
Most websites are protected against such attacks, unless developed by a complete idiot and lack any form of input validation.
How bad is it?
The effects can vary anywhere between database access to the full compromise of the target server, i.e. devastating. The TalkTalk breach, which resulted in the theft of personal details of at least 150,000 people, was carried out in part through a SQLi attack. The same goes for the VTech hack, which resulted in account information for 5 million users and 200,000 children stolen by hackers. A researcher is awaiting trial and sentencing for hacking into a website for the elections division of a county in Florida. How did he do it? You guessed it: SQLi.
Even the recent Panama Papers leak, which blew the whistle on financial corruption for some high profile figures, is suspect of having been carried out through SQL injection.
This is just a glimpse of how widespread SQL injection attacks are. SQLi has consistently appeared at the top of the list of most severe vulnerabilities published by cybersecurity organizations such as OWASP. The security firm Imperva calls SQLi the “most pernicious vulnerability in human computer history” and the method behind 83 percent of data breaches that occurred between 2005 and 2011.
In most cases, SQLi vulnerabilities will enable attackers to dabble into the target database, siphon sensitive data, create or manipulate user credentials, delete posts and information or replace them with offending content. With a bit of trickery, hackers can manipulate database content to target the website’s visitors, e.g. insert malicious Javascript code into database fields that will later be rendered and executed on visitors’ browsers.
If the database is hosted on a shared server and user rights assignments haven’t been properly set, the attacker may gain access to adjacent databases which aren’t necessarily related to the hacked website. This means that while you might harden your website against SQLi attacks, a vulnerability in a neighboring site might damage you.
In the worst case scenario (in which the server is being administered by a complete doofus), the hack might spill beyond the database server and into the host server’s operating system. This can happen when the database connection is made through a system administrator account (“sa” in MS SQL Server or “root” in MySQL). In this case, the attacker can use special administrator procedures (such as extended stored procedures in MSSQL) in order to carry out commands against the operating system, such as creating new users, opening up share folders, enabling remote desktop access, disabling firewalls, etc. That’s when nightmare will erupt. A few years ago, I saw one such case happen on a web server, and the whole thing looked like a total mess, something like Jim Carrey after he got machine gunned in The Mask. The only solution was a full format of the server and the restoration of backups.
How do I protect myself?
Protecting your website against SQLi should involve different measures and safeguards, depending on the role you have in the development and production cycle.
If you’re a developer, the best way to protect your code against SQL injection attacks is to validate all user input. Wherever there’s data that is entered (or can be manipulated) by visitors, make sure you escape it with the proper functions in your programming language of choice. This accounts for input forms such as textboxes, browser address bars and query strings, file contents and anything else that comes from users and is inserted into SQL commands. The basic rule is to never trust user input.
An even more efficient alternative is the use of parameterized commands. Instead of concatenating different strings to formulate a SQL commands, use the parameterized versions of the SQL commands, in which the command is initially written with placeholders for user input and the user input is later added into the command through safe API calls.
Never think that input channels will be overlooked by attackers. There are many automated tools that help in the discovery of SQLi vulnerabilities, such as sqlmap, which crawls the pages of a website in the same way a search engine crawler might, and looks for vulnerabilities in input forms.
If you’re a database administrator, you have to make sure that hackers gain access to the least amount of data in case they manage to hack into your servers. Encrypting sensitive information such as user passwords is a vital first step. Never opt for plain text passwords. Use strong hash algorithms such as SHA-2 (MD5 and SHA-1 are obsolete). Throw in a little “salt” to add randomness and security, but don’t store salt values next to passwords.
If you’re storing sensitive information such as chat logs, financial data and password recovery questions and answers, use strong encryption to make sure that attackers will not be able to gain easy access to the info. But you also have to be mindful of where you store the keys. They shouldn’t be within the reach of the same person who has direct access to the database. As the saying goes, don’t place all your eggs in one basket. Split your data.
And a final database tip is to not to store unnecessary information in the first place. The Ashley Madison hack, which spilled some of the most intimate and controversial information of more than 37 million users, owed part of its success in ruining the lives of the site’s customers to the fact that the firm had not stayed true to its promise to wipe out profile info for users that requested to do so. Only store sensitive information if you have to and wipe them out when their use is up.
If you’re a web server administrator, make sure the website’s connection to the database server doesn’t have any extra privileges. The credentials used for the connection should only be able to access the database related to the website and nothing else. An extra protective measure would be to use a read-only connection for parts of the site that do not involve data manipulation. This will ensure that in case your website is found with a SQLi vulnerability, the damage is mitigated and remains within that specific database.
Under no circumstances should you use system administrator credentials for your database connection.
In case you’re using a shared environment for your web and database servers, check with your service provider to make sure that you’re protected against possible vulnerabilities in other websites. If you’re administering a shared environment yourself, never use common credentials between databases and websites, especially if you have no control over their source code.
In general, the key management measures to protect against SQLi attacks involve maximum isolation and least privilege assignment.
Final thoughts
SQL injection is old, yet still devastating and as far as it looks, it’s still going to be around for a while. However, protecting your website against it is in fact simple and it just takes meticulous planning and secure coding practices. I’ve discussed some general website secure coding practices in this Daily Dot article recently, but I know there’s a lot more to be said. So stay safe out there, and watch out for them vulns!