With web applications and microservices being the norm now, Web Application Programming Interface (API) has never been more significant, more specifically the REST API. As more and more companies move towards using multiple micro-services to build their applications, which interact with multiple third party data sources, building a secure API is essential. Even if you build a secure application, an insecure API can be the broken link that makes your security posture inadequate.For those of you who don’t know what a REST API is, here is a quick 101.
REST stands for ‘Representational State Transfer’, and is an architectural method for creating an API. It uses HTTP as its underlying communication method, which is the most common method used by web applications to share, add, edit, and delete resources. The verb that is sent with the request informs the API what to do with the resource. For example, a GET request gets data about an entity, POST requests create a new entity. Following are two example of how a REST API shares resources:Example One:
Image 1: Image shows a HTTP request API call. The highlighted part is the parameters of request
Example Two:
Image 2: This image shows a response received following a REST API request. In the previous example, we requested to create a work-space. This image shows the response to that it was created
Now that you know what an REST API is, here are three major aspects of API that you need to keep in mind while creating a secure API.
Before any kind of resource is shared through an API, the requester needs to have the proper authorization. But, when the first API call is made, the app is not sure its an authenticated resource request. There are two ways to authenticate: Basic Authentication and API Key based authentication.
The easiest way to authenticate in a REST API is to use HTTP basic authentication transmitted over a SSLv3/TLS. We use a special HTTP header where we add 'username:password' encoded in base64.
GET / HTTP/1.1
Host: example.org
Authorization: Basic Zm9vOmJhcg==
The credentials are encoded not encrypted so by using the HTTP basic authentication we can retrieve the username and password. One of the disadvantages of basic authentication is that we need to send the password over each request. Also, make sure the client - server connection is using the most recent TLS protocol.
When there is an API key or a token present in a request, the authorization is provided to access the resource without any prior authentication. An API key is simply a unique token with decent entropy that only the application on both client and server sides know. When creating an API key, the following controls must be taken into account to make sure that the API is secure.
It is a very common practice to configure the REST API with asterisks (*) to allow access to all requests, because this means session validation is easier. This is a major security flaw, because this by itself isn’t enough to limit activity to legitimate users only. A good practice for this is to whitelist only the necessary HTTP headers such as GET, POST, PUT and DELETE. Restrict from using other HTTP methods, with generic error messages when accessed. And then enable proper session validation. If the session value or the token is not validated upon every state changing request, it makes it vulnerable to privilege escalation, for instance.
Here is an example where we were able to edit session usage, and compromise the host data.
Image 3: The image shows that the user order id is “3169”, which is the current session token
Image 4: This image shows that the victim user has an order with “3200”
Image 5: In this image, the malicious user intercepted a request using an intercepting tool and the request_id parameter is passed into the request
Image 6: This image shows that the malicious user intercepted the victim’s request and changed the value of the request_id parameter. Then, forwarded the request to DELETE the order. This attack was only possible because the DELETE HTTP method was improperly configured on the resource
In a REST API, it is very critical to validate user inputs on all endpoints like you would do on any parameters. By default, people don’t think about this when creating an API, which makes the application vulnerable. In modern RESTful API web services such as “Jersey”, the validation constraints are automatically enforced at the request in real-time which helps minimize the possibility of XSS (Cross Site Scripting), SQL Injection, XXE attacks.
a) To protect against XSS attacks, make sure to :
b) To protect against SQL attacks, make sure that you:
c) To protect against XXE (XML external entity attack) attacks, make sure that you:
Pretty interesting, right? Click here to know more about DevSecOps.
