Tags:
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.
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.