Demystifying RESTful Web Services (In) Securities

1.  REST Introduction

The usage of Twitter, Amazon, Google Maps, e-bay and many other applications has become extensive. The ease of development and access of such applications is due to the implementation of a web service which is simple yet supports complex functionalities; called Representational State Transfer (REST).

Before starting with REST lets understand what a Web service is. A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. In layman terms they are the calls made by the application to a service present on the web to perform the specified actions.

REST was introduced and defined in 2000 by Roy Fielding. Rest is a stateless architecture which uses a client-server, cacheable communication protocol HTTP. It is an Application Programming Interface (API) which performs all the functions using HTTP methods.

Features of RESTful Web Services:

  1. Client-server module:

REST has uniform interface with different separates clients from servers. Servers and clients may be replaced and developed independently, as long as the interface between them is not altered.

  1. Stateless:

The RESTful Web Service does not maintain state; the client–server communication is further constrained by no client context being stored on the server between requests. The server does not store any client specific data. Each request from the client contains all of the information necessary to service the request, and any session state is held in the client.

  1. Cacheable:

REST web services allow the clients to cache the responses. However, responses must be implicitly or explicitly defined themselves as cacheable, or not. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.

  1. Layered System:

A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. However, proper security policies have to be enforced in order to prevent information leakage.

  1. Code-on-Demand:

Servers can temporarily extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript

RESTful web services are the API calls which work like any other HTTP requests. In HTTP to access any page, a request is made to the corresponding URL. Similarly in REST, each resource will be assigned with a distinct URI(Uniform Resource Identifier). REST performs the following actions using the HTTP methods give below:

  • Action -> HTTP method
  • Create -> PUT
  • Read -> GET
  • Update -> POST
  • Delete -> DELETE

Advantages of RESTful Web services:

REST is stateless, simple, lightweight and fast and works on the standard HTTP protocol.

  • It uses a standardized XML messaging system
  • It is time-conserving
  • It supports custom coding.
  • It works on any operating system and programming language.

The resources are not restricted to a specific extension and it can be accessed in a various formats such as HTML, XML, plain text, PDF, JPEG, JSON, and others

Difference between Simple Object access Protocol (SOAP) and REST

Sl No REST SOAP
1. REST is an architectural style that is defined for web service communication SOAP is protocol used in web services communication
2. Every REST resource has a specific URI SOAP uses interfaces and named operations to expose resources
3. REST is stateless SOAP maintains the state of the user
4. REST is a client-server module and not suited for distributed computing environment. SOAP has a standardized mechanism where the data is managed at a Service registry. The service provider and consumer binds with each other using the service registry and Uniform Description, discovery and Integration (UDDI)
5. Message communication protocol can be either XML,JSON or other valid mime types. Message communication protocol is XML.
No WSDL (Web Services Description Language)  interface definition SOAP has a well-defined mechanism for describing the interface.
7. The Transport protocol is HTTP. SOAP works with HTTP, SMTP, JMS
8. REST is lightweight and easy to design. SOAP is bulky and complex
9. REST provides caching of resources. SOAP does not support caching.
Best suited for mobile applications and other simple modules. Supports complex applications like online banking.

 

2.  Deploying a simple RESTful web service

RESTful web service can be deployed using any language and it does not require a WSDL. I have used the Recess Framework to build the Restful web service. For the deployment of RESTful web service, refer the Appendix section.

3.  Security issues associated with REST

As the overall design and structure of the REST is similar to any other web application, it inherits the majority of the security issues associated with the Web Applications.

The following are the key vulnerabilities that are applicable for REST:

Issue #1 Authentication of REST API
Description Check for the authentication mechanism used in connecting to the server. The authentication mechanism involves sharing the access tokens that is generated by the authentication server. These tokens grant access to the third party application that grants permission to the user’s resources.
Impact As the application authenticates the user with the tokens and authorisation grant, the authentication mechanism should be strong enough to protect the user’s resources. If the web service uses basic authentication and over an unencrypted channel like HTTP then an attacker can easily get hold of the credentials and the auth token.
Recommendation Always use a fool-proof mechanism to authenticate the user and the web service. The following authentication mechanism can be used for REST:

  • OAuth2
  • HMAC authentication
References https://developers.google.com/youtube/v3/guides/authenticationhttp://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/http://devcenter.kinvey.com/rest/guides/security

 

