REST Security (or lack thereof)

Update (since this post is linked from multiple places): see this post on REST Threat Models and Attack surface for more ideas on REST current state security options

So the whole REST security thing just gets funnier, the S for Simple folks forget that S also stands for security. Here was a response to my post on the fact that people who say REST is simpler than SOAP with WS-Security conveniently ignore things like, oh message level security:

HTTP Basic or HTTP Digest or SSL (certificate-based) for authentication. SSL for encryption and digital signatures. You know, the way we've been doing things since 1995.

Where to start? Right, it was state of the art in 1995. no bout a doubt it. The world has moved on slightly since then. You know a couple 97 million stolen identities, endless phishing/pharming (growing double digit pct each month), malware taking 60% cpu utilization on consumer desktops. You know little stuff like that

HTTP Basic? The hell you say. Here is a round up of ways to break and/or bypass that. There are only 5 listed however.

Report:

Warning of Al Qaeda cyber attack on finance sites
The US government has warned financial services companies of an Al Qaeda call for a cyber attack against online stock trading and banking websites beginning today

Don't worry about that boss, I put HTTP Basic in front of our apps!

SSL? My friend Daniel opined thusly about the wisdom of SSL and REST:

It's nice to run it all over HTTPS, so now the
gigantic hole you made in the firewall will provide some privacy for
me as I dig through your customer's credit card numbers...

You just have to love a point to point security model in a system that last time I checked is supposed to be about interoperability.

Hey boss, where should I put that SSL thingie again?

Now if you are at all serious about putting some security mechanisms in to your REST there are some good examples. One being Amazon's developer tokens using HMAC for authentication at the message level (you know where the data is). But if you are going to say that REST is so much simpler than SOAP then you should compare REST with HMAC, et. al. to the sorts of encryption and signature services WS-Security gives you and then see how much simpler is. And, you know, maybe even see, oh golly gee I don't know, which one protects your customers' data better? Until then, we'll just continue (as Gene Spafford said) using an armored car to deliver between someone living in a cardboard box and someone living on a park bench.

Update: Part 2 (in which we achieve after fashion and many comments something resembling consensus and an action plan to improve REST security) is here

Comments

[Mark]

"Use SOAP or the terrorists win?" Seriously, is this what it's come to?

[Gunnar]

No, it is more like the Viridian principle - Eat What You Kill. If REST is that much better than SOAP then show me how the security is as good or better. Instead we get handwaving and SSL.

[Mark Baker]

*sigh*

Come on folks, how many times does this have to be repeated; REST is *not* shorthand for "Current practice on the Web".

This is a critique of current practice, and a pretty good one too; I agree with most of its characterizations of things that could be improved. But to suggest there's something wrong with REST is simply wrong, at least without a principled look at if and how REST's constraints get in the way of deploying better, more secure solutions on the Web. In fact, REST itself even validates the complaint about SSL and the hole it bores through firewalls; REST tells us that visibility is lost by such a solution.

Until then, please stop the comparisons, because best case they're wrong, and worst case they're dishonest.

[Gunnar]

The difference is that WS-Security has been reviewed by lots of people with a background in security. REST has nothing of the sort. I really am all for simple and do not see these things as black and white issues, but my ask is this

1) If you are writing web software please take security seriously.

2) If you are going to say REST is simpler let's make sure we mean REST with message level security.

3) I did not start the comparisons, the REST people did.

4) I repeat - eat what you kill.

[Bill de hOra]

"I really am all for simple and do not see these things as black and white issues..."

You could have fooled me. Anyway, what is it about REST that precludes message level security? Should I be worried about taking security opining from someone who either doesn't understand the difference between REST, HTTP as the Web as deployed, or just doesn't care?

"Now if you are at all serious about putting some security mechanisms in to your REST..."

"HTTP", not "REST" - as you say "m,kay" (http://www.tbray.org/ongoing/When/200x/2006/11/16/WS-Socratic#c1164991445.443568).

[Amit Sharma]

Point taken ... if there was one. SSL and hand waving does not solve everything, but if you know what you are doing you can get what you are aiming for.

SSL can be used for privacy over an untrusted channel, server side authentication and client side authentication if you are willing to use client certificates.

Maybe privacy and your ire suffices for some folks ... in which case SSL and hand waving just fits the bill.

Perhaps Sam Ruby says it better than me.

[Gunnar]

Bill - where are the peer reviewed security mechanisms in REST that do what WS-Security does?

[Pete Lacey]

My response conflates REST with HTTP but that's unavoidable right now. Anyway, you can see it here: http://wanderingbarque.com/nonintersecting/2006/12/01/restful-security/

Pete

[Bill de hOra]

"where are the peer reviewed security mechanisms in REST that do what WS-Security does?"

Again, this inanity - is it compulsory to leave basic design principles like layering at the door with webservices? You're going to have do much better than this.

Put it this way. Where are are the peer reviewed security mechanisms in SOA?

There aren't any. There's WS-Security tho'. Is it uniformly deployed for all SOA? Of course not. Can WS-Security be used in a REST based design? Yes, if the messages are SOAP. Is there anything in REST that precludes message level security. No, I don't think there is. Does the deployed HTTP/Web need to go beyond secure channels and think about messages? Absolutely.

See, that's bordering on cogency. I can only assume that if this wasn't about FUD and mudslinging, we could move forward.

My ask is this:

1) If you are writing SOA please take security seriously, but quantify the risks and costs, before talking about what to deploy. Don't moralize or talk about security risk in terms of absolutes.

