Learn what is the purpose of SOAP APIs, how they function, the main difference between REST and SOAP APIs, and what you can do to prevent the 7 most common SOAP API vulnerabilities.
In this article, you will learn:
- What are SOAP APIs
- What is SOAP Security?
- The Difference Between SOAP and REST APIs
- Top 7 SOAP API Vulnerabilities and How to Prevent Them
- SOAP Security Best Practices: Preventing SOAP Security Threats
- Automating SOAP Security with Bright
What are SOAP APIs?
Simple Objects Access Protocol (SOAP) originated in 1998. It’s a web communication protocol that was designed for Microsoft. Nowadays SOAP is used to send data over both HTTP and HTTPS. However, SOAP isn’t limited to just those protocols. SOAP supports XML data format only. Preset standards like a set of encoding rules, messaging structure, and a convention for granting procedure requests and responses are standard practice for SOAP.
SOAP data format
Unlike REST APIs, which support both JSON and XML, SOAP only supports XML both for requests and responses.
SOAP messages follow a standardized structure as well. Why are SOAP API requests and responses considered heavy? Because they appear as enveloped messages. Each message is made out of four elements that have unique functions for each one:
- Envelope. The core element of all messages. It tags start and end messages, enveloping it in a sense.
- Header. The header is an optimal element. It defines extra requirements like authentication.
- Body. Contains the data needed to process the request or the appropriate response to the user.
- Fault. Another optional element. Showcases data about errors that can appear throughout API requests and responses.
WS standard protocols
SOAP can also be extended with WS standard protocols. SOAP on its own already provides basic structural elements for messages. But it doesn’t direct the things that go into bodies and headers. Standard protocols augment the main protocol. They specify how you do particular things. WS- is the mark of these protocols and WS-Security is an example.
Another important SOAP API feature is the use of WSDL documents. WSDL documents are XML descriptions of a web service that SOAP APIs continually use and are the abbreviation of web-service-communication guidelines. They describe all processes that exposed applications can perform and they define endpoints. This includes data types that are used inside SOAP messages and any action that’s available through the web service. WSDL file services act like signed contracts between servers and clients.
What is SOAP Security?
SOAP security includes strategies and practices for preventing unauthorized access to SOAP messages and user information, tampering with SOAP APIs, and disruption of normal operations. Web Standard Security (WS Security) is a key element in ensuring SOAP security.
WS-Security is a set of principles/guidelines for standardizing SOAP messages using authentication and confidentiality processes. WSS-compliant security methods include digital signatures, XML encryption, and X.509 certificates. XML encryption prevents unauthorized users from reading data when accessing it.
While WS-Security provides enhanced security controls that are built into many SOAP APIs, organizations still need to set up these controls correctly, and ensure they cannot be bypassed. Critical SOAP security practices include input validation and sanitization, ensuring access control, and configuring authentication for all API endpoints, as well as for SAML-based single sign on (SSO) systems.
Are SOAP APIs More Secure than REST APIs?
The short answer is yes, SOAP APIs are more secure. To understand why, let’s explore the differences between these two types of APIs.
SOAP is a format used for message exchange. REST, on the other hand, is an architectural style. REST Sample Implementations use JSON over HTTP. SOAP Sample Implementations use XML over SOAP over HTTP.
The REST architectural structure focuses on using HTTP Transport. SOAP focuses on restricting your message structure:
- When it comes to the Data Exchange Format, SOAP is always SOAP-XML. This XML includes an envelope, a header, and a body.
- REST always uses HTTP as a transport protocol. REST also uses HTTP features like Response headers, Response, Request methods, etc.
In regards to the Message Interchange Format, SOAP uses the SOAP XML format for Request and Response. REST doesn’t need a fixed format. It’s the same thing for Service Definitions. SOAP uses WSDL while REST doesn’t have a standard service definition language. When we’re talking about Transport, SOAP doesn’t restrict the transport protocol that’s used. Both HTTP and MQ are available. REST utilizes the HTTP Transport Protocol.
To summarize the differences:
- SOAP services offer more comprehensive security measures, but REST services are much easier to implement.
- SOAP needs you to define your service via WSDL which comes with a lot of overhead. REST uses JSON that is much simpler to process and parse.
- REST doesn’t need a service definition to provide you with a web service
Top 7 SOAP API Vulnerabilities
We have now covered the basics. Now let’s talk about the 7 most common vulnerabilities and how to prevent them.
The most common SOAP API vulnerabilities include:
- SOAP Injections
- SOAP Action Spoofing
- SAML Vulnerabilities
- Replay Attacks
- Cross-Site Scripting
- Broken Access and Authorization
- Denial of Service (DoS)
SQL injection is a web security vulnerability that could allow an attacker to tamper with database queries made by an application, injecting malicious code into queries. In the context of SOAP APIs, this involves injecting malicious SQL queries into API calls that use SQL syntax as part of their inputs. If your API is vulnerable to SQL injection, attackers can change the content or behavior of an application and in some cases compromise the entire server.
XML Injection (XXE)
An XML or SOAP injection vulnerability occurs when user input is insecurely injected into a server-side XML document or SOAP message. Attackers can use XML metacharacters to change the structure of the generated XML. Depending on the XML capabilities enabled on the server side, it can interfere with your application’s logic, perform malicious actions and allow attackers to access sensitive data.
Command injection is an attack designed to execute arbitrary commands on the host operating system through a vulnerable application. In the context of SOAP APIs, any API that accepts user inputs and performs operating system commands, such as creating directories or accessing files in the file system, can be vulnerable to command injection.
A command injection attack can occur when an application passes insecure user-supplied data (forms, cookies, HTTP headers, etc.) to the SOAP API, which then passes the data to the system shell. In this type of attack, commands injected by the attacker are typically executed with the privileges of the server side of the SOAP API.
XAML Injection attacks are made possible when untrusted input is involved. XAML is the markup language that’s used to directly represent object execution and instantiation. What does that entail? Any elements made in XAML are able to interact with system resources. What happens when a hacker gains control of the XamlReader method call input? They can execute malicious code.
To protect against XAML injection, Microsoft enforces a rule in their IDEs, but this rule is not foolproof and can be disabled. The best prevention practice against this is manually validating and sanitizing the received input (learn more below).
SOAP Action Spoofing
Every HTTP request contains a field called a SOAP action, that is used to perform an action defined on the content. If communication is not encrypted, an attacker can place themselves between the client and the server, and perform a variety of bypass or man-in-the-middle (MitM) attacks that can modify the content of SOAP requests or responses.
Security Assertion Markup Language (SAML) originated way back in 2001. It is an XML-based open standard that provides authorization and authentication services. It lets identity providers pass authorization credentials to a service provider (for example, Salesforce SAML SSO). SAML is a common way to implement single sign on (SSO).
How is SAML vulnerable? Hackers found a way to modify SAML body content, but without invalidating the cryptographic signature. That’s the trick, you bypass the main authentication for any affected SAML service provider. A hacker that obtains access to one or compromises another account can then add comments to any attribute, obtaining an administrator account, for example.
The biggest problem with APIs is that they’re open to the public. In the sea of incoming requests, you need to know which are safe and which aren’t. Any web service that’s exposed over an HTTP request is vulnerable to attacks, such as a replay attack.
What can a hacker do when he acquires the web service request together with valid input parameters? Attack manually over and over again or use automated techniques that repeatedly perform attacks. What kind of damage can these attacks cause? The server’s memory gets consumed. This tanks the server’s performance greatly.
This attack is even more dangerous when used in conjunction with a malicious code injection in the input parameter. This gives the hacker sensitive data in the response.
Cross-site scripting (also known as XSS) is a web security vulnerability that could allow an attacker to compromise the interaction between a user and a vulnerable API. This allows attackers to bypass same-origin policies that seek to isolate scripts running on different websites from each other.
Cross-site scripting vulnerabilities typically allow an attacker to impersonate a victim user, perform any actions the user is capable of, and gain access to user data. In the context of a SOAP API, a successful XSS attack would allow the attacker to perform user actions that result in API calls that are processed with the same privileges of the legitimate user.
Broken Access and Authorization
Access control enforces policies to prevent users from operating beyond their expected privileges. Common access control vulnerabilities in SOAP APIs include:
- Ability to modify URLs, internal application state or HTML pages, to bypass access control checks.
- Ability to change a primary key to another user’s record, allowing an attacker to view or edit another user’s account.
- Ability to escalate privileges, such as logging in as a regular user and receiving administrative privileges.
- Ability to manipulate or tamper with JSON Web Token (JWT) metadata, cookies, or hidden fields that affect user authorization.
- Incorrect Cross Origin Resource Sharing (CORS) configuration allowing unauthorized API access.
- Ability to access authenticated content or operations as unauthenticated users, or force retrieval of privileged content or administrative operations as a standard user.
- Ability to access APIs without sufficient control for POST, PUT and DELETE operations.
Denial of Service (DoS)
Denial of service (DoS) attacks on APIs flood the API endpoint with traffic, in order to disrupt service and deny access to legitimate users. DoS attacks can significantly degrade the quality of service experienced by legitimate users of the API, cause significant delays in response, and eventually result in downtime.
DoS attacks are not limited to disruption of service. An attacker could inject and execute arbitrary code into an API during a DoS attack, to access sensitive information or execute commands on the server.
SOAP Security Best Practices: Preventing SOAP Security Threats
What actions help protect SOAP APIs? Continue reading to find out!
Input parameters are the entry points that are exploited when a hacker wants to access layers of an application. Hackers can inject their malicious code into an API message. This malicious code then endangers your entire application.
Regex Protection is a good security technique. XML or JSON payload, URL Path, Header. These incoming requests need to be evaluated against regular expressions like EXECUTE, DELETE, and UPDATE. Rejecting any detected request that’s vulnerable is important.
Input HTTP Verb Validation deals with HTTP verbs/methods. These include DELETE, GET, POST, PUT, PATCH, HEAD, TRACE, and OPTIONS. All of them need restrictions. The approved verbs are allowed to function while the rest of the methods should only return a valid response code.
Then there’s Headers Validation. Many kinds of Security Headers exist. Content-Length, Accept, Content-Type. All of them need validation against API. It’s also important to always perform validation for obligatory headers. API-specific headers and Authorization for example. In the case of custom-defined headers, we need to make sure to validate proper formatting and value (X-Access-Token).
Validating incoming content-types is also important. How do you validate the Content-Type policy for PUT/POST/DELETE requests? IBy ensuring the values for the request and the Content-Type header are the same. If the API detects that value does not match type, it returns a Bad Request Response (400).
Lastly, you need to handle Unsupported Resources. Addressing this is easy, by only permitting allowed resources and blocking unknown resources.
All APIs need special configuration. Why? So that only approved IP domains or regions are allowed. Any requests that don’t meet the set conditions should get rejected.
There are many different approaches to managing resource access. The most common method is role-based access control. By default users have all permissions denied to ensure full level security. Afterwards administrators grant required privileges to appropriate roles. Several types of permission levels exist. They include:
- Never (Regardless of role, this function restricts the user completely, making them unable to perform any operation)
- Always (This access level allows the user to perform operations as they see fit no matter what role they have)
- Grant (A user can perform an operation unless an entity-level permission disallowed it)
- Entity (Users that obtained access via entity-level permissions can perform the operation)
Implement Authentication for SOAP APIs
Each security layer in the organization requires comprehensive authentication. Without it, the API is vulnerable, making the data vulnerable as well. For example, hackers that have a valid mobile number are able to steal sensitive data. That’s why we use OAuth/OpenID. They offer complex and potent authentication and authorization mechanisms. It’s recommended to authenticate the end-user and the application as well.
Usage of 2FA, OAuth, and Nonce tokens improve access control and can also help prevent replay attacks. A Nonce token combines a unique GUID and a timestamp. One token is valid for one request. That way any request is unique, making it free of vulnerabilities. Use signed URLs for providing access to media type resources.
Enable SAML Authentication
If you use SAML for SSO, it is essential to use SAML authentication. The SAML authentication model has two parts:
- An identity provider – produces all SAML assertions
- A service provider (SP) – a consumer of assertions. This could be, for example, G Suite, Office 365, or other SAML-supported cloud applications.
Most SAML assertions are signed with a PKI signature. This signature checks if the assertion is valid or not.
Any cloud application that’s being accessed needs an authentication service – one that acts as an identity provider (IdP) – to collect user credentials and return a response to the accessed cloud application. This response is what we call a SAML assertion. This assertion can contain a reject or accept response only. The user successfully logs into the app if the SAML assertion is confirmed to be valid.
Ensure URLs Never Contain API Keys
Any API needs standard authentication and authorization mechanisms. Yet there are cases where the API key gets sent as a part of URI (Uniform Resource identifier). This makes the key compromised as it’s shown as a plain text in your browser. Sending API keys via the GET method is also a problem. Why? Because they can be stored either in the system logs as cache or in the browser history. This makes them accessible to other users. You never want your API key to be part of URI and should prefer sending it as part of headers instead of sending it via GET.
Automating SOAP Security with Bright
In summary, SOAP APIs have many advantages. It’s a more secure protocol than REST, it supports automation, and it’s standardized to an incredible degree. Yet, the inherent use of SOAP APIs also brings more overhead to SecOps teams. We’ve listed common vulnerabilities and what you can do to prevent them. However, you can automatically apply SOAP security best practices with an automated security testing solution.
Most legacy Dynamic Application Security Testing (DAST) tools do not support API security testing. Those that have attempted to make the leap are unable to support SOAP API security testing, resulting in a continued reliance on expensive manual testing, carried out late in the process and often after the API is in production.
With Bright, you can test your SOAP, REST and indeed GraphQL APIs, as well as Websockets, either as a standalone scanner or integrated seamlessly across your DevOps and CI/CD pipelines. You can now start to detect, prioritise and fix issues early, before they hit production.
By simply uploading the OpenAPI (Swagger) or Postman collections into Bright, you can achieve a comprehensive security scan that will cover the OWASP API Top 10 vulnerabilities. This can be achieved for a full scan against the complate target or for scope defined incremental testing on each new build, feature or merge.
Additionally, Bright has unparalleled support for a range of different authentication mechanisms, including SAML, OIDC, OAuth and more, ensuring you have maximum coverage.
API security testing no longer needs to be an afterthought and another human bottleneck in your processes – start automating your security testing.