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.
What are SOAP APIs
Why are APIs important? They serve as a bridge between web services and applications that allow them to exchange data in a specific way. APIs are an important part of today’s digital age. APIs enable systems to exchange data in a structured manner. The two most common API formats are the REST pattern and the SOAP protocol. We will explain the functions of SOAP APIs, the difference between SOAP and REST APIs, and explain how users can improve their SOAP API security!
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. A good part of web data exchange happens via REST exchange. But, SOAP has its advantages. It’s more secure, incredibly standardized, and can even support automation.
What are the two most common data formats? XML and JSON. Extensible Markup Language (XML) is a text format that establishes a special set of rules. These rules structure messages as machine-readable and human-readable records. SOAP works with XML only as it needs XML exchange between systems when requests and response messages get sent within web applications. SOAP APIs then send XML-coded messages back when a request arrives.
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:
The core element of all messages. Its tags start and end messages, enveloping it in a sense.
The header is an optimal element. It defines extra requirements like authentication.
Contains the data needed to process the request or the appropriate response to the user.
Another optional element. Showcases data about errors that can appear throughout API requests and responses.
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 are the thing that augments the main protocol. They specify how you do particular things. WS- is the mark of these protocols and WS-Security is an example. These standard protocols cover SOAP use facets and areas (Metadata, Security, Transactions, Messaging). Why are these protocols useful? Because you can pick which one to use. We call this SOAP extensibility. If you need extraordinary protection when exchanging sensitive information in enterprise architecture you can use any protocol that is ACID-compliant. WS-Atomic Transactions or SQLTransaction) Atomicity, Consistency, Isolation, Durability. That’s what ACID stands for.
The all-or-none approach. Multiple connected transactions have to work as one unit or they won’t work at all.
When a part of a transaction fails the entire system backs up to its initial state.
Each transaction is independent.
All completed transactions remain even if the system fails.
Another important SOAP API feature is the use of WSDL documents. WSDL documents are XML descriptions of a web service that SOAP APIs use all the time 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.
The difference between SOAP and REST APIs
Despite what many think, REST and SOAP aren’t similar in nature. For starters, 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.
What’s the main difference between these two? 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 also doesn’t need a service definition in place to provide you with a web service.
Top 7 SOAP API vulnerabilities and how to prevent them
We have now covered the basics. Now let’s talk about the 7 most common vulnerabilities and how to prevent them. SQL/Command/XML Injections, SOAP Action Spoofing, Cross-Site Scripting, Cross-Site Forgery, and Broken Access and Authorization related vulnerabilities are all common vulnerabilities.
What actions help protect SOAP APIs? Continue reading to find out!
How to prevent injection-based attacks like SQL Injection or Cross-Site Scripting? Use input validation. 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? In a way that ensures 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).
Last, you need to handle Unsupported Resources. Addressing this is easy, only permit allowed resources and block 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 permission 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)
APIs that lack Authentication
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.
URLs that contain 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.
The biggest problem with APIs is that they’re open to the public. Why is this an issue you may ask? Well, 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, a replay attack for example. 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. How does one prevent these attacks? Usage of 2FA, OAuth, and Nonce tokens. 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.
XAML Injection attacks are a enabled 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? He can execute his malicious code. However, Microsoft enforces a rule in their IDEs. This rule analyzes the whole codebase to check for such occurrences. But it can be configured differently if the user wants to.
The rule attempts to find any input from an HTTP request, one that reaches a System.Windows:Markup.XamlReader Load method. Yet, the problem lies in the fact that this rule can’t track data across assemblies. That means that this rule won’t make any warnings if a single assembly reads the HTTP request input and then proceeds to pass it some other assembly that loads XAML. Just keep in mind that there is a configuration limit that defines how deep this rule analyzes data flows across method calls. The best prevention practice against this is manually validating and sanitizing the received input.
The oldest standard, SAML originated way back in 2001. Security Assertion Markup Language (SAML for short) is an open standard that provides authorization and authentication services. This is an XML-based open standard. It’s used for exchanging authentication and authorization data between users. So, what does it do? It lets identity providers pass authorization credentials to a service provider (Salesforce SAML SSO).
Why is SAML useful? Because it’s easier to manage one login per user. Managing separate logins for each email, application, Active Directory, etc. takes up a lot of time and effort.
How is SAML vulnerable? Hackers found a way to modify SAML body content. They do it without invalidating the cryptographic signature though. 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. That’s how they obtain an administrator account for example.
What prevention guidelines should you follow? Use SAML authentication for starters. It enables identity information sharing between IDPs and web applications.
Now you may ask, what makes the SAML-based authentication model? Two parts:
- an identity provider (the producer of all SAML assertions)
- a service provider (called an SP that is a consumer of assertions like G Suite, Office 365 and 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(also called an IdP). Why? 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.
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 each common vulnerability and what you can do to prevent them. We hope you enjoyed this blog and that you’ve learned something new and useful that will help you understand SOAP API security better!