This is a collation of edited older posts on Fiddler, explaining how I usee it to bypass restrictive proxy settings for tool configuration, remove headers, change browser verbs when accessing pages.
Much of this functionality can be performed by other http proxies, at the time of each of these use cases I was using Fiddler as my default proxy.
Using Fiddler Bypass Restrictive Proxy Settings
One of my use cases for Fiddler, did not stem from a need for debug proxying.
Since I work on a variety of client sites, I periodically have issues with restrictive proxy servers where a .pac file somewhere sets up the browser config, and you have username and password issues etc. etc.
In those circumstances some tools need configuring to use the client site proxy - I tried to use httpgraph based on a suggestion from James Lyndsay.
Like many tools that allow you to configure the proxy httpgraph has a url and port. Nothing else. No http or https config, no usernames, no passwords.
And like many tools, it didn’t work out of the box with a restrictive client side proxy.
I used Fiddler to act as proxy for httpgraph.
Fiddler hooks in to the Windows internet controls seamlessly, it handles all the proxy stuff, including passwords. I then configured httpgraph to use Fiddler as its proxy. This way the tool has a simple proxy server to connect to, where I control the port and protocol config, and as a bonus, I can see the traffic sent.
- Start up fiddler, and
- point your new tool’s proxy to “127.0.0.1:8888”, the Fiddler defaults.
- Use httpgraph, or other tool that was hard to configure
Fiddler has other url configurations if this doesn’t work
Fiddler supports two special case addresses to use instead of localhost
http://ipv4.fiddlerhttp://ipv6.fidder
Removing X-FRAME-OPTIONS header
Some sites issue an X-FRAME-OPTIONS header that stops them loading in an iframe, remove the header to allow some tools to access the site e.g. for responsive web testing with a proxy.
Chances are the server sent an X-FRAME-OPTIONS header in the response e.g.
X-Frame-Options: SAMEORIGIN
or
X-Frame-Options: DENY
All we have to do is call upon our favourite HTTP proxy, and remove the header.
In fiddler, use the FiddlerScript tab and amend the OnBeforeResponse method to include the lines
// remove x-frame-options header from the response
oSession.oResponse.headers.Remove["X-Frame-Options"];
Then when your browser is proxying through Fiddler, your responsive testing tool should not be hampered by the headers.
Changing Browser Verbs - GET to POST
The following contains a true life summary of some recent testing to illustrate the use of Fiddler and some test thinking in action.
I once had cause to examine a Flash application to provide some feedback to the authors.
I normally start such investigations by using Fiddler to examine the communication between the Flash app and the server so as to understand the communication between the two applications. I tend to use Firefox as my browser for this, and put Fiddler into “Force traffic to Fiddler” otherwise Fiddler doesn’t seem to pick up all the communication.
So I use the application for a while with Fiddler running in the background to see what traffic goes back and forward and see what I find interesting.
I like to watch out for calls to different servers, as this often reveals areas of potential vulnerability, because when swapping between servers, sometimes session or authentication information gets passed in the request, and sometimes you have access to new functionality without authentication.
In this instance I saw calls to a different server so I took the URL from fiddler with the “copy > just URL” function and went directly to this in another browser window to see what I could see.
Since the URL led to a cgi app, I amended the URL to see what the page at the root of the server would tell me.
I did not expect to see a default page with link to the admin functionality, but such things can happen when you build on open-source frameworks – one reason why, as a tester, you need to know and learn about the technologies and frameworks that underpin the application.
So I passed this information on to the developers so they could mitigate this risk.
… time passed…
Later I visited the URL to the admin page and found that a password prompt popped up to stop me. So I had a quick look at the application again to see how the traffic between the flash application and the server had changed to see how the application bypassed the security mechanism:
- perhaps I would see something obvious like a password in the URL,
- or perhaps the application used a new set of URLs now.
Nope, same URLs, but this time it POSTed information instead of GETting information.
So in Fiddler I constructed a POST to the admin URL and lo and behold I could see the admin pages again.
In order to assess the impact of this I really wanted a way to browse the admin areas using a normal browser in ‘POST mode’, to see if I could still use the site easily, so I had to find a way to surf the site with POSTs instead of GETs.
I first looked for a browser extension to convert all GETs into POSTs but I could not find one.
And then I realised that I could probably do that with a customised rule in Fiddler.
So, should you ever want to surf the web using POSTs instead of GETs, you need to amend your “function OnBeforeRequest(oSession: Session)” rules to include lines such as:
if (oSession.HostnameIs(””) && oSession.HTTPMethodIs(“GET”)) {
oSession.oRequest.headers.HTTPMethod = “POST”;
}
I could then ‘surf’ the password protected areas of the site with ease by POSTing my requests instead of GETting them, and I could see all the results in a real browser, instead of just the Fiddler inspector windows.
So, queue another sending of information to the developer to mitigate the risk.
Summary:
- to identify some of the thought processes I use when Web Testing:
- explore the site and build a model of the server side communication
- watch for other servers in use in the transaction to identify possible risks for exploitation
- amend the URLs used in the communication and explore other parts of the server
- learn the underpinning frameworks
- build theories of possible implementation approaches and then investigate them
- find or make tools to help me explore risks further
- you can surf with POSTs instead of GETs
