Common Vulnerabilities In Web Apps: SQL Injection

Web Application Risks: SQL Injection

Welcome to the second of five posts on the top vulnerabilities found in vendor and bespoke web applications. Here, InfoSec Pro Kai Stimpson focuses on the second most common vulnerability we encounter – SQL Injection.

You can catch the first post on broken authentication here.

What is SQL injection?

SQL (Structured Query Language) injection is a technique used for attacking data-driven apps. Despite having been around for nearly 20 years, it continues to pose a significant risk to many web applications.

SQL injection maintains its presence in OWASP’s (The Open Web Application Security Project’s) top 10 most critical web application security risks, the latest copy of which may be accessed here:

OWASP Top Ten Project

SQL Injection occurs when a SQL query is constructed in an unsafe manner that includes user supplied input that has not been sanitised.

When an application fails to protect against SQL injection, an attacker can exploit this to inject their own malicious query in an attempt to formulate a variety of attacks. Such attacks can include:

Retrieving and modifying information stored in the database
Executing administration operations on the database
Performing remote command execution without proper authorisation

The resources detailed below provide a wealth of information on how SQL injection can be exploited to attack a web application that has either an integrated MySQL Database or Microsoft SQL Database.

How to Mitigate the Risks of SQL Injection

Parameterised Queries

Implement parameterised queries so that the application sufficiently escapes user supplied input. This will help to ensure that user-supplied data won’t break out of the constructed SQL query that is written into the application.

Whilst parameterised queries are generally the preferred mitigation method, if this is not possible the implementation of stored procedures may be an option.

Stored Procedures

Stored procedures, similar to parameterised queries, can generally be implemented safely via the implementation of strict validation and escaping, as long as they do not include any unsafe dynamic SQL generation.

Sanitising Input / Escaping User Supplied Input

Finally, an inferior technique to parameterised queries is sanitising input alongside escaping user supplied input. This method should be used with care as mistakes can be made that leave certain parameters vulnerable to SQL injection if not implemented appropriately.

This method involves implementing functionality to remove / escape malicious characters and accept only ‘known-good’ user supplied input that is being passed to a particular parameter.