Security

Tips to prevent rising danger from SQL injection attacks

SQL injection attacks may be on the rise, since database usage and the applications that interconnect databases are increasing.

The mainstream press has been flooded with revelations about major security breaches which have exposed confidential information to sources unknown. Major retailers, such as Target, Michaels and Neiman Marcus, as well as hotel chains such as Hilton and Marriott have recently become the victims of major breaches, indicating that attackers are becoming more successful at extracting confidential data.

Even more troubling is the fact that most of those high profile victims have yet to figure out how exactly those breaches occurred and what the full extent of the damage was. What’s more, concerned system administrators have been kept in the dark, simply because major news outlets are not reporting on any of the in depth details on how those attacks came to be successful.

Danger from SQL injection attacks

It is likely that attacks based on SQL injection techniques were involved at some point in time. SQL injection attacks are not a new phenomenon and security professionals are more than capable of protecting against them. However, according to Neira Jones, former head of payment security for Barclaycard, some 97 percent of data breaches worldwide are still due to SQL injection somewhere along the line. That fact begs a question – why are SQL Injection attacks still so effective?

For the most part, security professionals are well aware of the threats posed by SQL injection, yet are flummoxed by the rapid evolution of the latest attacks. Further complicating effective preventative measures is the fact that most attacks leverage zero day vulnerabilities. Simply put, the majority of the attack vectors has not been seen before and lacks the indicative signs of an intrusion. That creates a very difficult situation for most security professionals, especially those that rely on signature based security technologies to detect and prevent attacks.

Michael Sabo, vice president of marketing at DB Networks, a company that develops technologies to deal with SQL injection attacks, said, “battling SQL injection must take a different approach, one that identifies what is normal access and what falls out of the norm, all without creating false positives for attacks and at the same time, not miss an attack in progress.” Sabo made a valid point and indicated that automatic technologies that can identify attacks are becoming a must have for any business with an online presence.

Security solutions

However, the market is filled with security solutions and finding what works best for a given implementation will take some research. Nevertheless, administrators today should at the very least follow some best practices to keep their databases as secure as possible. Some best practices focus on the management and design aspect of a SQL database system, and prove easier to implement:

First and foremost is a practice that database developers should adhere to – “Do Not Blindly Trust Input”. Simply put, any input into the SQL engine should be validated – which means that organizations should build and enforce secure coding guidelines that requires SQL be constructed using parameterized queries. A coding intensive technique that prevents SQL injection attacks by separating executable code from inputted data.

Secondly, create error messages with care – attackers often use poorly crafted error messages to figure out how to better attack a database. Developers/DBAs need to consider what information is returned via an error, when there is unexpected input. For example, if a logon error comes back that “user names cannot contain numbers”, that may give an attacker insight on how to leverage pilfered user account information.

Thirdly, keep databases and applications fully patched. It should go without saying that security patches should be regularly applied, however patching is one of the most overlooked security techniques. That may be due to poor management, lack of vendor notifications or any combination of other factors. For many, the only solution is to implement a patch management system that removes the manual tasks, which often fall through the cracks.

While the above best practices are a good start, there are other practices that should be considered – regrettably those other practices may incur additional costs, but are ultimately worthwhile in the long run, if they prevent a breach from occurring:

  • Implement monitoring tools: Monitoring access activity at the application level can quickly give an indication that an attack is occurring. Simple clues, such as an increase in errors, or an increase in activity can be used to warn administrators of an attack in progress.
  • Implement filtering tools: Real time security applications can work hand in hand with monitoring systems to block attacks as they occur, by filtering the suspect traffic and denying access to the database.
  • Enhance security: Additional authentication systems that work with SSO (Single Sign On) solutions and can integrate with backend databases and application security controls and can bring additional protection to vulnerable databases. What’s more, high end authentication systems also incorporate logging and auditing capabilities, as well as control the native privileges that are associated with high-end databases. In other words, privileged access is only available to administrators and if others try to gain privileged access, the event is recorded and reported.

Combining best practices with aftermarket technologies proves to be the best path to protecting databases from SQL injection attacks, which are likely to remain a major threat to enterprises both large and small.

About

Frank J. Ohlhorst is an award-winning technology journalist, author, professional speaker and IT business consultant. He has worked in editorial at CRN, eWeek and Channel Insider, and is the author of Big Data Analytics. His certifications include MC...

2 comments
pgit
pgit

I saw an outfit that validated remote users via a VPN first, technically putting them on a firewalled LAN containing the sql server.


This sql was not the back end for a public web site, it was for internal corporate use. But couldn't something like this be used in a situation where info from the sql server has to reach the public?


Why couldn't a service do something like have you install openssh and set up public/private keys first, and use the (encrypted) shell for the DB content?


Perhaps there's a niche here for someone to create a lightweight vpn-like first step that would discriminate who even has a shot at logging into the sql server? (talk about "2 factor authentication!") Unless you're validated on a virtual LAN you can't even see the sql server, let alone feed it bogus input.

davist@childrensfactory.
davist@childrensfactory.

This became a major concern as we drove much of our business to our website.  One thing I think that is often overlooked is security at the database level.  


Some Admins I know allow the account connecting from the web far too much unrestricted access to their database.  We took a different approach and locked that user into specific tables that they have only specific permissions to sometimes even creating views of tables so the original was "invisible" to the outside user.   Combine this with prepared statements and a few other checks and though we are not bullet proof I feel much more comfortable letting outsiders near my data.

Editor's Picks