Web services security standards aren't enough

Enterprise professionals comforted by Web services security standards -- proposed or established -- may want to think again. Although useful for securing Web services messages, the specifications do little to safeguard against SOAP array overflow attacks and other ways of penetrating the back-end systems of an enterprise (see also "Shielding Web services from attack").

With names such as WS-Security and SAML (Security Assertion Markup Language), it's understandable that practitioners might expect these standards to provide a framework for locking down their Web services applications.

For the most part, however, they don't.

"These standards do not deal with how you prevent attacks from happening," says Tony Baer, principal at onStrategies. "Standards are all about how you define the policy. Its all about handshaking."

WS-Security, among the most popular and mature of the standards, was developed by a coalition of vendors under the umbrella of OASIS, the prime standards body for Web services. It specifies the types of encryption and authentication that messages need -- for instance, SAML tokens, PKI, or Kerberos -- before they will be accepted and acted on. That ought to give the payment department at a large insurance company more confidence that the XML message requesting a $250,000 claim check is, in fact, from a trusted party.

But security experts hold little hope that WS-Security -- or any of its brethren, including WS-Trust or WS-SecurityPolicy -- will be enough to secure Web services, particularly if developers continue to write insecure code.

"The challenge with Web services is that the complexity is evolving faster than we can create standards to address them," says Danny Allan, director of security research at Watchfire. "If we keep chasing this train that has already left the station, we're never going to be secure."