An API is called as Application Programming Interface which is used for communication. An API acts as a middle man who delivers your request to the provider and then delivers response to the requester. Let’s consider an example: A receptionist in an office gets the query from a person or guest about accommodation and then informs the manager about it. The manager checks for rooms and intimates the receptionist about the availability. Then the receptionist answers the guest with the availability.
Web Services use a collection of protocols and standards to exchange data’s between client and server over network. A web service either uses XML, to tag the data. Some commonly used Web services are HTTP, SOAP, WSDL, and UDDI. Let’s see what SOAP and REST API provides and how to secure them:
SOAP API was designed to exchange data’s between software’s that are built on different programming languages. SOAP’s built-in WS-Security standard uses XML Encryption, XML Signature, and SAML tokens to deal with transactional messaging security considerations.
Some Common API Vulnerabilities
API without Authentication
Keys in URL
Some Common API Vulnerabilities:
- SQL Injection
- Command Injection
- XML Injection
- SOAP Action Spoofing
- Cross-Site Scripting
- Cross-Site Request Forgery
- Broken Access and Authorization related Vulnerabilities.
Common Techniques to Secure SOAP API and REST API:
1. Input validation
A proper input validation is a crucial security measure to avoid injection based attacks such as Cross-Site Scripting, CSRF, SQL injection etc. An input parameter has always been the entry point to penetrate into the layers. For example, a malicious code can be injected in the API message, such as OS command injection which can compromise the entire web application.
Regex Protection: The incoming requests such as URL Path, Header, XML or JSON payload must be evaluated against the regular expressions such as DELETE, UPDATE and EXECUTE. Vulnerable request should be rejected.
Input HTTP Verb Validation:
HTTP Verbs such as GET, POST, HEAD, TRACE, OPTIONS, DELETE, PUT and PATCH should be restricted properly. Only allowed verbs should work and rest of the methods should return a proper response code.
Security Headers such as Content-Type, Accept, Content-Length should be validated against API. Also, validation against mandatory headers like Authorization and API-specific headers should be performed.
Validate incoming content-types:
The Content-Type policy for PUT/POST/DELETE requests should be validated such that the incoming request and Content-Type header value should be same. The API should reject the content with a 404 request when the header is gone missing.
Handle Unsupported Resource:
It must properly restrict only the allowable resources and block the other unknown resources.
2. Access Control:
API gateway should be configured in such a way that it should allow specific IP domains or regions. Requests which does not meet these conditions should be rejected.
When setting up role access, if an access type for a specific operation is not specified, members of the role do not receive any access privileges for that operation. This has the effect of implicitly disallowing the operation, unless another role grants more permissive privileges.
Never: This function will not let the user to perform any operation, regardless of the role they possess.
Always: In this access level, the user will be able to perform operations, regardless of the role they have.
Grant: Users will be able to perform the operation, unless explicitly disallowed by entity-level permissions
Entity: Only those users who are granted access through entity-level permissions will be able to perform the operation.
Implement the above access type to all users. By implementing these rules, Broken Access Control can be avoided.
3. API without Authentication:
An API without proper authentication can risk the organization’s databases which shows that the API’s design is an utter failure. Even if TLS was implemented, it can cause problems. If the attacker has the valid mobile number, he can obtain sensitive data’s such as device details and other personal data’s. Strong authentication and authorization mechanisms like OAuth/OpenID connect should be implemented. Authenticate both end user and application, if possible.
4. Keys in URL:
As said before, an API should have proper authentication and authorization mechanism. But sometimes, the API key is sent as a part of URI (Uniform Resource identifier) which can lead to the key being compromised, as it appears as plain text in browser. API key sent via GET method can be stored in the browser history or in the system logs as cache, which leads to other user to access it. It is recommended to use HTTP POST Method.
5. Replay attacks
API’s that are kept open to public face the challenge of sorting out whether the incoming requests are legitimate or not. When a web service is exposed over an HTTP request, it can be vulnerable to many attacks. One such among those is the replay attack where an attacker gets hold of the web service request along with the valid input parameters and performs repeated hits, either manually or in an automated fashion. Some impacts of this attack is that is consumes the server’s memory which gradually affects the servers performance. The attack can inject some malicious codes in the input parameter and might get some confidential data in the response.
1. A Nounce token should be used to avoid the reply attacks. A Nounce token is a combination of unique GUID and a timestamp. The Nounce token works on the principle of one token valid for one request. The GUID (Globally Unique Identifier) is a 128-bit integer number used to identify resources by the developers. With help of GUID value and timestamp, the request will be always unique.
2. Enable 2FA and 0Auth.
In order to develop a secure API, one should properly implement authorization and authentication measures. This is crucial because data must be safe and secure. Last but not the least, one should consider API SECURITY as their nucleus.