Prevent SQL Injection Before a Data Breach

SQL Injection


  • Don’t assume your application is secure
  • Simple fix prevents SQL injections
  • Better coding eliminates queries passing SQL syntax directly to the database

Data breaches seem to occur every week, putting millions of people’s personal information and identities at risk. In many cases if IT would just sanitize the data, the threat of reoccurrence would drop considerably.

  • July 2015Planned Parenthood was one of the latest victims of a SQL injection attack that allowed the dump of multiple databases.
  • 2014 – More than 1 billion passwords were stolen from 400,000 websites by a group of Russian hackers using a botnet with a SQL injection attack.
  • October 2013Hackers stole copies of corporate news releases from three news services for years to generate $100 million in illicit proceeds for them and traders, according to Securities and Exchange Commission regulators.
  • December 2012 – A hacktivist collective stole accounts from NASA, the FBI, the Pentagon, Interpol and many others, posting information from 1.6 million accounts online. The file dump appeared to include records obtained via SQL injection.

Most of these data breaches aren’t happening because of some complex coding by hackers. Usually it’s something pretty simple that could have been stopped at the source, such as when hackers perform a SQL injection to gain access.

Whenever a website has a query form, it’s possible that access is available to the database. If the website does not filter out dangerous or non-conforming data before it’s handed off to the database, the organization is open to a possible data breach. A hacker can submit some text with a single apostrophe to find out if the form is a direct query to the database. If a database error is returned, then the hacker knows the code has included the user input into the syntax of a SQL query. This bad code exposes the database. The website should filter all user input.

The following string used in a web-based login form could, for example, expose your User tables, providing a hacker with personal information on your users – and access to the entire database through the login information stored in these tables.
‘; ‘Select * From Users;

Many experienced hands at coding will say sanitizing the data isn’t even the root of the problem. Don’t write any SQL queries using user input. There’s always stored procedures or variable binding with prepared statements to handle user input.

It shouldn’t be difficult for organizations to secure their databases from SQL injection threats. Guides to preventing SQL injection prevention are easily found. A thorough and technical cheat sheet has been created by the OWASP Foundation. This foundation makes software security challenges its business.

It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.
OSWAP SQL Injection Cheat Sheet

However, it’s clear that the message isn’t getting through to everyone, as we keep reading about these data breaches. If you don’t know whether your organization has secured its SQL databases from just this one potential pain point, then you can’t be sure that anything is secure. If you claim your application meets regulatory compliance such as HIPAA but this gaping hole is left open, you’ve set your organization and your clients up for legal troubles.

Steps to Close a Potential Data Breach

  • Examine your security policy to make sure it sets minimum requirements for password strength, encrypting private data, proper use of admin passwords and any other security issues.
  • Strongly suggest to your clients that they have just as strong a security policy.
  • Check code for logins and other forms to determine if SQL queries are being passed to the database(s).
  • Are these SQL queries unfiltered? If you answered yes, you have problems.
  • User logins should query the database with each account limited to the relevant credentials table to avoid compromising the entire database.
  • Sanitize all user input, disallowing all characters except those specific to the data context. Numeric input fields should filter out any non-numeric input data before passing it to the SQL command.
  • Even if those SQL queries are filtered, seriously consider changing your code to use prepared statements or stored procedures. If this can’t be done immediately, include it in your next batch of updates.
  • Make sure you validate all input, including forms, data from the database and from wherever else data is being streamed.


OWASP SQL Injection Prevention Cheat Sheet
How to Prevent SQL Injection Attacks eSecurity Planet
SQL Injection: When Will We Learn? The Code Curmudgeon
SQL Injection Hall of Shame The Code Curmudgeon
Securing Self-Service BI in Your Application Izenda

Izenda integrates with your application, inheriting its security structure for multi-tenant environments down to the row level.

Request a live demo

Follow Izenda on social media for the latest on technology and business intelligence: