Is it worth the time to run input fuzzing tests against web services? When engaging a client for a security review I’m often the one to pose this question. Sure, why not… right? Well honestly there’s a more precise way to answer this question. First we really need to understand the goals of the security review, so a few questions are in order.
- Has threat modeling been done or is this my job?
- How much time and budget do we have for a security review?
- How complex are the web services? e.g. how many parameters do they take and in what format
- Are the web services written in managed code?
- Is user-input passed to unmanaged code?
Let’s take these answers from a common scenario:
- Yes threat modeling is complete
- We have about 2 or 3 weeks that you can use to test
- Very complex, they use WS-Security, take hundreds of parameters, some encrypted, using custom formats, SOAP, as well as embedded XML blobs
- Yes, they’re written in C# using the .NET Framework
- Some specific elements of user-input are handled by unmanaged code modules
Some things not obvious in these questions are:
- that the client is highly interested in finding Denial of Service (DoS) issues
- that millions of people will be using these Web Services whether they know it or not
- that no input fuzzing has been done to date
With 2-3 weeks we could get a lot done in a security review focused just one the web services. It’s becoming clear that fuzzing input would be a worthwhile venture. We’ll likely turn up some DoS issues, possibly some unmanaged code issues as well. Since we have a decent timeframe, we’ll be checking for the following issues, not all of which fuzzing is good for:
- elevation of privilege (EoP)
- repurposing attacks
- cross-site scripting (yes, even web services in some cases)
- information disclosure
- session replay
- SQL Injection
- DTD attacks
- XML validation
- script injection
- repudiation
- denial of service
- buffer overrun
Fuzzing will help with some of these, so at this point the answer is yes, let’s do it. We’ll also be doing some code review, which is great for identifying issues such as DoS, XML validation, and DTD attacks quickly. And we’ll be studying the specs and architecture along the way to keep a clear understanding of the system and help identify repurposing attacks, which will be tested for confirmation.
Ok let’s go!
