I went and watched Gunnar Peterson present an excellent overview of the state of Web Services security.
He had two points that hit home for me. One is that security vendors and developers are on different planets. It brought back memories of having to authenticate a web application using SAML with a device called “Reactivity”. It was 2 weeks of living hell. There was no documentation and no feedback about what I was doing wrong. As a developer, I would have needed a training or at least a hair follicle on which to base an investigation on what to do. Shudder. I liked his point that both developers and security pros need to take some steps towards the other.
Another point was how much of web services security was really left up to the developers and integrators. I saw this working with Oracle’s OAAM. The product can be perfect, but it is up to a team of developers to implement it properly.
He introduced the development of an OWASP top ten for web services. He went over examples of how people screw up web services security. Most memorable was the MQ product by IBM which has anonymous access turned on by default, and a recent error in Google’s Single Sign-on.
Another point was how ruthlessly stateless web services really are. There was a lot of talk on preventing “replay” attacks, which happen when a third party sniffs unencrypted web traffic containing web services calls and sends the exact same instructions again. the listening server has no way to detect if this replay is valid. In web applications, nonces (no more than once) can be used to ensure that replays do not happen, but it is difficult to “hack state back into the protocol”. For these reasons, https needs to be used for sensitive web services transactions. He was careful to say that for most web services implementations, there is a long, long way to go to improve web services security before you need to start worrying about replay attacks. Some of these improvements include proper schema/DTD validation, data type validation, data size validation, message authentication, authorization and logging.
A good web services development and testing tool called soapUI also serves as a good web services hacking tool. With it, you can take any publicly available WSDL and craft attacks against it. Gunnar’s slides took us through using this tool against Web Goat and made it look very easy.
Other points about Web Services. They were created to run on Port 80 so that they would be allowed through firewalls like regular web traffic. As Bruce Schneier said, “A ‘firewall friendly protocol’ is like a skull friendly bullet”
I’m always glad to have gone to OWASP. I was really grumpy before going yesterday afternoon, but the bike ride over there cleared my head and I managed to cram a few more bits of info in. The meetings are free and open to everyone.