SQL Injection


1. Introduction

SQL injections are still one of the most common ways of attacking web services, even though the risks are huge and it's very easy to avoid. The attack exposes that a Web Service is not (correctly) filtering user input that ends up as parts of SQL statements. The idea is to send malicious SQL code in a parameter field, in hope that the server will execute the code.

In 2009, one American and two Russian citizens were charged with what has been called "the biggest case of identity theft in American history". By using an SQL injection attack on servers in California, Illinois, Latvia, the Netherlands and Ukraine they stole 130 million credit card numbers. Among the companies hit were 7-Eleven.

1.1. Typical real-world attack

For example, suppose that the following code is used on a web application server to verify that a userName (sent as a parameter in a SOA request) exists in the database:

statement = "SELECT * FROM `users` WHERE `name` = '" + userName + "';"

The code may look fool proof at first glance, but the complete statement is easily bypassed by an attacker using the following string as userName:

' or '1'='1

1.2. What it does

The SQL Injection Security Scan tries to attack the web service by replacing the TestStep's original parameters with malicious strings, designed to expose potential flaws in web services that are using an SQL server. By using assertions, you can assure that the attack didn't expose sensitive data, return a session ID, etc.

2. Usage

Start by specifying which parameters to inject malicious SQL code into by using the Add, Remove, Copy, Clone and Extract all buttons 1_snag_evi. The Extract all button will extract all non-empty parameters from the tested request.

Then add assertions using the controls at the bottom of the window 5_snag_evi that checks if the injection succeeded. Some assertions that would typically make sense for the SQL Injection Security Scan is:

  • XPath Match, e.g. to look for a session ID that reveals an unauthorized login.
  • Sensitive Information Exposure, e.g. if database or database wrapper crashes.
  • Valid HTTP Status Codes, e.g. to assert that the request does not return a 5xx status code (Server Error).

These assertions will be added/suggested automatically if the Security Test is generated by the Security Test Wizard in ReadyAPI.

2.1. Configuration

The Strategy tab 3_snag_evi lets you configure if the scan should be run on failed TestSteps, how long it should wait between each request and how SoapUI should combine attacks on multiple parameters:

  • The One by One strategy iteratively tests each malicious value for each selected parameter, leaving all parameters but the currently tested at their original value.
  • The All at Once strategy iterates through the list of malicious values just once, applying the same malicious value to all selected parameters.

From the Advanced tab 4_snag_evi you can review and edit the list of malicious strings used by the SQL injection scan.

3. Prevention & Further reading

Read more about SQL Injections and how to protect yourself at the following websites: