The request is then passed from the Web server to the SOAP application server, though in some cases the application server may implement the Web server component internally. Once the request reaches the application server, another round of attacks is possible. Eventually, the body content of the SOAP request is pushed through an XML parser, which, depending on how the parser is implemented, could fall prey to XML structure attacks, structure/schema misvalidation and other vulnerabilities, such as an XML External Entities (XXE) attack.
Depressed yet?
Once the SOAP XML body content is finally parsed, the data can be interpreted to figure out which SOAP service to invoke and what parameters to pass to it. During this phase an attacker may attempt to invoke services not usually accessible or allowed. Or, an attacker may try to pass service parameter data that is invalid or unexpected. This usually is prevented by validating the attacker's data against the WSDL for the target SOAP service--but the validation can only be as thorough as the WSDL file that describes the service. Some WSDL-generation tools do not produce WSDL files that include security-specific attributes, such as maximum length restrictions on string parameters.
If the WSDL doesn't contain the specifics on how to best secure the SOAP service, the XML firewall could allow malicious data to pass. The WSDL file also cannot describe the specific contents of the actual parameter data, which leads to the last level of exploitation: the SOAP services.
The same gamut of vulnerabilities found in normal CGI/ Web applications still exists, in varying degrees, in SOAP services. All the custom code that actually implements the logic of the SOAP service is vulnerable to attacks, including buffer overflows, signed integer comparison attacks and SQL tampering.