I’ve written about the Scotch library previously, but I have scenarios where I cannot intercept HTTP requests directly within my code. i.e. SOAP generated client code handles this for us.

So what we want to do is use Fiddler initially to intercept responses for our service calls, save these and then replay them offline.

Fiddler comes with a great feature which allows us to intercept calls and automatically respond with previously saved data call AutoResponder.

Just select the AutoResponder tab in Fiddler.

All we need to do now, is add a rule, here we can create rules for specific URL patterns, i.e. just intercept some calls or all URLs. We can then assign a file (likely our previously saved intercept response files) and now we have Fiddler acts as the service by responding to requests with our locally saved files.

Don’t forget to “Enable rules” when you’ve saved all your rules and you probably want “Unmatched requests passthrough” also checked to allow other HTTP requests to pass through the rules.

If you’re using a .NET client application, remember you’ll need the following within your App.config,

<system.net>
   <defaultProxy>
      <proxy bypassonlocal="false" usesystemdefault="true" />
   </defaultProxy>
</system.net>

Here’s an example of a simple bit of .NET code that can be used to check everything is working, just add autoresponder rules for the URL myurl/test

var client = new HttpClient();
var r = client.GetStringAsync(new Uri(
   "http://myurl/test")).Result;

References

AutoResponder Reference

A while back I wrote a post on Intercepting and creating SOAP messages using Fiddler.

I’ve just had to revisit this post to debug changes in a SOAP implementation which seemed to be causing unexplained failures.

So I started up the servers (running in Java) and configured my .NET client as per the previously mentioned post, but for completeness, let’s show the App.config changes here anyway

<system.net>
   <defaultProxy>
    <proxy bypassonlocal="false" usesystemdefault="true" />
   </defaultProxy>
</system.net>  

I then ran Fiddler v4.5.x.x and then the .NET application. Fiddler showed no traffic.

Fiddler and localhost from a .NET application

Hunting around, I found several possible solutions, for intercepting IE or another browser, changing localhost to localhost. was one suggestion as well as adding the Fiddler proxy in some other way, but as per Problem: Traffic sent to http://localhost or http://127.0.0.1 is not captured, simply changing localhost in your application to the machine’s name worked and now I could intercept localhost messages.

The title of this post is specific to a requirement I have which is part of a security audit which requires that I test the role based security on some of our servers.

I need to intercept SOAP messages from one of the .NET client applications I maintain and then change data within the message to try to impersonate other users to see whether the server code correctly allows/disallows user access via it’s role based security.

Obviously, if you know Fiddler (now from Telerik) you’ll know that we can intercept any network traffic between the machine we’re using and some server – we’re just going to touch on some of the very basics of using Fiddler.

Setting things up

So continuing down the path of the requirements I have. The first thing I need to do (prior to starting the client application) is to run Fiddler. I’m currently using Fiddler 4.4.9.9.

You may notice calls to the web or the likes over HTTP in the left hand pane of Fiddler. This is where we’ll see individual calls to our server(s). But before we can run our client application we need to ensure it uses Fiddler – so in my case I need to add/change the system.net section of the .NET application configuration file to look like the following

<system.net>
   <defaultProxy>
      <proxy bypassonlocal="false" usesystemdefault="true" />
   </defaultProxy>
</system.net> 

Now the client will use Fiddler as the proxy.

See Configure .NET Applications for more information of this subject

Okay, at this point we can run our .NET client and we should start seeing calls to any servers appearing within the left hand pane of Fiddler (obviously when they’re made via the client).

Once the application started I used Fiddler’s “Any process” button (a gun sight style icon on the toolbar) to select the .NET application so to reduce the traffic I would see in Fiddler.

Capturing a message

We’re not going to dive too deep into Fiddler for this post, but instead we’ll just look at how to use Fiddler to carry out the specifics of the requirements outlined at the start of this post.

Next up we’re going to make the client application do some task – in my case we’re using a read/write role so I can get a message that is valid for a user with these permissions.

So now I run the functionality on the client which will result in a server call and generate the SOAP message I want to capture. It should appear in the left hand pane of Fiddler. If we double click on the specific entry on the left hand pane the right hand pane of Fiddler will show us the Inspectors view. From here we can look at the SOAP message using various viewers.

Now switch to the RAW view of the bottom part of the Inspectors pane and press the View in Notepad. At this point I delete the HTTP header and am left with the raw message (in my case starting with <?xml to the end of the document).

Okay, we’ve captured the SOAP message, the next step is to change information within the SOAP message to impersonate a lower permission user. Obviously this depends on how you might pass the data for such user information, whether it’s within the header or envelope. Whether such information is plain text of encrypted.

Creating (or composing) a message

We’ve captured an existing message and changes the user details within the message. Now we’re going to use Fiddler to send the message to the server.

Select the Composer tab in the right hand pane of Fiddler. In my case I need to set the message to be a POST and I supply the full URL.

The top pane of this composer view will update with any response from the server and be default has the User-Agent set to Fiddler (obviously you can change this to suit).

In the request body we copy our previously captured and altered SOAP message and paste it into the request body section. Now simply press the Execute button at the top right of the Composer view and your request should be sent to the specified URL.

Obviously I had a very specific requirement for using Fiddler but ofcourse you might use it to simply capture various messages in whatever format you use and replaying them as part of a test suite or the likes.