Issue #2 Session tokens and authentication tokens are exposed
Description The authentication and session tokens are the only means to identify the user. So these tokens should be protected during the transit.
Impact If the tokens are not implemented securely, then an attacker can get hold of these tokens and access the account on behalf of the victim.
Recommendation The following best practices have to be implemented to protect the tokens in transit:

  • The tokens should be custom generated, random and time limited.
  • The tokens should be sent over an encrypted channel.
  • The tokens should not be replayable.
  • The auth tokens should not be sent in the URL but it should be a part of the request header.
  • The session tokens used should be invalidated and all the cookie attributes like Secure, HTTPOnly should be set.
References https://developers.google.com/youtube/v3/guides/authenticationhttp://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests

 

Issue #3 Privilege Escalation
Description The resources intended to the privileged users should be protected. These resources may be for performing some sensitive actions link approval or granting permission on a record for other users. These API resources (URIs) should be restricted to only those administrator users who are required to perform the respective actions.
Impact If the resources are not restricted then an attacker accesses the URIs and performs actions posing as administrator.
Recommendation The privileged actions in the application should be protected and the users who can have access on these resources should be restricted.
This can be done by including a session key or an API token in the request for such actions.
These tokens should be sent in the header (like a cookie parameter) or in the body of the request.
References https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OWASP-AZ-003)

 

Issue #4 Insecure permissions on the resources
Description The HTTP methods allowed to a particular URI will allow the user to perform the corresponding operation. These methods can be PUT, POST, DELETE or GET.
Impact If a normal user who should have access to only fetch or view the information on the website, has been allowed with all the CRUD operations, then he may try to add, edit or delete resources.
Even though the mapping of the resources and data to the user role is correct, an adversary can still perform malicious activities as he/she is not restricted to the request methods.
Recommendation The request methods allowed to the user should be whitelisted based on the user levels. This filtering has to be done purely based on the type of application and the functions in the application.
References https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18

 

Issue #5 Parameter Manipulation
Description The REST API performs the actions requested by the user as specified by the user input. By understanding the pattern of the request and the parameters in the request, an unintended user may try to access data of other users without authorisation.
Impact An attacker posing as the victim performs actions on behalf of the victim.
Recommendation The privileges assigned to the user should be mapped to his role and any request to access others records or data should be responded with a generic error like 404 not found.
References http://www.cgisecurity.com/owasp/html/ch11s04.html

 

Issue #6 Cross-Site Request Forgery
Description Each user has a set of sensitive actions in the application. These actions may be considered as the actions that are available for all the users. This may be for a simple action of editing the profile details. An attacker can send a URL or a crafted page that contains the request to change the profile details and a victim who is logged in to the application and lure the victim to access them.
Impact An attacker entices the victim to send the request. The request is sent by the victim and uses the victim’s active session or auth token and triggers the intended action without the knowledge of the victim. Thus the application will not be able to differentiate if the request was actually legitimate.
Recommendation Implement anti-CSRF tokens for all the sensitive actions in the application.
References https://www.owasp.org/index.php/Cross_Site_Scripting_Flaw

 

Issue #7 Cross-Site Scripting
Description When the input entered by the users is accepted by the application and gets reflected in the response as is, then it is possible to inject javascripts as the input which gets executed in the user’s browser.
Impact An attacker will inject malicious scripts in the application and sends it to a victim to click that link there by stealing the cookies of the victim or performing other malicious activities.
Recommendation Implement strong input validation and Output sanitization. Also the user should all the input fields should be defined with set of allowed characters and reject any special character that is not present in the whitelist.
References

 

Issue #8 Parameter Pollution
Description HTTP Parameter Pollution (HPP) is a Web attack evasion technique based on splitting an attack vector between multiple instances of a parameter with the same name. In particular, some environments process such requests by concatenating the values taken from all instances of a parameter name within the request.
Impact This behaviour is abused by the attacker in order to bypass pattern-based security mechanisms. An attacker can craft a HTTP request in order to manipulate or retrieve hidden information.
Recommendation Implement an extensive and proper input validation. Moreover, awareness about the fact that clients/users can provide more than one parameter should be raised and multiple occurrences of the query string parameters should be rejected.
References http://www.slideshare.net/embyte/http-parameter-pollution-vulnerabilities-in-web-applications-black-hat-eu-2011https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)

 

