In-Depth

Guarding Against Your Partner's Web Services Flaws

Coding errors in Web Services code at your partners can trigger problems on your own systems.

• By Mathew Schwartz
• 01/28/2004

Creating pristine code and predicting every potential kind of attack is vital, but it's practically impossible. Solid applications run on less-than-solid operating systems for which no one can keep all of the holes patched. Yet there's still room for improvement, especially as the Web Services movement interconnects ever-wider groups of servers. One potential threat: a small coding error at your partner’s site lets an attacker work his way up the channel to compromise your environment.

How can your company protect itself? One option is to scrub security flaws when code is still in development and not force quality assurance or security managers to spot security flaws, then cajole developers to fix them long after the code base is near-final.

To understand how to accomplish that, Security Strategies spoke with Caleb Sima, chief technology officer and founder of SPI Dynamics, which makes WebInspect, an automated inspection tool for Web Application security vulnerabilities.

How advanced is Web Services security?

Today, when people talk about security and Web Services, they talk about encryption, authentication, and access control. These are the big deals when people are dealing with Web Services. [While] those things are important, what about the developer … of Web Services applications? Web Services, at the developer level, is also the beginning of the security cycle.

Historically, however, from the very beginning when the Web first came out, security wasn't a concern, it was about making it look nice, making it work. And we've found a lot of companies that [still] haven't secured their Web applications. Sometimes we find custom vulnerabilities that [leave a company’s] Web Services wide open, because they thought the only thing that would connect to the enterprise application would be internal. Those developers weren’t thinking about something like Web Services.

What’s a common Web Services vulnerability?

SQL injections at the Web Services level. [They’re tricky;] even if a developer is accepting SQL queries, what if I … insert a query into that request? The Web Service can return results to me the developer wouldn’t expect to occur, or crash. Or [say] I return 5,000 characters instead of the expected 50? What happens?

Web Services is just at the beginning [of its life]. There aren't a lot of vulnerabilities out there that have been published, but as Web Services grows, they will appear.

How does your tool help mitigate that risk?

It's a software tool, you install it on your laptop or machine, and you point it at the Web Service and it will … find the vulnerabilities for you. It runs on Windows.

Would such a tool ideally be used from day one of the development cycle?

Oh, yes. We talk about how the product is used not only in developer but also product testing and quality assurance (QA). In development, especially because it's [still a nascent area], scan with it constantly to make sure it's okay, then QA can [also] scan to make sure.

Is it difficult to integrate yet another tool and process into the development cycle?

The developers especially have a hesitancy to incorporate something [new]. But what we found was, our tool was originally built for security people and … they couldn't fix the vulnerabilities [they found]; they had to take them back to the developers to fix. So as the developers have started learning about security, we've actually seen implementation [get] easier. Because with developers, it's not about telling them they have a bug in their code, it's saying hey, did you know a hacker could get access through your code? It's sort of like revealing a magic trick to a developer.

The interconnected nature of Web Services also magnifies any developer errors.

From a security perspective, if [a company] gets hacked, and then I [as a Web Services subscriber] go to that site, pull down some information and present it to a viewer, well now it looks like my site was hacked. Or what if that subscriber and a financial company, and the attacker tries to get into my site?

How can companies subscribing to Web Services from others protect themselves?

What you need is certification. If I'm going to use [a company’s Web Services offering] in my application, you want to know if one, it’s realizable, two, it can be trusted to interoperate with my Web Service, and three, it’s secure.

Who would certify such a thing?

I don't know, there's nothing out there right now that does that. The reason why is Web Services is still in its infancy; it hasn't gotten there yet. But we need it.