With security being one of the main tenets of SOA implementation and REST quickly becoming one of the prevalent SOA implementation approaches, the topic of REST security seems very timely. According to Chris Comerford and Pete Soderling, REST development does not address security well:
- REST does not have predefined security methods so developers define their own, and
- Often, developers in a hurry to just get... services deployed don't treat them with the same level of diligence as they treat web applications.
Comerford and Soderling continue by explaining that since REST is based on HTTP, REST services are prone to the same vulnerabilities as standard web applications, including broken authentication, injection attacks, cross-site scripting and cross-site request forgery. In addition, REST services are adding some unique security vulnerabilities, for example:
- Mashup related issues:
... a mashup that pulls data from multiple APIs might require user names and passwords. It's up to the mashup provider to authenticate end-users' access credentials. End users must trust the mashup provider not to steal (or inadvertently reveal) their credentials and the API providers must trust that the mashup provider has authenticated the valid user of this account, not a hacker or malicious user.
- Immature grass-roots protocols:
OAuth 1.0... is vulnerable to a session-fixation attack and could result in an attacker stealing the identity of an API end-user.
Fortunately, many HTTP security practices can be successfully applied for securing REST services, Comerford and Soderling are recommending several rules to follow:
- 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.
- Don't roll your own security. Use a framework or existing library that has been peer-reviewed and tested...
- Unless your API is a free, 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.
K. Scott Morrison further explains the state of affairs with REST security:
REST lacks a well-articulated security model... by virtue of its grassroots origins, [it] suffers from a security just-do-it-like-the-web nonchalance that’s certainly done it no favors... The REST style owes much of its popularity to being simple and fast to implement, particularly when faced with the interest-crushing complexity and tooling demands of the WS-* stack. It’s reasonable to think that in the enthusiastic dash to cross the working application finish line, that security is conveniently de-emphasized or forgotten altogether.
Morrison also reaffirms that REST services can be secured and shows how some of Comerford and Soderling recommendations can be implemented using SecureSpan Gateway by configuring a policy, ensuring that access to the service requires usage of SSL and authorizing service access based on group membership. Additionally, SecureSpan can be configured to implement scanning for cross-site, PHP and shell injection attacks.
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. Is that sufficient? Only time will show.