Sorry

Web services are almost irresistible. Every popular IDE makes them easy to build — to unlock the data and business logic in legacy systems, to provision common functions that can be shared across multiple platforms, or to provide partner organizations direct access to information or applications. And by their nature, Web services helpfully describe themselves, allowing one system to find and interact with another with little or no human intervention.

Yet the very virtues that make Web services compelling — their use of trusted ports and protocols, their ease in exposing back-end systems, their eagerness to describe exactly what services are offered and how to get at them, and their use of multiple intermediaries — also make them a potential windfall for criminals crossing an enterprise’s perimeter (see also "Web services security standards aren't enough").

“You’re taking all of these systems that you would never put on the Internet — you would never hook your mainframe up to a DSL line — but now you’re exposing all their functionality through a Web service, and if you’re not thinking about security when you do that, you’re also exposing all those vulnerabilities,” says Alex Stamos, principal partner at iSec Partners, a security consulting company.

Few organizations have fully grasped the situation, in part because Web services technology is still relatively new. Even enterprises that are implementing an SOA (service-oriented architecture) — which provides a framework for building, running, and managing services — seldom recognize the new security risks. Ultimately, the recognition that we need to tackle Web services’ vulnerabilities is part of a growing awareness that security must be addressed in the code of applications, not just through firewalls and gateways.

Click for larger view.The limits of trust

Topping the long list of excuses for not locking down Web services is the mistaken belief that the applications they expose are known only to internal personnel or trusted partners, rather than the world at large.

For instance, a Web app developer at a bank that provides online credit card processing may assume the SOAP interface he just implemented is invisible to all but the handful of customers who received his instructions on how the new service works.

“That’s not true,” says iSec’s Stamos, who has come up with a simple white-hat hacking tool he says is remarkably good at identifying the Web services that lurk behind IP addresses and figuring out how to use them without authorization. “In fact, they all have these systems built in to Web services to advertise their presence, and people don’t understand how pervasive those systems are,” he says. Stamos estimates that as many as 400 of the Fortune 500 companies have at least one b-to-b Web service. “Almost none of them are going to be completely secure,” he warns.

Another common reason for vulnerabilities is the belief that security is the other guy’s responsibility, says Paul Henry, vice president of technology evangelism at Secure Computing, which provides gateway devices to help secure Web services. “Unfortunately, you’ll have a team that’s working on the front-end software, and a separate team on the back end,” he explains. “Both assume the other has taken care of security.” What’s more, enterprises tend to design Web service applications from scratch rather than buying them from vendors that have put them through rigorous testing.

Then there’s the multi-hop problem. Web services frequently pass messages through several intermediaries before they reach their final destination, undercutting technologies such as SSL, which secures connections only across the open Internet.

“The idea that you don’t know where your message is going to go actually causes a lot of issues with Web services,” says Rafat Alvi, senior architect in the office of the CTO at Sun Microsystems.

The verbosity of Web services, which are designed to be self-describing and self-discovering, also presents a problem for security professionals, says Danny Allan, director of security research at Watchfire, a provider of Web application security assessment products. “Web services notoriously give way more information in them than is typically expected,” he says.

Giving away the keys

The difficulty of securing Web services — and the inattention paid to its importance — can make seemingly hardened enterprises vulnerable to some of the oldest tricks in the security book.

A high percentage of Web services interact with databases. SOAP and XML make it easy to disguise malicious payloads, opening new avenues for buffer-overflow attacks, SQL-injection exploits, and other misdeeds targeting an enterprise’s most vital systems. Compounding matters, some of the machines exposed using Web services are legacy systems — old Windows NT boxes, for example — that are much more susceptible to attack than newer systems.

“The same issues we have been dealing with for the last five years can all be manifested through these new technologies,” says Tom Parker, senior manager in the professional security service group at Verizon Business.

Click for larger view.

Meanwhile, new classes of exploits targeting Web services have been developed. They include SOAP array overflows, a new variation on buffer-overflow intrusions in which an attacker sends an XML request with an array length that exceeds what has been specified. Like conventional buffer overflows and SQL injections, SOAP array attacks are among the most serious because they can expose confidential data or allow code execution on an organization’s back end.

Other common Web service exploits include XML parser attacks, in which an infinite string leads to a denial of service, and XML external entity attacks, in which a request points to an invalid file, resulting in an error that may cause the Web service to give out information it shouldn’t disclose.

Defensive measures

Although Web services raise risks, organizations that open XML channels need not fall victim to security breaches if they take proactive measures.

The obsolescence of perimeter security is hardly new, but the notion gains greater relevance in the world of Web services. “When people think, ‘Where does my security happen, where is my edge?’ — the edge has gone all fuzzy now,” iSec’s Stamos says. “Now the edge of your network is on this Web service system, but it’s also on this mainframe, and it’s also on this database, and it’s also on all these things that people can now indirectly access through a big, federated Web service that you’ve set up.”

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.

“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.”