SQL Injection

Structural Query Language (SQL) is a language used to program and manage data in relational databases. Originating in 1986, SQL has gained so much popularity due to its practicality and ease of use that these days most databases are formed around an implementation of SQL, for instance, MySQL or Microsoft SQL Server. 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 the system holding the database, there is another method of attack which could be utilized to gain access to the contained information or even to eradicate the data; SQL Injection.

SQL Injection attacks target the database directly by attempting to interact with it via for instance a web form field or a URL. The goal there is to send commands to the server which will then return an entire table containing usernames and passwords or even credit cards. This is how many of the massive breaches (up to 100+ million users) over the last decades have occurred.

Protection

There is a lot that can be done to prevent such an attack 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 are many books written about the endless way to perform SQL Injection attacks), imagine a web form asking for a username. Once entered, the provided username will be taken as input and will be processed in the background, for instance, to write it to a table in a database or to compare it to existing entries. This web form allows for interaction with the database, and if the attacker can supply input that escapes the underlying code and then execute his or her own commands, they 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 for individual characters to be used, should escape strings where needed and should use Prepared Statements wherever possible, amongst many other best practices. However, unfortunately, everyone makes mistakes and sanitization is complicated and time-consuming.

Another (additional) option is to filter incoming traffic for suspicious input via a Web Application Firewall or IDS/IPS solution. This would allow for the traffic to be dropped or alerted on before it even reaches the web server. These solutions can be expensive, however. They also present some challenges around encrypted HTTPS traffic. In that case, for a WAF or IDS device to be able to inspect traffic for malicious content, SSL interception will be needed, which can impact performance and can be even more expensive to implement and operate. By no means, these systems are a replacement for proper input sanitization on the server itself. Quite often these 3^rd party products are not aware of the type of data or system they are trying to protect, leaving many opportunities open to a smart attacker.

Cloud solutions

Because database and web servers are ideal candidates to be running 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 in the protection against SQL Injection attacks. It is great to see that providers do offer various products in this space.

Probably the most advanced solution is offered by Microsoft Azure: 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. This is a comprehensive 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 simply be too much to customize. This is really where the cloud shows one of its many benefits: low pricing due to standardization and its massive scale.

Of course, other providers offer these types of protection as well. Amazon, for instance, offers a virtual cloud version of the earlier mentioned Web Application Firewall. 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 (no need for hardware in the datacentre) and configuration and full integration with other cloud security products, like a DDoS protection product make this something to strongly consider when running a web and database server within any cloud platform.

Again, these cloud security products would be additional to a securely designed web front end and backend, which should include comprehensive input validation and fully patched systems.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Conclusion

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. More often than not, this leads to a loss of reputation, a substantial financial impact, but also to 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 well worth considering going that additional step and moving these systems to a cloud provider and then purchasing the database specific security products mentioned earlier.