Security Testing with Fiddler Everywhere
Security threats are growing rapidly and are persistent. Hence the need for security testing can no longer be ignored. Security Testing reveals the vulnerabilities of a system and finds out the possible weaknesses which might result in losing data or reputation.
OWASP provides the top 10 most critical web application security risks of the year since 2003. These risks are ranked on the frequency, severity, and magnitude of their potential impact. This list offers web developers and security professionals insights into the most predominant security risks. These insights will allow them to find solutions to minimize the known risks in their applications.
Some software testers assume security testing is a very complex task left only to the security test professionals. The glossary used by the security test experts makes the subject look scarier.
But when I started learning about security testing, I found that though there is a lot to learn, it is not hard to get started. There are so many free tools to try out security testing and I chose Fiddler Everywhere. And in this article, I discuss how to assess some of the most common security vulnerabilities using Fiddler Everywhere.
First, download and install Fiddler Everywhere by Telerik. Then log in to Fiddler with a preferred account.
Configuration
- Since Fiddler is capturing all the outgoing network calls, we need to apply a filter to capture the required HTTP/HTTPS traffic. To do that, click on the filter icon and let the filter window open.
2) Then configure the request header that you need to capture in the filter window.
This information can be taken from the Network tab after loading your web application’s URL in the browser.
3) Then reload your web application in the browser.
Once it starts to run, Fiddler will start capturing the API calls.
4) When a particular call is selected, Fiddler will show request information and the response in the right-side grids.
5) By default HTTPS calls can not be decoded by Fiddler. To do that you have to add the Fiddler root certificate into the operating system.
You can do that easily by clicking the ‘Trust’ button in Fiddler setting window and checking the ‘Capture HTTPS traffic’ option.
Security tests
1: Parameter tampering
In Parameter Tampering, manipulated parameters are exchanged between client and server in order 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,
1) Select a captured API call
2) Right-click → Select ‘Edit in Composer’
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.
“product_id”: 13747
“variant_merchant_id”: 30867
That means product 13747 is only sold by merchant 30867. No other merchant sells product 13747.
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 allows people to access secure data without forcing them to log in first. To test this,
1) While Fiddler is running, log in to the application, perform some actions that require a user to be logged in, then log off.
2) Select an API call from the Fiddler, which requires a user to log in, right-click, and select Replay.
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 in to the application, as a user (User A) who has access permission for a particular module. ex: Admin user
Then log out.
2) Login with a regular user (User B) who does not have access permission for the particular module in the application.
3) From Fiddler, select the API call related to User A and open it in the composer.
4) Now go to the Live traffic tab and pick User B’s most recent request with an ‘Authorization key’.
5)Copy the User B’s Authorization key’ from the inspector tab.
6) Replace the User B’s Authorization key’ in the Composer request of User A’s. Click on the tick icon.
7) Execute the doctored request from the Composer.
8) If you get a successful response body, it means the application is vulnerable to Function Level Access Control. If you get an unsuccessful response, the selected API request is immune to Function Level Access Control.
Kudos! With these security tests, you have covered some of the common security vulnerabilities which you might have assumed too difficult before you read this article. Happy testing!
