You have got the basic concepts of REST API and how it is implemented. Now let’s get started with the main motto of this post i.e.How to perform VAPT of a REST API web service and what are different issues we should be looking.
Finally, the Guide!
REST API VAPT is somewhat similar to web application VAPT since we need to look for some standard vulnerabilities that we look for the web application such as SQL Injection, Access Control, XSS, CSRF, etc. Apart from these standard vulnerabilities, we need to look for API specific vulnerabilities also.
Enumeration
Before attacking any web service it is necessary to know from where you can start attacking. This can be tricky, finding attack surface for a web application is easy as we get GUI to examine different form fields, URLS, etc. But for API we only get API end point. In this stage we need to gather as much information as we can about the API’s endpoints, messages, parameters and behavior and technologies implemented. Following are some helpful points to gather information about the API end points.
a) If client provides API programming documentation or configuration files, analyse it thoroughly check how user authentication process is implemented, check URL style used, check what are different standard HTTP headers and non-standard HTTP headers are required to interact with the API service and analyse the error codes and description to get clear idea about the valid range of values an API end point is accepting, how user authentication and authorisation is handled by web service.
b) If the client does not provide configuration files, meta-data or programming guide, then try to record the interaction between API end point and existing API client by setting up local recording proxy. Analyze the recorded interaction and gather information about API end point such as
– Non-standard HTTP headers used.
– Analyze URL pattern and look for sign of variables such as numeric value, standard template (date), object names (username, hotelname, flight_id, etc). URLs ending without file-extension can be a parameter
– Check for a structured pattern in HTTP request body in the form of JSON, XML, YAML, etc.
– Check for the cookie, authorisation to get an idea about the authentication/authorization is handled.
Rate Limit Implementation
Rate Limit is defined as a number of requests allowed per time window per user access token. For example, if rate limit is 20 means the application will allow 20 requests per time window by a client application or user.
– Check rate limit for anonymous and authenticated user.
– Check rate limit for different HTTP methods, it may vary.
– Check whether consumer of API is blocked temporarily for too many error codes return (HTTP response code – 401,404,500)
– Check for the presence of HTTP headers related to rate limit such as
– x-rate-limit-limit: Maximum rate limit allowed for an API end point
– x-rate-limit-remaining: Number of request remaining for the time window
– x-rate-limit-reset: Remaining time before window gets reset.
Some variations for above headers are
– X-RateLimit-UserLimit
– X-RateLimit-UserRemaining
– X-RateLimit-UserReset
– X-RateLimit-ClientLimit
– X-RateLimit-ClientRemaining
Information Disclosure
Check for sensitive information disclosure such as server information, development platform information, hosting environment information, etc.
– Check for HTTP headers Server for web server information and X-Powered-By header for development platform information.
– Check cookie name to identify the technology used to implement web services such as PHPSESSIONID, JSESSION, ASP.NET_SessionId/ASPSESSIONID, etc.
– Try to get stack trace information by submitting invalid values. For example, submit alphabetical values where numerical values are expected.
– Check caching headers and determine whether sensitive information is being cached or not.
We can plan a well-targeted attack against the hosting environment by using information obtained by above methods.
Access Control
We need to validate that security is correctly enforced for objects depending on who should have and who should not have access to the object.
– Assess the restriction implemented for different HTTP methods. For example, it is fine for an anonymous user to GET a resource but it is not okay to allow the anonymous user to delete a resource.
– Check for identifier parameter such as bill_id, order_id, etc which uniquely identify a resource on the server. Iterate sequentially over this parameter and check whether you are able to access the resource which should not meant to be accessible.
– Check for non-standard HTTP methods, cookie or URL parameter used to signify the role of the user such as UserType, IsAdmin, etc.
– If HTTP Authorization header is used, try submitting a request without it and check the response whether the application is rejecting the request or not.
SQL Injection
Check for SQL injection vulnerability in the web services.
– Identify parameters which are used for querying database. Look for these parameters in the request body, URL, HTTP headers, etc.
– Try different kinds of normal and encoded SQL injection attack vectors.
Cross Site Request Forgery
Yes! RESTful APIs are also vulnerable to CSRF attack as web application are. For clear understanding CSRF vulnerability please refer this <a href=”https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)”>link</a>
– Check for the presence of custom HTTP headers related to CSRF such as X-CSRF, CSRF-Token, etc. Try submitting POST, PUT, PATCH and DELETE request without these headers and check how web service respond.
– Check whether token generated after authentication used in HTTP authorization header for authentication purpose.
– Check implementation of CSRF validation is based on user-controlled entity such as values in HTTP header, URL parameters, etc.
Authentication
We already figured out how the web service is authenticating the user whether it is using session based authentication or token based authentication.
By reading “session based authentication” if you are wondering that web service is defying REST constraint of stateless, then before moving ahead let me explain this.
The REST constraint stateless says that there should be no server-side session for storing the states between requests. But session based authentication means that session is used for storing the logged-in user context not the states between the requests.
If web service is using session based authentication check for following
– Are session tokens are reused?
– Are generated tokens are sequential or is there a pattern? Is it possible to deduce the next session token value?
– Do session tokens timeout correctly?
If web service is using token based authentication check for following
– Are tokens are transmitted over unencrypted channel?
– Are tokens are transmitted as a URL parameter?
Input Validation
– Check how API end point is handling abnormal input.
– Check content-type, how the application is responding to a request containing not allowed content-types. Look for Content-type header manipulation check ACCEPT HTTP header.
Output Validation
Check whether web service is performing server side encoding of the data controlled by the user. For example, check whether the application is performing server side encoding of an HTML/JavaScript input provided by the user to avoid XSS. If the server is not performing the server side encoding of user controlled data then there is a possibility of XSS vulnerability since it will be totally dependent on how client application is handling the response from the server.
Cryptography
Check for the data in transit whether it is properly encrypted. For ensuring the proper encryption is implemented check for following
– Check for a self-signed certificate.
– SSL pinning implemented at server side.
Before wrapping up, I would like to share some tools used for RESTful API VAPT.
Conclusion
RESTful API VAPT is mostly same as web application VAPT, one should look for SQL injection, Access Control, CSRF, Server side validation flaws and RESTful API specific vulnerabilities such as rate limiting, input validation, output validation, token based authentication issue.
References
http://www.restapitutorial.com/
https://en.wikipedia.org/wiki/Representational_state_transfer
https://www.owasp.org/index.php/REST_Assessment_Cheat_Sheet
https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
