Structured Query Language is used to program and manage data in relational databases. First making an appearance...
in an IBM Research paper in 1974, SQL has gained much popularity due to its practicality and ease of use. These days, many databases -- such as MySQL and Microsoft SQL Server -- are formed around an implementation of SQL.
Databases can hold sales data, customer information, medical records and financial information, meaning their contents could have enormous value. Therefore, they have been heavily targeted by malicious parties since the early days of computing.
Apart from the regular vulnerabilities that could be exploited to gain access to a system holding a database, there is another method of attack that could be utilized to gain access to the information or even to eradicate the data -- SQL injection.
SQL injection attacks target the database directly by attempting to get a web form field or a URL to interact with the database. The goal is to send commands to the server that cause it to respond, for example, with an entire table containing usernames and passwords, credit card information, or any other data stored in the database. This is how many of the significant breaches over the last few decades -- affecting up to 100 million or more users -- have occurred.
SQL injection protection
There is a lot that can be done to prevent SQL injection attacks from being successful, but the solutions can be quite complicated. Input sanitization is the primary prevention method; after all, why allow a malicious command to be executed in the first place?
Without going into too many technical details -- there have been many books written about the endless ways to perform SQL injection attacks -- imagine a web form asking for a username. Once entered, the p entries, for example.
This web form enables interaction with the database, and if the attacker can supply input that escapes the underlying code and then execute his or her own commands, the interactions could be processed as well. A few clever, quite simple commands could return hundreds of thousands of otherwise hidden database records to the attacker. Some attack methods can even create additional admin-level accounts within the server.
It is, therefore, critical that all input into web forms -- and associated HTTP POSTs -- is properly sanitized. A programmer, for example, should not allow certain characters to be used, should use escape sequences where needed so strings are not treated as commands, and should use prepared statements wherever possible, among many other best practices. Unfortunately, everyone makes mistakes, and sanitization is complicated and time-consuming.
Another option is to filter incoming traffic for suspicious input via a web application firewall or identity detection system (IDS)/identity protection system solution. This would enable the traffic to be dropped or for an alert to be sent out before the input even reaches the web server.
These tools can be expensive, however. They also present some challenges around encrypted HTTPS traffic -- SSL interception may be needed -- and are by no means a replacement for proper input sanitization on the server itself.
Because database and web servers are ideal candidates to run within a semi-isolated, highly scalable and highly available cloud environment, they represent a significant percentage of the systems within the various cloud platforms. This means cloud providers also have a role to play to prevent SQL injection attacks. It is great that providers do offer various products in this space.
The most advanced offering is probably Microsoft Azure's SQL Database Threat Detection. For just $15 per server per month, this service produces alerts based on SQL injection, anomalous database access patterns and potential vulnerabilities.
SQL Database Threat Detection is a broad service that would not have been available for such a low fee if the servers were running on custom hardware and software within an organization's own on-premises network. There would be too much to customize. This is really where the cloud shows one of its many benefits: low pricing due to standardization and its large scale.
Of course, other providers offer these types of protection, as well. Amazon, for instance, offers a virtual cloud version of the web application firewall (WAF) mentioned earlier.
Not only is there a requirement to place the WAF in the same cloud as the web and database server to intercept incoming web traffic, placing the WAF in the cloud has some further benefits, as well.
Like many other cloud services, the ease of deployment and configuration and full integration with other cloud security products, like a distributed denial-of-service protection product, make Amazon's WAF something to strongly consider when running a web and database server within any cloud platform.
When it comes to publicly accessible web and database servers, an organization does not get a second chance. Once the data is compromised, it will forever be in the public domain. This often leads to a loss of reputation, a substantial financial impact, and legal battles around compliance and due diligence.
Hardening servers, applying input sanitization and building a layered defense of security products, such as IDS and proxy devices, is a good start. On top of that, it is worth considering moving these systems to a cloud provider and then purchasing the database-specific security products mentioned here.