CAPEC-110 - SQL Injection through SOAP Parameter Tampering

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.






  • Attack Methods 2
  • Injection
  • Analysis
  • Purposes 1
  • Exploitation
  • Sec Principles 2
  • Defense in Depth
  • Least Privilege
  • Scopes 5
  • Modify application data
  • Integrity
  • Unexpected State
  • Availability
  • Read application data
  • Confidentiality
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality
  • Execute unauthorized code or commands
  • Availability
  • Integrity
  • Confidentiality

Medium level: If the attacker is able to gain good understanding of the system's database schema

High level: If the attacker has to perform SQL injection blindly

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

No specialized hardware resources are required

Inject SQL characters in SOAP parameters and observe system behavior

Review WSDL to understand what is expected by the service provider

Remember that the client can be made invisible

Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-Web

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.

Indicator ID: 1 - Environment(s) env-Web

Type: Positive

SOAP messages are used as a communication mechanism in the system

Outcome ID: 1

Type: Success

Any indication that the injected input is causing system trouble (e.g. stack traces are produced, the system does not respond, etc.) then the attacker may come to conclude that the system is vulnerable to SQL injection through SOAP parameter tampering.

Step 1 - 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..

Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-Web

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.

Outcome ID: 1

Type: Success

Attacker achieves goal of unauthorized system access, denial of service, etc.

Outcome ID: 2

Type: Failure

Attacker unable to exploit SQL Injection vulnerability.

Always safely access the database through prepared statements that leverage parameter binding

Properly validate all SOAP parameters to ensure that their values are as expected

Reject bad user input (do not try to sanitize it)

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.