SQL Injection

What is it

As the saying goes “it is all about information in the security world”, people with malicious intent will always wanted to gain access to information stored in databases.

All web applications be it traditional or newer ones deal with data in some manner or the other. They mostly utilize a database management system to store data and querying is done by using Structured Query Language (SQL).

Applications generally reveal data ONLY to the legitimate users identified based on their inputs. The inputs are then used to create a SQL query which would be passed onto the database, gets executed and sends results back to the application to be displayed to the user.

What does this have to do with security?

Well, if developers hard code the SQL query so that user input is directly pasted to the query (making the user input a part of the query), then a malicious user can pass some inputs (via the input interface like a form) and this could get included in the SQL query. Due to the modified query getting executed, the user sees what he desires rather than what the application was designed to show.

How serious is it

SQL injection is a widespread vulnerability across many web applications and statistics suggest it to be the root cause among most data breaches.

The impact of someone gaining access to your application or system through SQL injection may result in

  • Understanding the database structure. This enables them to write targeted queries to access data
  • Gaining access to the data contained in your system (loss of Confidentiality)
  • Possible loss of data (loss of Availability)
  • Possible modification of data (loss of Integrity). User accounts usually have privileges to run database queries

The amount of data an attacker can retrieve depends on multiple factors like his creative skills, system design and implementation.

How to prevent
Sanitize User Input. Never generate SQL by directly using user inputs. Attacks like Cross Site Scripting use this vulnerability to insert and execute malicious code on the applications. A better idea is to not trust any user input and sanitize it. Every language worth its salt has some sanitization library in place. OWASP ESAPI (The OWASP Enterprise Security API) libraries are also available for all major languages and could be used.

Use Parameterized Queries

Most platforms like .Net and Java support parameterized queries to generate dynamic SQL. A parameter input is mostly treated as a literal value and not treated as dynamic/executable code.

Use Database Functions/Stored Procedures

Stored procedures are a better way to handle SQL functions. However special importance needs to be put onto their usage as parameterization here would jeopardize the efforts to prevent SQL injection. Parameterized stored procedures are equivalent to having no input sanitization and could still result in SQL injection.

  • Use Web Application Firewall
  • Use a WAF to create a protection shield without any change in existing applications. A web application firewall will help you identify & stop any attacks (Note that they may need to be configured properly in order to provide maximum value).
  • Use Least Privilege Access.
  • Limit access to data by implementing techniques such as Role Based Access Control (RBAC). Do not allow every user to be able to run all queries as this could result in abuse of privileges.
  • Exception Handling
  • Improper exception handling will not allow an application to fail gracefully. This could also result in revealing crucial information post-crash. A malicious user can tweak certain queries in order to inject them in the application.
  • Avoid Obvious Names
  • Attackers also resort to guessing crucial information labels (Ex. Database names, table names, table prefixes, user IDs, passwords etc.). Change all default values while setting up the system including credentials and configuration settings.