2) If you are going to say SOA is better or more secure let's make sure we mean SOA with interoperable message level security - and - we mean there are /specific/ technologies that support it, namely SOAP+WS-Sec. I see nothing in SOA that directly enables security, but SOA is so woolly, who knows?

3) if you are going to say REST is not simple with message level security in tow, let's make sure we know whether or not REST precludes message level security first. Does it?

[Bill de hOra]

"Point taken ... if there was one. SSL and hand waving does not solve everything"

You'll get no argument from me there's a need to do more than secure the channel on the Web. That said, if things like HMAC are to move forward, and we're to introduce concepts like tamper-evident or encrypted messages to the *Web*, that's a lot of evangelising. I guess the first thing is to ask why the B2C Web is ok with taking surrogate identifiers in the form of credit cards?

[Gunnar]

Bill- I agree with this totally:

"Put it this way. Where are are the peer reviewed security mechanisms in SOA?"

There are HUGE problems in SOA security both in theory and in practice. I teach an all day training on this, and there are many, many issues to be considered.

Bill:"There's WS-Security tho'. Is it uniformly deployed for all SOA? Of course not. Can WS-Security be used in a REST based design? Yes, if the messages are SOAP. Is there anything in REST that precludes message level security. No, I don't think there is. Does the deployed HTTP/Web need to go beyond secure channels and think about messages? Absolutely."

Great. I agree with this whole statement. At least one study showed that 72% of ESBs are using a weak security model

http://1raindrop.typepad.com/1_raindrop/2006/10/wsgameover_72_o.html

Regarding supporting WS-Security and/or WS-Security-like behavior in REST - this is exactly what I have been trying to ask for, sorry if I have not been clear, my fault, I do not have a dog in the WS-* v. REST hunt whatsoever. I care about tthe security properties I can get out of them for the systems I work on.

The requirements that drove WS-Security were:

• Multiple security tokens for authentication or authorization
• Multiple trust domains
• Multiple encryption technologies
• End-to-end message-level security and not just transport-level security

I really do see these as essential in basically every non-trivial environment these days. In any case, can someone build something RESTful that does? Of course, that is one reason I have posted the AWS example at least four times.

The thing is that WS-Security was also reviewed by a wide audience such as Verisign, IBM, MS, and friends. So while the functionality of the security mechanisms is definitely doable and desirable in a RESTful way, so too would be an open review process. This is important in security.

Bill: "Don't moralize or talk about security risk in terms of absolutes."

Could not agree more
http://1raindrop.typepad.com/1_raindrop/2006/10/decentralizatio.html

Bill: "If you are going to say SOA is better or more secure let's make sure we mean SOA with interoperable message level security "

Again, I don't really care if REST or SOA solves my security problem. I would be happiest if they would both address it. I think the WS-* people made a nice start with WS-Security.

Bill: "if you are going to say REST is not simple with message level security in tow, let's make sure we know whether or not REST precludes message level security first. Does it?"

No I don't think that it does per se. Again AWS does similar things to what WS-Security does.

Bill: "I guess the first thing is to ask why the B2C Web is ok with taking surrogate identifiers in the form of credit cards?"

I think that they are increasingly less ok with this. If you project forward from this point based on the progress that criminals and such have made in the last few years, it is not a pretty picture. There is a lot of money on the web, and it is not just hackers having fun, it is determined criminal professionals tha we have as opponents.

So anyway, if I was a muckety muck at Sun or some other big SW house, I would take the advice of a really smart guy who said

" It’s here today, it works, it’s standards-based, and there’s a huge opportunity for building tooling and developer support around it."
http://www.tbray.org/ongoing/

And what I would do, is learn from some of what Amazon and others have done with HMACs and developer tokens for their REST interfaces, and the tooling would enable the equivalent bits of what WS-Security and a few of the related security standards do, and make it brain dead simple and easy for a REST developer to build web style software with a security model that can go end to end instead of point to point.

[Harry Fuecks]

So SSL == gigantic hole in firewall?

Now if that isn't the pot calling the kettle black.

http://technetcast.ddj.com/tnc_play_stream.html?stream_id=416

Don Box: "if you look at the state of the average organization, they use proxy servers and they use firewalls to prevent normal TCP traffic from making it from one machine to another. Instead, they set up this infrastructure to allow HTTP to work. So part of the problem was replacing the transport, which is the way DCOM does framing, with an ACDP-based transport. That was the first part of the SOAP effort."

[Mark Baker]

FWIW, I recall at least 2 attempts at message level security in HTTP. The most recent one is http://www.httpsec.org/ and the first was http://www.w3.org/TR/WD-http-sea.html

Also, WS-Security can be used RESTfully (not to say it doesn't have other issues though). Too bad it requires SOAP, which is kind of a non-starter these days. P-)