Security For Rest Services And APIS Computer Science

Since REST architecture style is based on HTTP protocol, these services are prone to the same vulnerabilities as standard web applications like broken authentication, injection attacks, cross-site scripting and cross-site request forgery. Also REST services faces unique security challenges with Web 2.0 applications like mash-ups.

This article explains how REST security is different from HTTP security and ways of addressing REST security challenges using various security mechanisms. 

This article also throws some light on industry wide initiatives to provide standards based security mechanism for REST services.

What is REST?

The REST approach is one of the major approaches to building distributed systems using "pure" web technologies (HTTP, HTML etc) and this approach is widely known as resource-oriented approach. REST (REpresentational State Transfer) is a term coined by Roy Fielding in his PhD dissertation describing a resource-oriented architecture style for networked systems [] .

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information) [] .

Security for REST services and API's

Because of the inherent HTTP attributes of REST like simplicity, openness, scalability more and more Application Programming Interfaces (API) are being developed using REST principles. While doing so existing HTTP Web application security models used (e.g. HTTPS; authorization and authentication mechanisms) are also adopted to provide security for REST applications.

Difference between REST security and SOAP security

SOAP allows invocation of remote procedure calls (RPC) to be invoked via HTTP ports to provide web services support across organizational boundaries, but majority of the REST developers considers this as a major flaw that compromises network security. REST calls also go over HTTP or HTTPS but with the help of firewall or similar software one can easily identify the intent of the REST message by analyzing the HTTP commands used in the request (Ex. GET is always considered as safe as it cannot modify any data or state of the server)

SOAP requests always use HTTP POST method to communicate with a given service. It is not possible for firewalls to identify the intent of the SOAP request without inspecting SOAP envelope (Ex. There is no way to tell whether intent is to query the data or erase the data)

For authentication and authorization, SOAP places the burden in the hands of the application developer. The REST methodology instead takes into account the fact that Web servers already have support for these tasks.

Challenges faced by REST API's and Applications

Since REST architecture style is based on HTTP protocol, these services are prone to the same vulnerabilities as standard web applications like some mentioned below

Un validated Input: Attackers can use these flaws to attack backend components through a web applications or REST API's. It is very important to validate input data as it traverses the application layer. A large number of attacks can be mitigated by validating input data, whether obtained from the client, infrastructure, external entities or database systems.

REST API's should never trust incoming inputs without verifying them. Following are some of the standard Web Application Security techniques that can be applied to REST Web Services as well.

- Validating the size of parameters on the Query String

- Validating the content of parameters on the Query String

- Examining parameters in the Query String for known attacks such as SQL Injection

- Applying regular expressions to Query String parameters

Broken authentication: If restrictions on what authenticated users are allowed to do are not properly enforced, attackers can exploit these flaws to gain control of other users' accounts, sensitive data, or perform unauthorized functions.

Injection attacks: Where web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

Some of the input validations techniques mentioned above can be used to guard REST API's against Injection attacks.

Immature grass-roots protocols, pay good attention before adhering to new protocols Ex. OAuth 1.0, which is vulnerable to a session-fixation attack and could result in an attacker stealing the identity of an API end-user

Also REST services faces unique security challenges with browser scripting and Web 2.0 approaches like mash-ups:

Cross-site scripting (XSS) and cross-site request forgery where web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end users session token, attack the local machine, or spoof content to fool the user.

Web 2.0/RIA applications relies heavily on REST API's, these API's are prone to XSS attacks.

A mash-up that retrieves data from multiple APIs might require user credentials. It's up to the mash-up provider to authenticate end-users' access credentials (e.g. same-origin bypass).

End users must trust the mash-up provider not to steal (or inadvertently reveal) their credentials and the API providers must trust that the mash-up provider has authenticated the valid user of this account, not a hacker or malicious user.

Best practices for REST services security

Unlike WS* that specifies a well-defined security model, which is protocol independent and is build specifically for web services, REST doe not (currently) has its own security model. Instead, today's REST security best practices are leveraging existing HTTP security implementation approaches. Following are the some of the rules recommended for securing REST services (by Comerford and Soderling (Soderling, 2010) )