Issue #9 SQL Injection
Description SQL injection is a vulnerability that allows an attacker to alter backend SQL statements as it takes the user input. An SQL injection occurs when web applications accept user input that is directly placed into a SQL statement and doesn’t properly filter out dangerous characters.
Impact An adversary can try to gain sensitive information from the database and shutdown the database if the application accepts dynamic queries.
Recommendation The application should use parameterized queries and the input should be validated. Also the database should have an understanding of the type of values that it accepts.
References http://www.w3schools.com/sql/sql_injection.asphttps://www.owasp.org/index.php/SQL_Injection

 

Issue #10 Cacheable HTTP responses
Description The RESTful API responses are cacheable and also REST uses a layered structure which includes a number of intermediate proxies. So if the responses are allowed to be cached, then a copy of this page will be present in all the intermediate proxies.
Impact An attacker who gains access to the user’s system or the intermediate proxy can view the post-authenticated cached pages of the user.
Recommendation Set the following cache control attributes in the response header:
No-cache
No-Store
Revalidate
References http://condor.depaul.edu/dmumaugh/readings/handouts/SE435/HTTP/node24.html

 

Issue #11 XML related attacks
Description If the application uses XML for representing the data, then due to the poor parsing technique and the fact that the XML accepts special characters, it may be vulnerable to the following issues:
XML Injection
XXE Attack (External Entity Injection)
Xpath Injection
XML Bomb
Impact
  • An attacker may gain access to sensitive files on the server including /etc/passwds.
  • An attacker injects and executes malicious scripts on the server.
  • An attacker retrieves information from the database that he is not authorised.
  • An attacker performs denial-of-service attacks on the server.
Recommendation
  • Perform strong input validation.
  • Use parameterized xpath interface and precompiled XPath queries.
  • XML processor should be configured to use a local static DTD and any declared DTD included in the XML document should be disallowed.
References

4.  Testing Methodology

Testing tools:

Due to the simple design of RESTweb services, testing REST is similar to any other web application and can be tested using the browser add-ons.

The following are the list of add-ons that can be used for testing REST APIs:

  • Postman
  • REST Console
  • REST Client
  • REST Easy
  • Poster

The following tools can be used for testing RESTful web services:

  • REST Client
  • SOAP UI

5.  Testing RESTful web services

Cross-Site Scripting vulnerability:

As the RESTful API “Blog” does not have a check on the special characters, it is possible to inject java scripts. (As indicated in the issue 39 at https://github.com/recess/recess/issues/39)

Step 1: Go to the “Write Post” page, enter a new post with the following script:

<script>alert(“XSSed”)<script>

Step 2: Save the post as shown in the following screenshot.

rest-01

Step 3: The following screenshot shows that the web service accepts the special characters and the script gets executed in the browser.


rest-02

Similarly you can test for other findings also.

6.  Appendix

Recess Framework Restful web service developed by Kris Jordan. It’s a lightweight deployment friendly framework. Let’s install the framework. REST APIs can be built using any programming language, Recess framework uses PHP which is easy to code and also to interpret.

The following tools are required to implement Recess:

  1. WAMP Server – http://www.wampserver.com/en/
  2. Recess framework – https://github.com/recess/recess/

Follow the steps given below to deploy the framework:

Step 1: Extract the Recess Zip file and add it to the web root ( Wamp->www)

Step 2: Make sure that the PHP extension, rewrite_mod is enabled. To check this, go to the icon tray in task bar and click on WAMP server. Select PHP and check the extensions enabled under PHP.

Step 3: Configure the database settings in the recess-conf.php file. This can be done by uncommenting the database of your choice. For example, to connect to mysql database hosted on localhost with default credentials, the mysql part of the database config should be uncommented and the replaced with the following line:

(‘mysql:host=localhost;dbname=recess’, ‘root’, ”)

Step 4: If using mysql database, then follow the steps given below to import the database:

  1. Login to phpmyadmin (http://localhost/phpmyadmin/index.php) and create a new database with the name “recess”.
  2. Select the database and click on the import option.
  3. Choose the file schema.sql at recess->data->sqlite folder and click on the “Go’ button.

You are all set now. Start testing the application by accessing ‑ http://localhost/recess/index.php/recess/apps/ (If you are running the wamp server on the port 80).

C&S Official Security Blog