It is likely that SQL injection was involved in at least some of these breaches. For more than 10 years, attackers have broken into countless databases using SQL injection to steal information such as account data and transaction details. 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 still involve SQL injection at some point. That begs a question: Why are SQL injection attacks still so effective? It’s not for lack of trying. Security professionals are well aware of the threats posed by SQL injection – flummoxed by the rapid evolution of the latest attacks. What’s more, most attacks leverage zero day vulnerabilities – so the attack vectors have not been seen before and do not exhibit telltale signs of an intrusion. This poses problems for most security professionals, especially those that rely on signature-based security technologies to detect and prevent attacks. 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 missing an attack in progress. Products using this type of an approach are emerging, including DB Networks’ SQL Injection management solution, which was recently reviewed on Enterprise Networking Planet. That said, it becomes obvious that there should be some best practices for reducing the possibility of a SQL injection attack. Three practices focus on the management and design aspect of a SQL database system:

  1. Do Not Blindly Trust InputSimply put, any input into the SQL engine should be validated – which means 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.
  2. Create Error Messages with CareAttackers often use poorly crafted error messages to figure out how to better attack a database. Developers and DBAs need to consider what information is returned via an error, when there is unexpected input. For example, if a logon error comes back with “user names cannot contain numbers,” that may give an attacker insight on how to leverage pilfered user account information.
  3. Keep Databases and Applications Fully PatchedIt 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 a combination of these and other factors. For many, the only solution is to implement a patch management system that removes manual tasks, which often fall through the cracks. While these best practices are a good start, there are other practices that should be considered. These three practices may incur additional costs, but are ultimately worthwhile in the long run if they prevent a breach from occurring.
  4. Implement Network Monitoring ToolsMonitoring 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.
  5. Implement Filtering ToolsRealtime security applications can work with monitoring systems to block attacks as they occur, by filtering the suspect traffic and denying access to the database.
  6. Enhance Database SecurityAdditional authentication systems that work with single sign on (SSO) solutions and can integrate with backend databases and application security controls 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. We have gathered this information from esecurityplanet.com written by: Frank Ohlhorst