Scary Web Services: Part 1

I have several things I want to say about web services but for this post I am going to constrain myself to explaining why web services are scary to me in the role of a pen tester. In this context, web services can really mean any type of web service but typically refers to those found on internal networks, which are often SOAP-based. I have spoken to a number of colleagues on this topic in recent months and they have pretty much unanimously agreed that testing a web service is usually a fair bit “scarier” then testing a “normal” web application. Let’s be clear: by “scary” I mean not “frightening”, but rather challenging in the sense that they may contain vulnerabilities that are extremely hard to find.

So what makes web services so scary? For starters, the architecture is usually more complex than “normal” web apps. There is a web service contract or schema acting as a layer of abstraction between the producer and consumers of that web service. Just think about it: one of the main purposes for building web services is to allow disparate technologies to communicate with each other in a common language. That language is different for each web service because it is defined by the functions available in the web service. I know, I know: what about the WSDL? Have you tried to decipher a WSDL lately for a complex web app? That alone is a scary exercise and still doesn’t tell you what technology is on the other end of the connection. The producer side (server side) of a web service can be doing just about anything. It could be simply performing some computations, or interfacing with a database or LDAP directory, or interfacing with a mainframe, or even talking to other web services. As a tester, we often don’t know what’s behind the web service – or if we are told ahead of time, it is often in somewhat vague terms.

Web services often model business functions. These are things that make sense within the context of the applications that interface with the web services. Often these are somewhat obvious to anyone who is paying attention, for example a function that is named “getCustomerRecord” is pretty self-evident. Automated scanning tools on the other hand often don’t know what to do with them. Some will attempt the usual injection payloads such as SQL Injection and XSS but are naturally not very good at selecting good insertion points or understanding the results and whether or not they can even be used. Add to that the aforementioned abstraction makes it extremely difficult for an automated tool to fingerprint anything past the web service framework itself. In a nutshell, automated testing tools are not very good at understanding business logic so the pen tester will often be stuck doing some manual heavy lifting or script customization.

Lastly, many modern web service frameworks come equipped with fairly strict data format policies through their schema definitions. Development teams who actually take advantage of these features (many do), are providing a level of strict data validation that is rare in “normal” web applications. The important thing to note is that server-side schema checking usually makes injection attacks much more difficult to execute. Since injection attacks make up the bulk of attack types, enforced schemas can cut down the likelihood and severity of security vulnerabilities considerably.

So there you have it. Web services are scary to pen testers because we often don’t really know what’s behind them, their affinity for business logic makes it hard to test them reliably through automated means, and built in features such as schema checking can do a decent job of mitigating many types of attacks. Please leave a comment if you feel there are other factors that make make web services challenging. My next post on web services will provide a contrasting view describing why web services are scary for those who build and host them.