Follow Us

We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message

The security nightmare of REST web services

The web protocol is winning the battle of the APIs

Article comments

Clearly, REST (Representational State Transfer) is winning the web service protocol debate. What was once a grassroots movement has proliferated inside the enterprise and out. As of January 2010, 1,100 out of the 1,600 APIs listed on Programmable Web are REST-based. Some of our best-known cloud services utilize REST, including APIs from Amazon, SalesForce and Google.

As API engineers, we're all for it. The architectural style described by REST is simpler, more open, more scalable and more consistent with other Internet protocols (remember that REST is basically HTTP) than the alternative, the litany of web service protocols referred to as WS-*.

But as security experts, we're aghast at some of the REST-based API practices we're seeing. In general, the security of APIs is much lower than in web applications. There are two key reasons for this:

1) REST does not have predefined security methods so developers define their own, and

2) Often, developers in a hurry to just get their web services deployed don't treat them with the same level of diligence as they treat web applications.

These conditions lead to web services with serious vulnerabilities. For instance, most APIs handle authentication using a key but no secret, essentially requiring a user name but no password. Another problem is using HTTP basic authentication (with no SSL) and letting the user name and password cross the wire with no encryption.

REST APIs typically have the same attack vectors as standard web applications, including injection attacks, cross-site scripting (XSS), broken authentication and cross-site request forgery (CSRF).

They also have some unique vulnerabilities and attack vectors, including mashup related issues in which the mashup requires end users to place too much trust in the mashup provider. For example, 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. Other vulnerabilities stem from immature grassroots protocols such as OAuth 1.0, which is vulnerable to a session fixation attack and could result in an attacker stealing the identity of an API enduser.

So, what can you do to secure your RESTful APIs? There are many rules to follow, but we'll call out a few:

  • Do employ the same security mechanisms for your APIs as any web application your organisation deploys. For example, if you are filtering for XSS on the web frontend, 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. Developers not familiar with designing secure systems often produce flawed security implementations when they try to do it themselves, and they leave their APIs vulnerable to attack.
  • 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. (Use SHA-2 and up, avoid SHA & MD5 because of vulnerabilities.)

We'll be getting into greater technical depth on REST web service security issues and methods at the RSA Conference 2010, session ID AND-203. Hope to see you there!


Share:

More from Techworld

More relevant IT news

Comments

Brian said: I cant count how many things are wrong with this article I tried to list them but ran over the word count In short just remember that REST is no more secureinsecure than the rest of the web It also can make use of all the security features present in the rest of the web Identify your risks and apply company resources cost effectively to apply standard security Ignore about 60 of the article above



Send to a friend

Email this article to a friend or colleague:

PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.

Techworld White Papers

Choose – and Choose Wisely – the Right MSP for Your SMB

End users need a technology partner that provides transparency, enables productivity, delivers...

Download Whitepaper

10 Effective Habits of Indispensable IT Departments

It’s no secret that responsibilities are growing while budgets continue to shrink. Download this...

Download Whitepaper

Gartner Magic Quadrant for Enterprise Information Archiving

Enterprise information archiving is contributing to organisational needs for e-discovery and...

Download Whitepaper

Advancing the state of virtualised backups

Dell Software’s vRanger is a veteran of the virtualisation specific backup market. It was the...

Download Whitepaper

Techworld UK - Technology - Business

Innovation, productivity, agility and profit

Watch this on demand webinar which explores IT innovation, managed print services and business agility.

Techworld Mobile Site

Access Techworld's content on the move

Get the latest news, product reviews and downloads on your mobile device with Techworld's mobile site.

Find out more...

From Wow to How : Making mobile and cloud work for you

On demand Biztech Briefing - Learn how to effectively deliver mobile work styles and cloud services together.

Watch now...

Site Map

* *