"Extensible Markup Language (XML), Web services, and service-oriented architecture (SOA) are the latest craze in the software development world. These buzzwords burn particularly bright in large enterprises with hundreds or thousands of systems that were developed independently. If these disparate systems can be made to work together using open standards, a tremendous amount of time, money, and frustration can be saved. Whether or not we are on the verge of a new era in software, the goal alone is enough to make security people cringe. It might be easy to glue System A and System B together, but will the combination be secure?
Today, most discussions about Web services security focus on standards: from WS-Security and SAML down to SOAP and even XML. While the standards are important, measuring the security of a Web service requires looking past the standards and considering all of the ways the system might fail. Attackers focus on a system's weak points, and a security assessment should do the same. Consider the following:
- Complex protocols might seem bloated or redundant. Skipping or changing steps might not create any problems for normal operation, but it could but jeopardize the security guarantees the protocol offers.
- Application platforms that support Web services are incredibly flexible. In practice, that means they have incredibly complex configurations. Mistakes in these configuration files become vulnerabilities in the service.
- Services are often built on top of legacy software that was not originally designed to operate as a service. Vulnerable code that's never been exposed to the network before offers attackers new opportunities."
"Most people know better than to make up their own cryptography, but a surprising number of programmers are still willing to try their hand at a home-brewed authentication protocol. Last month Google found out just what a bad idea that is. The single sign-on protocol they used for Google Applications was derived from SAML, but it left out a few seemingly unnecessary pieces of information from two protocol messages. The result was a severe security flaw that allowed a dishonest service provider to impersonate a user at another service provider. The moral to this story is if you adopt a standard, don't stop at "good enough." Subtle vulnerabilities creep in where standards compliance falls off.
Web service containers such as WebSphere, WebLogic, or .NET WSE are amazingly versatile when it comes to Web services support, but what at first might seem a blessing quickly turns into a nightmare for the people who have to configure these systems. People stitch together configurations from sample projects or flail until somehow their service starts working. The result is service configurations that don't do exactly what the author intended." - TechTarget