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.