Enhancing Security Using Threat Protection and Mutual SSL in WSO2 API Manager Gateway
By Chamin Dias
- 18 Dec, 2018
The API-driven business model plays a major role in today’s world. Digitally transformed businesses have constantly reaped the benefits of exposing their services via APIs to the wider community with most of their revenue being generated by APIs.
Security is one of the major concerns for any enterprise IT application. This has the same importance for API management as well. In this context, service providers must make sure that only authorized parties have access to respective services. API security is important because unauthorized access to resources will negatively impact an organization's revenue.
Traditional token-based authentication and authorization can be found in any API management solution. Nowadays, it should go beyond that since the requirements are getting more complex. When exposing a backend through an API, we need to make sure that every aspect in the deployment is secure. In this context, preventing unauthorized use of APIs, protecting the backend from harmful (intentional or unintentional) requests, and maintaining trust between the API management solution and the backend are some of today’s “must have” functionality.
Importance of Enhancing Security at the Gateway Level
As mentioned in the introduction, we need to ensure that the services (i.e. the APIs) are only consumed by authorized users. However, this does not guarantee that these users are sending legitimate requests all the time.
In WSO2 API Manager, the API gateway is the component which acts as a proxy before sending requests to the actual backend (endpoint). Therefore, all requests that are coming from end users should go through the API gateway. It is true that we have secured WSO2 API Manager using OAuth2 based security, but there might be cases where we cannot "trust" the request coming from the end-user. Over time, some users might send requests that contain harmful content (intentionally or unintentionally), which might affect the backend.
In those kinds of scenarios, it is pivotal to have some kind of mechanism to prevent malicious requests. This way, we can ensure that the backends are safe with an additional “security” check. The system cannot be misused even by legitimate subscribers (who are sending requests with a valid token).
Figure 1: High-level picture of WSO2 API Manager deployment (with threat protection and mutual SSL)
Let us explore this a bit more.
According to figure 1, we can see that the request should come with a few attributes. Payload, query parameters, headers, and token are some such attributes. In the past, we would just validate the token against the API key manager. For more information on token generation and validation, read our documentation on API security.
However, if we observe the request carefully, we can notice the other important attributes such as payload and query parameters. What if the user sends a malicious payload with a valid token? It will harm the backend and cause problems. Therefore, we need a solid mechanism to add an extra validation layer for the requests.
This will be beneficial for both consumers and service providers. Service providers are ensured that the backends are protected from harmful requests. At the same time, consumers are assured that they are not in a position to “break” the system even by accident.
Securing Backends from Harmful Requests Using the API Gateway
We have carefully identified what might go wrong here and we have come up with a robust solution to address the aforementioned vulnerability.
Now we have regular expression threat protection, JSON threat protection, and XML threat protection for API gateway. Let us explore each of these separately.
Regular Expression Threat Protection for WSO2 API Gateway
As shown in figure 1, multiple elements of the request should be "scanned" before sending the request to the backend. Therefore, it is important to have a mechanism to validate the payload against a predefined rule set so that it ensures that the backend is safe from harmful requests. API providers and developers must foresee these kinds of attacks and take necessary prevention actions in advance.
WSO2 API Manager is capable of effectively facilitating this requirement. It can be done by using the regular expression threat protection feature. The main intention of this mechanism is to prevent SQL injection attacks. With this feature, WSO2 API Manager is capable of analyzing payloads (JSON or XML), query parameters, URI paths, and request headers. During the validation process, WSO2 API Manager scans the candidate values in the payload or query parameters and compares them with the pre-defined malicious patterns. If the request contains at least one malicious element, it will be blocked immediately. It will not pass the API gateway (to the backend). This way, people who are exposing services via APIs, are ensured that their backend systems are protected against attacks and malicious code injections.
API developers have the flexibility to edit the sequence through registry artifacts. At the same time, these policies can be attached as API sequences (possibly the in sequence). When we upload the threat protection policy as an in sequence, WSO2 API Manager will block the malicious requests at the API gateway level so that it won’t reach the backend.
JSON Threat Protection Using WSO2 API Gateway
This is useful to validate the request body of the JSON message and prevent harmful payloads from reaching the backend. The blocking conditions can be pre-configured and attached as a mediation sequence. With this, it is possible to define maximum values for the number of properties, length of the string, number of elements in an array, and the length of key and length of JSON in a JSON payload. However, there will be a slight performance overhead when using this.
XML Threat Protection Using WSO2 API Gateway
Without limiting to threat protection in regex and JSON payload, WSO2 API Manager offers the capability to protect backends from harmful XML payloads as well. This is similar to the JSON threat protector.
With this, it is possible to define maximum values for the depth of the XML request message, number of allowed elements in the XML request message, count of allowed attributes in the XML request message, length of each attribute value in characters, entity expansion limit of the XML request message, and number of child elements allowed in the XML request message. At the same time, this is capable of enabling and disabling the DTD payload in the XML properties to avoid attacks as well.
According to the above explanations, it can be observed that WSO2 API Gateway offers the full capability to prevent any payload based attacks by scanning the payloads in every aspect.
Securing the Connection Between the API Gateway and the Backend
In order to get the picture clearly, let us have a quick look at mutual SSL.
Figure 2: Basic overview of mutual SSL
Figure 2 represents the flow of mutual SSL. First, the user navigates to the server. Next, the server sends the SSL certificate to the client. Then, the client verifies the certificate sent by the server. After that validation, the client sends his certificate to the server for validation. Finally, the connection will be established (if all validations are OK).
Accordingly, it is clear that in mutual SSL
- The client must verify the identity of the server
- The server must validate the identity of the client
This will lead to a system that has very tight security and avoids any requests made to the client to provide the username/password, as long as the server is aware of the certificates that belong to the client. At the same time, this mechanism builds "two-way" trust between the server and the client.
When it comes to mutual SSL in the gateway, it is mandatory to have the public key of the backend service in the truststore (API Manager truststore). Moreover, it requires the backend service to have the public key of WSO2 API Manager in the truststore.
In this case, WSO2 API Manager’s gateway becomes the "client" while the backend is acting as the "server".
What are the advantages of having this implemented in a production environment using WSO2 API Manager? Let us have a look.
First of all, this makes sure that the API gateway only communicates with trusted backend servers and that all responses are coming from a trusted source. API consumers are ensured that they will have the response from the intended backend. At the same time, this prevents someone from sending a response disguised as the actual backend (prevents sending user information or requests to a third party or bogus server).
The second advantage is, the private information (i.e. the private key) is never sent to the server. The client or the gateway doesn't let its secret out at all during the authentication.
Lastly, the server can still authenticate that client (with no username or password) by using the certificate, provided it trusts the CA that issued the certificate.
Official documentation of WSO2 API Manager has a comprehensive page describing how to export the certificates, how to configure WSO2 API Manager to enable dynamic SSL profiles and how to test mutual SSL between the API gateway and the backend.
Accordingly, we can see that WSO2 API Manager's gateway is capable of ensuring the security of both the backend and the end users. This makes WSO2 API Manager a production friendly API management solution.
In this article, we focused on enhancing the security of the API management deployment using WSO2 API Manager’s gateway. Since WSO2 API Manager is a complete, enterprise-ready solution for managing APIs across the complete API lifecycle, organizations can use it to deploy and expose APIs while ensuring a secure environment for API consumption, even at the gateway level.
Protecting backends (services) is a must in any digitally transformed business because exposing backend services as APIs is a key revenue generation model of today's world. At the same time, it is mandatory to ensure the security between all communication links in the deployment. By deploying WSO2 API Manager, we can ensure that both API consumers and service providers (backends) are protected from all kinds of threats.