Do employ the same security mechanisms for your APIs as any web application your organization deploys. For example, if you are filtering for XSS on the web front-end, you must do it for your APIs, preferably with the same tools.

CA SDM REST API implementation security strictly follows this best practice by adhering to all access policies/restriction implemented by SDM web application (using SDM SLUMP API's on the server side).

Don't invent or roll out your own security. Use a framework or existing library that has been peer-reviewed and tested.

Unless your REST API read-only public API, don't use single key-based authentication. It's not enough. Add a password requirement.

Don't pass unencrypted static keys. If you're using HTTP Basic and sending it across the wire, encrypt it.

Ideally, use hash-based message authentication code (HMAC) because it's the most secure

Filtering QueryStrings is important, for this REST security can follow standard to Web Application Security approaches.

Web Application security mechanisms and REST services

Let us look at some of the major HTTP security approaches within the scope of REST to see how they help in securing REST services.

Following are some of the some of the main HTTP approaches for securing web applications

HTTP authentications

Token based authentication

Transport Layer Security (TLS) protecting sessions over the Internet

HTTP Authentication Schemes

HTTP authentication mechanisms can be briefly divided into two popular categories and they are

Basic Authentication scheme

Digest Authentication scheme

Basic Authentication scheme

Basic Authentication scheme is the most simple authentication scheme [] defined in RFC 2617 [] . It sends a HTTP header called 'Authorization' with the Base64 encoding of the ":" string as follows:

If the provided authentication information is valid, the content of the requested resource is returned along with HTTP status code of 200 as shown below. If authentication information is not valid i.e. if the request is issued without the 'Authorization' header or if the provided credentials are invalid, the server would respond back to the client with a HTTP status code of 401 requesting authentication as shown below.

Basic Authentication scheme is also called pre-emptive authentication schemes as it client to send the authentication header in its first request, with no additional client interaction required. Because of this pre-emptive nature of basic authentication can be considered as performing slightly better than Digest (challenge-response) authentication that requires a re-issuing of the request with a response to the challenge presented.

Advantages

Simple and easy to use

Virtually all HTTP libraries support it

Disadvantages

Transmits the username and password in the clear easily decrypt-able manner (i.e. using Base64 coding)

Because of its simplicity Basic Authentication scheme is widely popular and supported by majority of the REST API implementations. It is usually appropriate only over secure connections i.e. HTTPS.

Digest Authentication scheme

Digest access authentication is one of the agreed methods a web server can use to negotiate credentials with a client (ex. web user's browser). It uses encryption to send the password over the network which is safer than the Basic access authentication. Technically digest authentication is an application of MD5 cryptographic hashing with usage of nonce values to discourage cryptanalysis. Digest access authentication was originally specified by RFC 2069 [] 

Digest authentication is a challenge-response mechanism, where a client application (ex. Browser) sends an HTTP request (e.g. a GET) to a web server. The server sees the resource (or URL) being accessed has been configured to require Digest authentication and replies with a 401 "Authentication Required" status along with a "nonce" i.e. a unique hash of several data items, one of which is a secret key known only to the server.

Client application computes MD5 hash of the username, password, nonce and URL are re-sends the original request along with the hash.

The web server compares that hash with its own computation of the same values. If they match, the original HTTP request is allowed to access the specified resource.

Advantages

The password is not used directly in the digest, but rather hash generated using MD5(username:realm:password) is stored.

Client nonce (introduced in RFC2617), which allows the client to prevent chosen plaintext attacks

Replay attacks can be prevented by including timestamps in server nonce submitted by client.

Server cab maintain a list of recently issued or used server nonce values to prevent reuse

Disadvantages

Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode

Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack

Digest authentication involves too much traffic i.e. HTTP authentication is usually a two-step process to establish a session and RESTful services don't usually have any kind of session.

Token based Authentication

Amazon Web Service (AWS) token based approach for authenticating REST services.

Amazon Web Services (AWS) request authentication (Amazon):

AWS request authentication is the process of verifying the identity of the sender of a request. In the context of Amazon Web Services (AWS) requests, authentication is the process by which AWS can confirm that a request came from a registered user, as well as the identity of that registered user.

To enable authentication, each request must carry information about the identity of the request sender. The request must also contain additional information that AWS can use to verify that the request can only have been produced by the sender identified. If the request passes this verification test it is determined to be "authentic" and AWS has sufficient information to verify the identity of the sender.

Verifying the identity of the sender of a request is important, as it ensures that only those requests made by the person or party responsible for the AWS account specified in the request are accepted and allowed to interact with AWS services. In this manner, request authentication allows Amazon to track the usage of AWS services on a per request basis. This enables Amazon to charge and bill AWS subscribers for use of AWS paid (not free) services.

The following steps are the basic steps used in authenticating requests to AWS. It is assumed that the developer has already registered with AWS and received an Access Key ID and Secret Access Key.

The sender constructs a request to AWS.

The sender calculates a Keyed-Hashing for Message Authentication code (HMAC), the request signature using the sender's Secret Access Key and the values of the Service, Operation, and Timestamp parameters as input.

The sender of the request sends the request data, the signature, and Access Key ID (the key-identifier of the Secret Access Key used) to AWS.

AWS uses the Access Key ID to look up the Secret Access Key

This not truly private as Amazon also knows senders private key.

AWS generates a signature from the request data and the Secret Access Key using the same algorithm used to calculate the signature in the request.

If the signature generated by AWS matches the one sent in the request, the request is considered to be authentic. If the comparison fails, the request is discarded, and AWS returns an error response.

This approach is reinvention of a sub set of SOAP/WS-Security functionality for REST and that is as follows

WS-Security UsernameTokens, with timestamp support, for sending username tokens

WS-Security's support for XML Signature

Advantages

No need of exchanging user credentials

Helps in validating identity of the sender of a request

Helps is in tracking, applying ACL and policies Ex. Number of request per hour etc;

Disadvantages

No proof of possession of the Secret Access Key

This approach is better than Basic or digest authentications approaches and provides better security with for RESTful services much overhead.

Transport Layer Security (TLS) and Secure Socket Layer (SSL)

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability. Transport Layer Security (TLS) or Secure Socket Layer (SSL) provides transport level, point-to-point security [] .

In TSL approach client and server negotiate a stateful connection by using a handshaking procedure by agreeing on various parameters used to establish the connection's security.

Client application initiates handshake by connecting to a server and requests a secure connection and presents a list of supported ciphers and hash functions. From this list, the server picks the strongest cipher and hash function supported by the server and notifies the client of the decision.

The server sends back its identification in the form of a digital certificate. (The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key).

The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is valid before proceeding.

In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key. From the random number, both parties generate key material for encryption and decryption.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

Advantages

Encryption protects Request and Response bodies from intermediate prying eyes.

Server authenticated - Clients who stores the server's SSL certificate can monitor server to ensure it does not change over time to prevent man-in-the-middle type attack.

Using a certificate signed by a signing authority can also provide a similar level of assurance for the client application.

Disadvantage

Increased load, Encrypting and decrypting communication is noticeably more CPU-intensive than unencrypted communications

Every request requires additional back and forth communications to set up the secure socket

This overhead can be minimized by using stateful connection feature of HTTP

Easy setup and can be configured at web server. No additional coding required.

Though all REST implementations take advantage of this approach to secure authentication mechanisms like basic authentication etc, SSL or TSL security approach does not naturally align with the REST architecture in the sense that secure sessions create session specific keys but more static data that can be stored in web caches cannot be confidentiality protected and fetched from the caches at the same time. This heavily reduces the scalability of the REST architectural style for applications and services that require access control to the data and for this reason provide the data through e.g. TLS tunnels or require HTTP authorization.

"Fundamental challenge with existing HTTP security models is that they offer IP-to-IP security solutions and not application-to-application ones"

Industry wide standards for REST services securityTo be completed

Abbreviations

API

Article name: Security For Rest Services And APIS Computer Science essay, research paper, dissertation