Forum Post: Security Think Tank: Quick time to market to blame for many SQLi attacks

In response to

---

Source

Cyber criminals are typically after your data for monetary reasons. From their point of view, the most valued asset in your network is your customer or payment card database; the bigger the merrier.

If your customer application is accessible to the internet, it is almost certain that you will have a web-application-database model setup, and SQL connection would be used to access data in the backend database. It is no surprise that injections are the top means of attack, as documented in the Open Web Application Security Project (OWASP) Top 10. But why is that the case?

The answer is surprisingly simple. The developers code the web applications with a speed to market objective in mind. The security of the data is typically a secondary, or even lower, priority for them. It only takes a small mistake in the web application setup, architecture or code, and the SQL injection attack could be used to manipulate query that the application server sends to the database server. Such an attack could mean that within minutes or hours, depending on the database size, your data has all gone into wrong hands.

All this is still happening now to some companies, despite the fact that the remedy is so close, so easy to use, and mostly free. So what should your company do to minimise the likelihood of a successful SQL injection attack? I believe in defence in depth, and in this case, it certainly works.

First, developers must be trained in the web and database security architectures and coding techniques, for example by studying OWASP Top 10.

Second, a multi-tier architecture, with security control points between tiers is essential – a web application firewall in front of the web server, and database firewall in front of the database server. These should be monitoring and controlling access. While this is not foolproof, these appliances should catch 80% of attacks.

Third, instead of creating SQL statements in the application use database views, stored procedures or prepared statements, let database server handle security for you.

Finally, monitor for application and user behaviour by collecting logs and analysing them for anomalies.

If you implement all of the above, suddenly you will be a much less attractive and easy target, making it more expensive for criminals to attack you. And guess what, there might just be another company not as clever and determined as yours.