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. 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 3rd 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. 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. 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. 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.
