Fiddler Classic for security testing.
Identifying security vulnerabilities of web applications is vital to avoid loss of customer trust, website downtime, and securing web applications against future attacks. Web security testing tools are useful in proactively detecting these vulnerabilities and securing websites against attacks. In my last article, I described how to access three of the most common security vulnerabilities using Fiddler Everywhere, which used to be an open-source tool. Since Telerik decided to make it a commercial tool, I am writing this article to explain how the same vulnerabilities can be accessed by Fidler classic, which has been a free tool since its launch.
You can download Fiddler Classic by Telerik from their official website. And then install it.
a) To start with, close down all the applications that communicate with the network except one tab for a specific browser. Then launch Fiddler.
b) For Fiddler to decrypt the HTTPS session, its root certification should be trusted. This is done to provide an SSL proxy so that unencrypted traffic is also captured.
To do this, go to Tools and select Options.
And select the HTTPS tab. Select the checkboxes for ‘Capture HTTPS CONNECTS’ and ‘Decrypt HTTPS traffic. Then click on the Actions button and select ‘Trust Root Certificate’.
c) Then the request header that you need to capture has to be configured in the filter window. This information can be taken from the Network tab after loading your web application’s URL in the browser.
Go to the Filters tab in Fidler and enable filtering. From the ‘Hosts’ dropdown option select ‘Show only the following hosts’ and give the hostname to the text field.
Then run the web application in the browser. Once it starts to run, Fiddler will start capturing the API calls.
d) Pick one of the requests, then take a look at the Inspectors tab. Fiddler will show the request information and the Response in the right-side grids.
1: Parameter Tampering
In Parameter Tampering, manipulated parameters are exchanged between client and server to modify application data, such as user credentials, permissions, quantity, etc.
The Composer tab in Fiddler allows editing requests by changing the values of form fields or query strings. To test this,
- In Fiddler go to the Composer tab
- Select a captured API call and drag it over to the Composer tab. The raw text of the request will be filled in.
3) Then in the request body, change the form field values.
Since we are testing the security aspects, be mindful to choose form fields that are important concerning security.
Here in this example, product_id and variant_merchant_id are chosen to be edited because this pair can not have any other values.
That means product 23144 is only sold by merchant 55190. No other merchant sells product 23144.
4). After setting a different value to “variant_merchant_id” the call is executed again by clicking on the execute button.
And a successful response body is received and the same item was added to the cart with the tampered variant_merchant_id, which means the selected API request is vulnerable to Parameter Tampering.
If you get an unsuccessful response, the selected API request is immune to Parameter Tampering.
To avoid Parameter Tampering, the applications must always validate the incoming parameters.
2: Broken Authentication and Session Management
This vulnerability happens when the application lets people access secure data without forcing them to log on first.
To test this,
1) While Fiddler is running, log on to the application, do something there that requires a user to be logged on, then log off.
2) Select an API call from the Fiddler, where login should be required, right-click, and select Replay and then Reissue Unconditionally (Unconditional Reissue will replay the request without first checking whether anything has changed on the server).
3) If you get a successful response body, it means the application is vulnerable to Broken Authentication and Session Management. If you get an unsuccessful response, the application is immune to Broken Authentication and Session Management.
3. Missing Function Level Access Control
This vulnerability is about letting the browser decide what form fields to show, hide, or make read-only based on the level of access, and not doing the same set of checks when making changes.
To test this,
1) While Fiddler is running, log on to the application, as a user (User A) who has access permission for a particular module.
Then log out. Fiddler will record the session information.
2) Login with a regular user (User B) who has not access permission for the particular module in the application.
3) From Fiddler, select the API call related to User A and drag it to the Composer tab.
4) Now go to the Inspector tab and Auth and pick User B’s (regular user’s) most recent request with an ‘Authorization key’.
5) Copy the User B’s Authorization key’.
6) Replace the User B’s Authorization key’ in the Composer request of User A’s.
7) Execute the doctored request from the Composer.
If you get a successful response body, it means the application is vulnerable for Function Level Access Control. If you get an unsuccessful response, the selected API request is immune for Function Level Access Control.
Fiddler Classic vs Fidler Everywhere
Fiddler Classic is not appealing to the users due to its cluttered complicated UI. And the tool is not straightforwardly accessible by macOS and Linux developers, whereas Fiddler Everywhere is a more attentive application of Fiddler which provides access to the most treasured features of Fiddler Classic. And it fiddles across all platforms including macOS, Linux, and Windows.
Fiddler Classic is a tool with a lot of features that it has implemented over its lifespan. And not all of them are in Fiddler Everywhere and it is highly doubtable will all of them ever be in Fiddler Everywhere. Fiddler Everywhere has significant usability improvements but it is becoming a paid tool in the near future whereas Fiddler Classic has been a free tool for its all past 15 years.