Shielding Web services from attack

That means the biggest defense comes from ensuring code works as expected, preferably before it’s ever exposed to the Net. Although plenty of coders use blacklists to prevent well-known types of malicious routines from being executed, the more prudent approach is to employ whitelists so, for example, a field that asks for a Social Security number will accept only a positive value that has nine digits.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

“The Web service needs to defend itself, and to do that it needs to do things that we’ve been telling people to do since the beginning of time,” Allan says.

Allen Brokken, security analyst at the University of Missouri, has been using SPI Dynamics’ WebInspect, which scans Web services and other online applications for vulnerabilities. The tool generates detailed reports that include the exact form fields or parameters that have problems. “For us, the best part of it is it gives clear guidance on how to solve the problem,” Brokken says.

Security professionals should also take careful inventory of every service that’s exposed to the Internet, preferably though an audit carried out by someone external to the IT department. That approach can be particularly effective in identifying services left behind by a previous generation of developers who have since moved on.

Whether the services are already in place or not yet deployed, each one needs to be thoroughly tested using a variety of methods. One is to scan every port of every IP address and carefully query each service that responds, looking to see whether UDDI servers, WSDLs, Disco files, and/or other self-describing mechanisms are giving up information that could aid an attacker. (Manual inspection of WSDLs is also a must, paying close attention to whether they are divulging debugging information or other internal secrets.) The Web services also need to be fuzzed to see, for example, how an application expecting a SOAP array with a length of three elements will react when it gets a length of four.

Security professionals should also think about deploying a Web services gateway, which analyzes XML input for malicious payloads before sending it to the appropriate back-end service. There’s much debate about whether the devices are effective. Verizon Business’ Parker argues that the additional complexity they introduce can actually make an enterprise more vulnerable. But many others — including Alvi of Sun, which resells Web services gateways from companies such as Forum Systems and Reactivity — say the devices can provide an important layer of protection.

Ultimately, security experts say, the security of Web services depends on an increased awareness of the developers who create them, and that will require a major shift in thinking. Billy Hoffman, lead researcher at SPI Dynamics, says a trip to Barnes and Noble exposes the short shrift secure code gets in the majority of mainstream Web services programming books.

“None of them talk about security,” Hoffman says. “The examples they give are bad. You get a lot of developers who don’t know where to get good information about security. We’re just starting to fix it.”