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 
. 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 
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 
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 
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: