Blog

We specialize in Products, Application and Infrastructure security assessments and deep technical security training.

...
...

Beginner’s Guide to RESTful API VAPT – Part 1

by Siddharth Bezalwar
07/07/2017

Beginner’s Guide to RESTful API VAPT – Part 1


With more and more web applications are developed on top of the web services (RESTful API) many web application penetration tester are wondering exactly how to test these web services and what to actually look for. To help explain how to perform VAPT of REST API, let’s take a quick look at the basics of RESTful API.

What is a RESTful API?

Before understanding RESTful API let’s take a look at what the term REST actually mean.

REST

REST stands for REpresentational State Transfer which is a style of web architecture which describes six constraints.

Uniform Interface

Uniform interface simplifies and decouples the architecture, which enables to each part to develop independently. There are four basic principles for designing uniform interface.

  1. Resource Based – Individual resources are identified in requests using URIs as resource identifiers.
  2. Resource Manipulations Through Representations – A client with a representation of a resource along with its metadata can modify or delete the resource on the server depending on the permissions.
  3. Self-descriptive Messages – Each message contains information to describe how to process the message.
  4. Hypermedia as the Engine of Application State (HATEOAS) – Clients provide state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services provide state to clients via body content, response codes, and response headers.

Stateless

– No client context should be stored on the server between requests. This means required the state to handle the request is provided within the request as a part of the URI, query-string parameters, request body, or HTTP header.

Cacheable

Responses must implicitly or explicitly specify themselves as cacheable, or not.

Client/Server

Client and server must be separated via a uniform interface.

Layered

A client cannot tell whether it is connected directly to the end server, or to an intermediary along the way.

Code on Demand

Servers are able to temporarily customize the functionality of a client by transferring logic to it that it can execute by using JavaScript, JAVA applets, etc.

Complying with these constraints is referred as RESTful. After understanding REST let’s take a look at RESTful Web Services API.

RESTful Web Services (API)

“Representational state transfer (REST) or RESTful web services is a way of providing interoperability between computer systems on the Internet. REST-compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations” – Wikipedia

Web services are implemented using HTTP and the principles of REST. It is a collection of resources with four aspects – base URI of the web service, content type supported by web service, operations supported by web service and API must be hypertext driven.

Aspects of RESTful API

A RESTful API client does not need to know details about the structure of API. It is server’s responsibility to provide necessary information the client needs to interact with the service. The client can interact with APIs with the HTTP methods. Let’s look at different HTTP methods used by the client to interact with APIs.

HTTP Methods for RESTful API

HTTP MethodCollectionSingle Entity
GETRetrieve all resources
Request URL: https://mysite.com/api/users
Retrieve a single specific resource
Request URL: https://mysite.com/api/users/1
HEADRetrieve all resources (headers only)Retrieve a single specific resource (headers only)
POSTCreate a new resource in a collection
Request URL:https://mysite.com/api/users
PUTUpdate/Replace a resource
Request URL: https://mysite.com/api/users/1
PATCHUpdate/Modify a resource
Request URL: https://mysite.com/api/users/1
DELETEDelete a resource
Request URL:https://mysite.com/api/users/1

HTTP response codes are used to indicate the status of an operation requested by client.

Response Status – HTTP Response Codes

Following are primary or most-commonly-used HTTP response code
200 OK
Indicates the success of requested operation.
201 CREATED
Indicates successful creation of entity via either POST or PUT.
204 NO CONTENT
Indicates success but nothing is in the response body, generally used for DELETE and PUT operations.
400 BAD REQUEST
Indicates general error occurred at the server while serving request which resulted in an invalid state. Reasons for such errors are validation error, missing required parameters, etc.
401 UNAUTHORIZED
Indicates error code response for missing or invalid authentication token.
403 FORBIDDEN
Indicates error code for when the user is not authorized to perform the operation or the resource is unavailable for some reason (e.g. time constraints, etc.).
404 NOT FOUND
Indicates when the requested resource is not found, whether it doesn’t exist or if there was a 401 or 403 that, for security reasons, the service wants to mask.
405 METHOD NOT ALLOWED
Indicates that the requested URL exists, but the requested HTTP method is not applicable.
409 CONFLICT
Indicates a resource conflict occurred. For example, trying to create two users with same information.
500 INTERNAL SERVER ERROR
Indicates the error which cannot be addressed from the consumer end.
To get a clear picture here is sample request to API end point.

Request to API end point

And it’s response.

 

Response from API end point

Continue to VAPT

Token Stealing with Windows Update KB4054518

5-July-2019
Blogger
Siddhant Badhe

Introduction of Tcache bins in Heap management

13/03/2019
Blogger
Gaurav Nayak

6 Must have tools for your iOS pentesting toolkit

22/02/2019
Blogger
Akansha Kesharwani

Latest news See all news

23-Oct-2013
Luxembourg

We will be delivering a workshop on ARM Android Xploitation Primer at Hack.lu

22-May-2014
Moscow, Russia

We will be delivering a workshop on ARM Exploitation at PHDays

22-Sep-2014
Ghent, Belgium

We will be delivering 3 days training on ARM Android Exploitation at Brucon