Techniques for securing RESTful web services

1. Techniques for Securing REST
by Anivella Sudhakar, Senior Architect, CA Technologies
Abstract
Because the REST architecture style is based on the HTTP protocol, REST serv-
ices are prone to the same vulnerabilities as standard web applications, includ-
ing broken authentication, injection attacks, cross-site scripting, and cross-site
request forgery. Also, REST services face unique security challenges with Web
2.0 applications like mash-ups.
This article explains how REST security differs from HTTP security and suggests
various security mechanisms to address REST security challenges. This article
also sheds light on industry-wide initiatives to provide standards-based security
mechanism for REST services.
1. What is REST?
The REST approach is one of the major approaches to building distributed sys-
tems using “pure” web technologies (HTTP, HTML, and so on) and is widely
known as the resource-oriented approach. REST (REpresentational State Trans-
fer) is a term coined by Roy Fielding in his PhD dissertation describing a re-
source-oriented architecture style for networked systems1
.
An important concept in REST is the existence of resources (sources of specific
information), each of which is referenced with a global identifier (such as an
HTTP URI). In order to manipulate these resources, components of the network
(user agents and origin servers) communicate via a standardized interface (such
as HTTP) and exchange representations of these resources (the actual docu-
ments conveying the information)2
.
1.1 Security for REST Services and APIs
Because of the inherent HTTP attributes of REST such as simplicity, openness,
and scalability, more and more Application Programming Interfaces (API) are
being developed using REST principles. While doing so, existing HTTP Web ap-
plication security models (such as HTTPS and other authorization and authenti-
cation mechanisms) are also adopted to provide security for REST applications.
2. Differences between REST Security and SOAP Security
Although it is interesting to compare REST to SOAP, they are not directly compa-
rable because REST is an approach while SOAP is a protocol. Still, they are often
treated as alternatives, so we will look at them together. SOAP allows invocation
of remote procedure calls (RPC) via HTTP ports to provide web services support
across organizational boundaries. Many REST developers consider this as a
major flaw that compromises network security.
This occurs because policies have been made around standard port numbers to
distinguish applications, such as port 80 for HTTP. Any service can be blocked by
doing the necessary configuration at the firewall level, an approach that makes
it easy to have control over the applications that may be used. However, SOAP
over HTTP shifts this problem to the layer above by tunneling remote methods
over the standard HTTP port. At the TCP level, it is no longer possible to distin-
About the author
Anivella Sudhakar is a Senior Architect
at the CA Office in Hyderabad, India. He
is responsible for the design and devel-
opment of Service Desk Manager. He is
currently focused on designing common
RESTful services components for CA
Technologies products in collaboration
with other senior colleagues.
Prior to Joining CA Technologies, he
worked at Cordys as a Solutions Archi-
tect where he designed and imple-
mented various Cordys components and
SOA based enterprise solutions in the
areas of Manufacturing, insurance and
ITSM for customers in Europe, Gulf and
India.
At BHEL he developed a functional pro-
gramming tool for programming PLC’s
and software for distributed control sys-
tems (DCS).
Currently he is a member of the Tech-
nologies Innovation Committee (TIC) at
CA Technologies, and is a member of In-
dian Science Congress Association.
He has co-authored 5 patents in the
areas of Business Process Optimization
and Change Management at CA Tech-
nologies.
Anivella obtained his Masters Degree in
Computers with specialization in AI
from Osmania University, Hyderabad,
India.
32

