REST Security Protections

Greg Leonard is an instructor with the SANS Institute for DEV541: Secure Coding in Java/JEE.

REST Security Protections

Representational State Transfer (REST) has become popular in modern web application development. They take advantage of HTTP, a well established web communication protocol, and provide a simple-to-understand framework for delivering a flexible and highly performant content delivery method for web services (known as RESTful services).  However, adoption of REST has seen some resistance as it does not include any standards for security.  This means that every service developed that wants to provide authentication, authorization, validation, encoding, or any other security concern is essentially on their own.  Clients that want to consume these services are likewise responsible for creating custom interfaces for every REST service they interact with.

Fortunately, there have been some efforts to try and create frameworks to help standardize some of these security concerns.  For example, OAuth was designed to provide a consistent authorization framework.  OAuth was designed with the “valet key” concept in mind – just like a valet key allows someone to start your car and drive it, but it does not allow them access to your glove box lock.  Similarly, OAuth can allow one application to interface with another application on your behalf.  For example, imagine you have accounts on both a file sharing program and an online printing program and you want to allow the printing application access to your online files.  It would be a major security risk to allow both of these applications to share the same authentication credentials.  Using OAuth, however, you could authenticate into both applications using separate credentials and then use the OAuth API to grant limited access to the printing application.  As with the valet example, the printing application could be given read-only access to your files without the ability to modify or delete them.

OAuth does have some drawbacks.  For example, OAuth 1.0 had a serious session fixation vulnerability and is no longer considered valid.  Also as an authorization framework and not an authentication framework, OAuth relies on the implementing systems to handle authentication properly.  OAuth does not have the capability to verify that the system that it is granting its valet key to is legitimate.  For example, many applications allow you to authenticate using your Facebook credentials by using the Facebook OAuth API.  Most of these systems assume that the Facebook account you are linking to actually belongs to you, but there have been many examples of attackers using their own Facebook accounts to link to a victim’s account.  Lastly, the OAuth framework has gone through many drastic changes during its evolution.  As such, version 2.0 is not backwards compatible with version 1.0.  If you want to interface with an OAuth service, you must use the same version as the service provider.

As an instructor for SANS DEV541 for the past couple of years, I consistently hear questions regarding web service security.  Students enjoy the depth of the material in DEV541, from the topics on Java EE to the secure SDLC.  However, one consistent question I hear is “Why doesn’t the course offer anything about web services?”

Well good news!  DEV541 now has a section dedicated to web services.  We will discuss the history of web services as they pertain to Java, from the old days of Remote Method Invocation, through the evolution of SOAP JAX-WS, and including the recent history with RESTful services JAX-RS.

Additionally, we will cover many relevant goals for modern web service development, including how to perform authentication, authorization, and validation with RESTful services.  We will discuss OAuth in detail, including providing hands-on experience with an example service using OAuth for authorization as well as discussing some key security issues related with the framework.

I’m looking forward to teaching this new section, and I’m looking forward to the feedback for the new section to see how we can continue growing DEV541 into the most useful class it can be.

About the Author

Gregory Leonard has over 16 years of experience in software development, with an emphasis on writing large-scale enterprise applications. Greg’s responsibilities have included application architecture and security, performing infrastructure design and implementation, security analysis, code reviews, and evaluating performance diagnostics. Greg is currently focusing on overseeing the integration of secure development practices for his company. Follow Greg on Twitter @appsecgreg.

LinkedIn OAuth Open Redirect Disclosure

During a recent mobile security engagement, I discovered an Insecure Redirect vulnerability in the LinkedIn OAuth 1.0 implementation that could allow an attacker to conduct phishing attacks against LinkedIn members. This vulnerability could be used to compromise LinkedIn user accounts, and gather sensitive information from those accounts (e.g. personal information and credit card numbers). The following describes this security vulnerability in detail and how I discovered it.

The Vulnerability
Section 4.7 of the OAuth 1.0 specification (RFC 5849) warns of possible phishing attacks, depending on the implementation. A vulnerable OAuth implementation could enable phishing attacks via user-agent redirection. The stated emphasis, further supported by OAuth 2.0 (RFC 6749 via “redirect_uri” parameter), is intended to raise awareness of open-redirection as a security vulnerability that should be avoided.

LinkedIn’s implementation lacked validation between the value of its “redirect_uri” parameter and the origin (base) of a registered client’s endpoint. In other words, if a redirect_uri (although optional) was entered during establishment of the OAuth integration, that redirect_uri value was not validated to ensure it belonged to a valid client. Manipulating this parameter to an unexpected location resulted in the application redirecting the user away from the intended web site.

The Attack
According to LinkedIn API documentation, the steps involved in obtaining an OAuth authorization token are as follows (prior to the fix recently put in place by LinkedIn):

First, a GET request specifying access permission is requested:,rw_nus,r_network&state=some_random_string_of_your_choice &redirect_uri=any_url

Upon successful authorization, a code is generated by LinkedIn and the end user’s browser (user-agent) is redirected to the URL specified in the redirect_uri parameter. Notice that the domain specified in the “redirect_uri” parameter in the above screenshot is the payload specified by our hypothetical attacker that redirects the end user to the malicious site.

Next, the browser redirects the user to an impersonated LinkedIn login page via the “redirect_uri” parameter, which attempts to gather the LinkedIn user’s credentials.

Finally, the victim then enters their credentials, trusting that the site is the official LinkedIn web application.

The proof-of-concept demonstrated the ability to phish for user’s credentials, but could have a larger impact if used against LinkedIn Premium members with credit card numbers stored with their personal account information.

LinkedIn Remediation
I contacted LinkedIn about the vulnerability in October 2013, and it was a pleasant experience working with the LinkedIn Information Security team members. They confirmed the vulnerability within 2 days. From confirmation of the vulnerability to deployment of its remediation, LinkedIn spent approximately seven months (from October 2013 to May 2014) developing the patch. LinkedIn took advantage of this opportunity to upgrade its OAuth implementation to v2.0, while still supporting its legacy API (v1.0) for compatibility with existing applications. Based on the information provided by LinkedIn, such remediation required deep collaboration with several partners on how OAuth tokens are handled.

At the time of writing of this document, a patch for the disclosed vulnerability had already been deployed. For a detailed disclosure, please visit to obtain a free electronic copy (PDF).

About the Author
Phillip Pham is a security engineer with a strong passion for Information Security. Phillip has worked in various sectors and for organizations of various sizes, ranging from small start-ups to Fortune 500 companies. Prior to transitioning into an Information Security career, Phillip spent ten years in software engineering. His last five years of Information Security experience have been focused on Application Security. Some of his application security assessment strengths (both onpremise and cloudbased) include web applications, web services, APIs, Windows client applications, and mobile applications. He currently holds a GCIH certification and is cofounder of APT Security Solutions. Follow Phillip on Twitter @philaptsec.