Blog powered by TypePad

« Protect the transaction | Main | Of Assets and Threats »

Current State - Empowering Developers and Attackers Alike

Larry O'Brien says WS-* is too hard

I’ve advocated REST and POX in this column over the years, but never at the expense of WS-*, for which I always gave a “to be sure, complex scenarios may call…” deferral. No more. The final straw came when I found myself tracing a WS-* service call with a network sniffer. A network sniffer! In order to see why my multihundred-dollar, best-in-breed tool wasn’t able to interact with my “simple” Web service! What is this, NetWare in 1992? With REST, the URI endpoint for the communication is universally reachable—point a browser at it to see the client view, toss a server page in there to see the server view. With POX, you’re just a cut-and-paste away from parameter and response validation and automation.

Fair enough, but the problem is that attackers are programmers too. Basically, when you empower your developers you are likely to empower attackers. The same week that the above article was posted we had a Hell of a Week for Online Crime including

So the state of the 1995 security model, aka network firewall, SSL, and a prayer, that most developers use for app "security" is not cutting it. Larry O'Brien makes legitimate points about the usability of some elements of the WS-* stack. What is missing from this conversation is that the decisions are left up to developers to choose what is easiest to work with, without consideration for what is at risk. Were the developers' personal info or money stolen in the above cases? Probably not. So why not just say WS-* is too hard and rely on your network firewalls, SSL, and prayers, right?

My mantra when developers say it is ok to use personal info for interop because it is protected by SSL is to say "ok, can we use your SSN for testing then?"

Instead of punting message level security away as too hard, how about we

a) Look at WS-* as a stack that still requires more engineering to get right. I seem to recall Apache was not perfect at 1.0 either.

b) Continue to identify and develop Restful message level security solutions

c) Both of the above

Comments

Okay, first off, I'm not really familiar wth the various security standards of SOAP. I use the .NET implementation of web services in my job but that's about it. The reason I'm interested in REST is that in our system, we've ended up just passing XML around as the payload for the SOAP message. We haven't gone the whole WS-Security route because we've just ended up encrypting/signing the XML with the relevant W3C standards. Couldn't the same be done with REST to ensure message-level security?

The comments to this entry are closed.