2. guish the application or service being used by the port number. Instead, content
of the HTTP messages or SOAP messages must be analyzed to control access to
certain applications or services.
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. For example, GET is always considered
safe because it cannot modify any data or state of the server.
It is not possible for a firewall to identify the intent of a SOAP request sent using
the HTTP POST method to communicate with a given service without inspecting
the SOAP envelope. For example, there is no way to tell whether intent is to
query the data or erase the data.
For implementing authentication and authorization, SOAP places the burden on
the application developer whereas the REST methodology relies on web servers.
3. Challenges Faced by REST APIs and Applications
Because the REST architecture style is based on the HTTP protocol, these serv-
ices are prone to the same vulnerabilities as standard web applications such as:
Unvalidated Input: Attackers can use these flaws to attack backend compo-
nents through web applications or REST API. It is important to validate input
data as it traverses the application layer. A significant number of attacks can be
avoided by validating input data, whether obtained from the client, the infra-
structure, external entities, or database systems.
REST APIs should never trust inputs without verifying them. Some of the stan-
dard web application security techniques that can be applied to REST are as fol-
lows:
- Validate the size of parameters on the query string
- Validate the content of parameters on the query string
- Examine parameters in the query string for known attacks such as
SQL Injection
- Apply 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, access sensitive data, or perform unauthorized func-
tions.
Injection Attacks: Web applications pass parameters when they access exter-
nal systems or the local operating system. If an attacker can inject malicious
commands in these parameters, the external system may execute those com-
mands on behalf of the web application.
Some of the input validation techniques mentioned above can be used to guard
REST APIs against Injection attacks.
Immature Protocols: New protocols may not always properly handle security.
For example, OAuth 1.0 (E. Hammer-Lahav, 2010) is vulnerable to a session-fixa-
tion attack that could allow an attacker to steal the identity of an API end-user
(OAuth Security Advisory: 2009.1, 2009).
Also, REST services face the following additional security challenges from
browser scripting and Web 2.0 approaches like mash-ups:
• Cross-site scripting (XSS) and cross-site request forgery where a 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 user’s
Never trust inputs without verifying
them.
33

