The Perils of Web Services

With confidentiality, we want to ensure that only the intended audience is able to access information. Integrity means that we know where the data came from and that it has not been altered in transit. For this to occur, we need to have strong authentication that allows the system to validate a true identify and authorization which grants access permission to only authorized users. When we attempt to implement these measures in Web services we find ourselves falling down a rat hole of acronyms and cobbled pieces which only address part of the issue.


Often the first place security professionals tend to look for help is the WS-Security (Web services security) standard. WS-Security is a proposed standard for dealing specifically with confidentiality and integrity for Web services. I’ve seen many implementations of Web services which attempt to sprinkle magic SSL/TLS security dust on the problem to make it go away. While using a protocol like HTTPS to transmit the messages between the requestor and the Web service, this only provides point-to-point security and does not address security for the message after it reaches the other point. We need so called end-to-end security and WS-Security attempts to provide us with that.

WS-Security allows users to attach timestamps to messages to ensure freshness and prevent replay attacks. There is a mechanism included for encrypting messages which provides the needed confidentiality. There is also a mechanism for digitally signing messages, which authenticates the sender and ensures the message has not been tampered with; meeting our integrity requirement. It also allows us to attach security tokens to a message such as username/password or X.509 certificates which can be used for authentication.

While a step in the proverbial right direction, WS-Security does have drawbacks such as performance issues and key management and distribution concerns. The most glaring however, is that it does not provide any authorization to know if the requestor has access to the information and functionality they are requesting. For this we can link in SAML (security assertion markup language), turn to XACML (eXtensible access control markup language); or use both.

Other Standards

SAML and XACML attempt to provide a means to create access control policies that can be enforced by the system. This allows restricted access to certain data and functionality based on a requestor’s identity. Both SAML and XACML can create policies which describe proper access controls for data and operations. The problem is that these access control policies are not easy to create, understand or manage. It is also difficult to determine which language to use.

As inferred from the challenges mentioned above, securing a Web service is a daunting task. Unfortunately, there is little help for developers in determining how best to integrate these components into their programs. Developers are left to flail about, hoping to stumble upon secure implementations. The typical response I’ve seen is to either delegate security to the network appliances or to ignore it all together. Neither of these options presents a desirable situation. As a security community we have to make it easier for developers to create secure code. It is our responsibility to shed light on the issue and not to leave them alone in the dark.

John Carmichael leverages his strong lab development, programming and security process skills to deliver secure software development training courses to some of the world’s largest organizations including Adobe, EMC and MassMutual. Prior to joining Security Innovation, John was a systems analyst who led various Web development labs and product training for both technical and non-technical audiences.