Techniques for securing rest
1 like499 views
The document discusses techniques for securing REST (REpresentational State Transfer) services and APIs. It begins by explaining that REST services are vulnerable to the same attacks as traditional web applications, such as injection attacks and authentication issues. It then describes how REST security differs from SOAP security in that REST messages can be more easily identified by analyzing the HTTP commands, unlike SOAP messages which require inspecting envelopes. The document outlines challenges for REST APIs like input validation, broken authentication, and risks of emerging protocols. It concludes by recommending best practices for REST security such as consistent security checks across access points and use of proven security frameworks and libraries.
Techniques for securing rest
- 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