3. session token, attack the local machine, or spoof content to fool the
user.
Web 2.0 and Rich Internet Applications (RIA) rely heavily on REST APIs,
making these APIs prone to XSS attacks.
• A mash-up that retrieves data from multiple APIs might require user
credentials. It is up to the mash-up provider to authenticate end-users'
access credentials (such as same-origin bypass).
End users must trust the mash-up provider not to steal (or inadver-
tently 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.
4. Best Practices for REST Services Security
Unlike WS-* that specifies a well-defined security model that is protocol inde-
pendent and is built specifically for SOAP web services, REST does not currently
have its own security model. Instead, today’s REST security best practices lever-
age existing HTTP security implementation approaches.
Following are some of the rules recommended for securing REST services by
Comerford and Soderling (Soderling, 2010)3
1. Security checks should be consistent across all possible access
mechanisms. Always apply the same security checks for access to an
application, whether via its web Interface or via its API. For example, if
XSS is a concern, you should check it for both API and web access.
2. Stick to proven models in implementing security. Rather than building a
custom security approach, use any standard framework or existing
library that has been peer-reviewed, tested and approved by the
appropriate authority.
3. For read-only and public REST API’s, it is acceptable to a use simple
single key based security mechanism. Security mechanism for all other
REST API’s should include at least password based validation.
4. Never send unencrypted authentication data over unsecure channels.
Always encrypt authentication data while sending over unsecure
channels. Ex. HTTP Basic Authentication Sends username and password
in plain Base 64 encoded format, which can be a security risk.
If possible, use any hash-based message authentication code (HMAC)
approach as it can provide better security.
5. Protect REST API’s against query injection attacks with the help of
standard and proven query filtering techniques.
5. 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.
The following are some of the main HTTP approaches for securing web applica-
tions:
• HTTP authentications
• Token-based authentication
• Transport Layer Security (TLS) protecting sessions over the Internet
Security checks should be consistent
across all possible access
mechanisms.
34

4. 5.1 HTTP Authentication Schemes
HTTP authentication mechanisms can be divided into the following two cate-
gories:
1. Basic authentication scheme
2. Digest authentication scheme
Basic Authentication Scheme
The basic authentication scheme is the simplest authentication scheme4
de-
fined in RFC 26175
. It sends an HTTP header called 'Authorization' with the
Base64 encoding of the "<username>:<password>" string.
If the provided authentication information is valid, the content of the requested
resource is returned along with HTTP status code of 200. If authentication infor-
mation is not valid; that is, if the request is issued without the 'Authorization'
header or if the provided credentials are invalid, the server responds back to the
client with a HTTP status code of 401 requesting authentication.
The basic authentication scheme is also called pre-emptive authentication as it
requires clients to send the authentication header in the first request, with no
additional client interaction required. Because of this pre-emptive nature, 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
1. Simple and easy to use
2. Almost all HTTP libraries support it
Disadvantages
1. Transmits the username and password in a clear and easily decryptable
manner (Base64 coding)
Because of its simplicity, the basic authentication scheme is widely popular and
supported by the majority of REST API implementations. It is usually appropri-
ate only over secure connections, for example, HTTPS.
Digest Authentication Scheme
Digest access authentication is one of the agreed methods a web server can use
to negotiate credentials with a client (such as a web user's browser). It uses en-
cryption to send the password over the network which is safer than the Basic ac-
cess authentication. Technically, digest access authentication is an application
of Message-Digest algorithm 5 (MD5) cryptographic hashing using nonce values
(defined below) to discourage cryptanalysis. Digest access authentication was
originally specified by RFC 20696
.
Digest authentication is a challenge-response mechanism, where a client appli-
cation (such as a browser) sends an HTTP request (such as GET) to a web server.
The server sees the resource (or URL) being accessed has been configured to re-
quire digest authentication and replies with a 401 "Authentication Required"
status along with a "nonce” - a unique hash of several data items, one of which
is a secret key known only to the server.
The client application computes an MD5 hash of the username, password,
nonce, and URL and resends the original request along with the hash.
The web server compares that hash with its own computation of the same val-
ues. If they match, the original HTTP request is allowed to access the specified
35

5. resource.
Advantages
1. The password is not used directly in the digest. Instead, the stored
value is hash-generated using MD5 (username:realm:password).
2. The client nonce introduced in RFC2617 allows the client to prevent
chosen plaintext attacks by generating different nonces each time that
the 401 authentication challenge response code is presented.
3. Replay attacks can be prevented by including a timestamp in the server
nonce submitted by client.
4. The server can maintain a list of recently issued or used server nonce
values to prevent reuse.
Disadvantages
1. 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.
2. Digest access authentication is vulnerable to a man-in-the-middle
(MitM) attack.
3. Digest authentication involves too much traffic. HTTP authentication is
usually a two-step process to establish a session, but RESTful services
do not usually have any kind of session.
6. Token-Based Authentication
Token-based authentication is the approach used by Amazon Web Services
(AWS) for authenticating REST services. In the context of Amazon Web Services
(AWS) requests, authentication is the process AWS uses to both confirm that a
request came from a registered user and obtain the identity of that registered
user.
To enable authentication, each request must carry information about the iden-
tity 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 ac-
count 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.
1. The sender constructs a request to AWS.
2. 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.
3. 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.
36

6. 4. AWS uses the Access Key ID to look up the Secret Access Key.
5. This is not truly private because Amazon also knows the sender’s
private key.
6. 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.
7. 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 a reinvention of a subset of SOAP/WS-Security functionality for
REST. Concepts used from WS-Security are as follows:
• WS-Security UsernameTokens with timestamp support, for sending
username tokens
• WS-Security’s support for XML Signature
Advantages
1. No need to exchange user credentials
2. Helps in validating the identity of the sender of a request
3. Helps is in tracking, applying Access Control List (ACL )and policies;
for example, the number of request per hour
Disadvantages
1. No proof of possession of the Secret Access Key
This approach is better than basic or digest authentications approaches and pro-
vides better security for RESTful services without much overhead.
7.0 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 In-
ternet. 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. TLS or SSL provides transport level,
point-to-point security7
.
In the TSL approach, client and server negotiate a Stateful connection by using a
37

7. handshaking procedure and agreeing on various parameters used to establish
the connection's security.
The client application initiates handshaking by connecting to a server, request-
ing a secure connection, and presenting a list of supported ciphers and hash
functions. From this list, the server chooses the strongest cipher and hash func-
tion 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 de-
cryption.
This concludes the handshake and begins the secured connection, which is en-
crypted and decrypted with the key material until the connection closes.
Advantages
1. Encryption protects request and response bodies from intermediate
prying eyes.
2. Server authenticated — Clients can store the server's SSL certificate and
monitor the server to ensure it does not change over time to guard
against a man-in-the-middle type attack.
3. Using a certificate signed by a signing authority can also provide a
similar level of assurance for the client application.
4. Easy setup and can be configured at the web server. No additional
coding is required.
Disadvantage
1. Increased load - Encrypting and decrypting communication is
noticeably more CPU-intensive than unencrypted communications.
One issue with both TLS and SSL is that every request requires additional back
and forth communications to set up the secure socket. This overhead can be
minimized using the Stateful connection feature of HTTP 1.1. Though all REST
implementations take advantage of this approach to secure authentication
mechanisms like basic authentication, the SSL or TSL security approach does not
naturally align with the REST architecture. TLS secure sessions are user specific
and keys are generated dynamically. The content is encrypted repeatedly as it
travels via a secure tunnel, making it impossible to cache this data as the web
caches cannot access the data inside the tunnel. However, clients receiving the
content can copy it locally. This heavily reduces the scalability of the REST archi-
tectural 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.
The fundamental challenge with existing HTTP security models is that they offer
IP-to-IP security solutions and not application-to-application ones.
The fundamental challenge with exist-
ing HTTP security models is that they
offer IP-to-IP security solutions and
not application-to-application ones.
38

8. 8.0 Industry Wide Standards for REST Services Security
8.1 OAuth (OAuth Community Site)
Open Authorization (OAuth) is an open standard for authorization. It allows
users to share their private resources stored on one site with another site with-
out having to hand out their credentials, typically username and password.
OAuth allows users to hand out tokens instead of credentials to their data
hosted by a given service provider. Each token grants access to a specific site
(for example, a video editing site) for a specific resource (for example, only
videos from a specific album) and for a defined duration (for example, the next
2 hours). This allows a user to grant a third-party site access to their information
stored with another service provider, without sharing their access permissions or
the full extent of their data.
OAuth tokens are session identifiers. Interaction is not stateless between re-
quests in the OAuth token negotiation protocol as the requests must be per-
formed in a specific sequence and they do require per-client storage on the
server as needs to track things such as when they were issued. So, OAuth does
violate the strict principles of a RESTful architecture.
OAuth can potentially be used as an authorizing mechanism to consume se-
cured (authenticated) RSS/ATOM feeds. In general, consumption of RSS/ATOM
feeds that requires authentication has always been an issue.
OAuth is a service that is complementary to, but distinct from, OpenID.
8.2 OpenID (OpenID Foundation)
OpenID is an open standard that describes how users can be authenticated in a
decentralized (brokered authentication) manner, avoiding the need for services
to provide their own ad hoc systems and allowing users to consolidate their dig-
ital identities.
Brokered authentication standards, such as OpenID, accommodate RESTful web
services for browser driven client or use cases. However, they do not address
RESTful service patterns where identities need to be propagated across nested
service invocations, or any RESTful web service client that is not browser based.
9. Conclusion
Current security models around HTTP are built to address the traditional request
response patterns such as stateful communication, server side sessions, and
long connection timeouts. The REST approach brings its own set of request re-
sponse paradigms such as statelessness, caching more requests to the server
(than traditional web applications), non browser based clients, and so on. More-
over, REST services are widely used for API design unlike traditional web serv-
ices. The existing HTTP security models, in most of the cases, reduce the REST
service capabilities (for example, the SSL and REST caching mentioned above,
and so on).
The current HTTP security approaches are not sufficient to address the security
needs of REST services. Therefore, there is a definite need to extend the existing
HTTP security models to adequately address the specific needs for REST services
and Web 2.0 applications.
Initiatives such as OAuth and OpenID are very encouraging in terms of providing
security approaches for modern web applications. Providing more space for in-
clusion of the REST approach in these standards will augment in bringing up
standardization of REST services security instead ending up with multiple and
custom security implementations.
There is a definite need to extend
HTTP security models to address the
specific needs of REST.
39

9. Abbreviations
ACL Access Control List API Application Programming interface
Atom The Atom Syndication Format AWS Amazon Web Services
CA Certificate Authority HMAC Hashing for Message Authentication code
HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure MitM Man-in-the-middle
POX Plain Old Xml REST REpresentational State Transfer
RPC Remote procedure calls RSS Really Simple Syndication
S3 Amazon Simple Storage Service SSL Secure Socket Layer
TLS Transport Layer Security URI Uniform Resource Identifier
XSS Cross-site scripting
References
1
Chapter 5 of Fielding's dissertation is "Representational State Transfer (REST)". http://www.ics.uci.edu/~fielding/pubs/dis-
sertation/rest_arch_style.htm
2
Representational State Transfer (REST) http://en.wikipedia.org/wiki/Representational_State_Transfer
3
Why REST security doesn't exist - Chris Comerford and Pete Soderling.
http://www.computerworld.com/s/article/print/9161699/Why_REST_security_doesn_t_exist?taxonomyName=Security&t
axonomyId=17
4
Basic Access Authentication Wiki http://en.wikipedia.org/wiki/Basic_access_authentication
5
Basic Access Authentication RFC 2617 http://www.faqs.org/rfcs/rfc2617.html
6
Digest access authentication RFC 2069 http://tools.ietf.org/html/rfc2069
7
Transport Layer Security Wiki http://en.wikipedia.org/wiki/Transport_Layer_Security
Acknowledgements
• RESTful Security by Dan Forsberg, Nokia Research Center, Helsinki, Finland dan.forsberg@nokia.com , dforsber@gmail.com
• Representational State Transfer (REST) WiKi http://en.wikipedia.org/wiki/Representational_State_Transfer
• RFC 1321 The MD5 Message-Digest Algorithm http://www.ietf.org/rfc/rfc1321.txt
• RFC 2069 An Extension to HTTP : Digest Access Authentication http://www.ietf.org/rfc/rfc2069.txt
• RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 http://www.ietf.org/rfc/rfc2616.txt
• RFC 2617 HTTP Authentication: Basic and Digest Access Authentication http://www.ietf.org/rfc/rfc2617.txt
• Why REST security doesn't exist - Chris Comerford and Pete Soderling
http://www.computerworld.com/s/article/print/9161699/Why_REST_security_doesn_t_exist?taxonomyName=Security&t
axonomyId=17
• Security for REST and Web 2.0 - Richard Mooney - Senior Solution Architect
http://www.iamcorean.net/attachment/hk11.ppt
• OAuth Core 1.0 http://oauth.net/core/1.0/
• OAuth Security Advisory: 2009.1 http://oauth.net/advisories/2009-1/
• Is OAuth 2.0 Bad for the Web? http://www.infoq.com/news/2010/09/oauth2-bad-for-web
• Acknowledgement of the OAuth security issue http://blog.oauth.net/2009/04/22/acknowledgement-of-the-oauth-secu-
rity-issue/
• Cross-site scripting (XSS) Wiki http://en.wikipedia.org/wiki/Cross-site_scripting
• Cross-site request forgery Wiki http://en.wikipedia.org/wiki/Cross-site_request_forgery
• Rich Internet application http://en.wikipedia.org/wiki/Rich_Internet_application
• MD5 (Message-Digest algorithm 5) http://en.wikipedia.org/wiki/MD5
• Access control list (ACL) Wiki http://en.wikipedia.org/wiki/Access_control_list
40