Software and web application security

January 13, 2007

To fuzz or not to fuzz web services…

Filed under: penetration testing, software security, web apps — chrisweber @ 12:42 pm

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.

  1. Has threat modeling been done or is this my job?
  2. How much time and budget do we have for a security review?
  3. How complex are the web services? e.g. how many parameters do they take and in what format
  4. Are the web services written in managed code?
  5. Is user-input passed to unmanaged code?

Let’s take these answers from a common scenario:

  1. Yes threat modeling is complete
  2. We have about 2 or 3 weeks that you can use to test
  3. Very complex, they use WS-Security, take hundreds of parameters, some encrypted, using custom formats, SOAP, as well as embedded XML blobs
  4. Yes, they’re written in C# using the .NET Framework
  5. 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!

Advertisements

2 Comments »

  1. […] to identify real issues in the software. In this example we’re taking from the last post to fuzz or not to fuzz web services. So we’ve got web services in managed code plus some unmanaged code modules handing […]

    Pingback by How to: Fuzzing Web Services on IIS 6.0 and ASP.NET « Chris Weber — January 14, 2007 @ 2:19 pm

  2. […] to identify real issues in the software. In this example we’re taking from the last post to fuzz or not to fuzz web services. So we’ve got web services in managed code plus some unmanaged code modules handing […]

    Pingback by How to: Fuzzing Web Services on IIS 6.0 and ASP.NET — December 11, 2008 @ 4:11 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: