| Name |
SQL Injection through SOAP Parameter Tampering |
|
| Likelyhood of attack |
Typical severity |
| High |
Very High |
|
| Summary |
An attacker modifies the parameters of the SOAP message that is sent from the service consumer to the service provider to initiate a SQL injection attack. On the service provider side, the SOAP message is parsed and parameters are not properly validated before being used to access a database in a way that does not use parameter binding, thus enabling the attacker to control the structure of the executed SQL query. This pattern describes a SQL injection attack with the delivery mechanism being a SOAP message. |
| Prerequisites |
SOAP messages are used as a communication mechanism in the system SOAP parameters are not properly validated at the service provider The service provider does not properly utilize parameter binding when building SQL queries |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Detect Incorrect SOAP Parameter Handling] The attacker tampers with the SOAP message parameters and looks for indications that the tampering caused a change in behavior of the targeted application. |
- The attacker tampers with the SOAP message parameters by injecting some special characters such as single quotes, double quotes, semi columns, etc. The attacker observes system behavior.
|
| 2 |
Experiment |
[Probe for SQL Injection vulnerability] The attacker injects SQL syntax into vulnerable SOAP parameters identified during the Explore phase to search for unfiltered execution of the SQL syntax in a query. |
|
| 3 |
Exploit |
[Inject SQL via SOAP Parameters] The attacker injects SQL via SOAP parameters identified as vulnerable during Explore phase to launch a first or second order SQL injection attack. |
- An attacker performs a SQL injection attack via the usual methods leveraging SOAP parameters as the injection vector. An attacker has to be careful not to break the XML parser at the service provider which may prevent the payload getting through to the SQL query. The attacker may also look at the WSDL for the web service (if available) to better understand what is expected by the service provider.
|
|
| Solutions | Properly validate and sanitize/reject user input at the service provider. Ensure that prepared statements or other mechanism that enables parameter binding is used when accessing the database in a way that would prevent the attackers' supplied data from controlling the structure of the executed query. At the database level, ensure that the database user used by the application in a particular context has the minimum needed privileges to the database that are needed to perform the operation. When possible, run queries against pre-generated views rather than the tables directly. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-20 |
Improper Input Validation |
| CWE-89 |
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-66 |
This attack exploits target software that constructs SQL statements based on user input. An attacker crafts input strings so that when the target software constructs SQL statements based on the input, the resulting SQL statement performs actions other than those the application intended. SQL Injection results from failure of the application to appropriately validate input. |
| CAPEC-108 |
An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host. |
|