My Journey into a QA Security Mindset: Information disclosure vulnerability
My journey into a QA Security Mindset continues with learning about Information Disclosure vulnerabilities. If you would like to see how this journey started, you can go to my first post here.
I learned about information disclosure by seeing an example of a real bug. It was the exposure of an internal service URL in response to another request, and with this information the attacker was able to get even more information. You want to know how to test for information disclosure? Want to prevent the next bug in your website? Keep reading…
Information disclosure
Also known as information leakage, it happens when a website reveals sensitive information to its users.
Such information can be: Internal URLs, Secret keys, IPs, Database credentials, Directories and their structure. The risk in this vulnerability can be the data itself that is sensitive, or that the information that is exposed can be the base for a more advanced attack.
Add this vulnerability to your test plan
After learning about information disclosure vulnerabilities, my next step was to think of how I can test it using automation. I tried to think of what would be the assertion to identify that an information disclosure bug has been found, and it was quite complicated. If you think about it, the response can contain any of the following: internal URLs, IPs, credentials, directories, and more. So how can you actually find an assertion that will be generic for all of that?
My decision at that point was to add it to my test plan as a manual test case and guide the other quality engineers on what to look for in a response to their services.
Example
The tool that best matches for the manual tests is Burp suite (The Community version is free for downloading).
Burp suite is a tool that is used by security engineers. It acts as the man in the middle between the client and server side, and allows you to interact between HTTP requests before and after they are sent to the server. It has many other capabilities that are less relevant to our topic.
You can use their built-in browser (under Proxy tab -> Intercept -> Open browser), or define one of your browser’s to use Burp suite as a proxy. They provide detailed guidelines on their website, on how to configure your browser.
Let’s take a look at an example of how to use Burp suite. I will use one of the PortSwigger labs (https://portswigger.net/) to show an example of information disclosure.
The lab reveals in an error message that it is using a vulnerable version of a third-party framework.
I found a relevant HTTP request that I want to test in the Proxy -> HTTP History tab.
Then I right click on it, and sent it to the repeater:
The repeater allows me to manipulate the request. First, I resend the request by clicking the Send button, to make sure that it works and that I get a valid response.
This lab should reveal something in an error message. To create an error message, I will try to send a string instead of the integer value in the productId parameter.
The unexpected data type caused an exception, a full stack trace displays and exposes which version the lab is using: Apache Struts 2 2.3.31.
With this information an attacker can look on the internet to find which security vulnerabilities this Apache version has, and perform an attack.
Automating Information Disclosure
While writing this blog post I got to thinking about automating it. I was curious to see what the best practices are for information disclosure testing in the industry, and found out that using scanners/fuzzing is a good approach.
Currently I am working on a project to automate other vulnerabilities, and I am trying to do that with the OWASP ZAP API tool that has the scanning capabilities. This might be my answer for how to automate information disclosure. Once I succeed in implementing it, I will share with you how I did it in my next blog posts.
Thanks for reading. I hope you’ll join me for my upcoming posts, where I plan on writing about:
PART VI: My Journey into a QA Security Mindset: XSS vulnerability
PART VII: My Journey into a QA Security Mindset: SQL Injection
.
.
.
PART X: To be decided
