Introduction:

Discovering sensitive information disclosure in cybersecurity can have serious consequences for users and organizations. During a recent penetration test, I uncovered a significant vulnerability in a web application that exposed user information. This post will walk you through the details of my findings, the steps I took to investigate the severity of the issue, and the broader security implications.

The Discovery:

During a routine penetration test for a client, I discovered that the application used a combination of email, phone number, and DOB for its login functionality. Upon closer inspection, I found that these parameters were being passed in the URL. This in itself raised a red flag because sensitive information should never be transmitted in the URL due to the risk of exposure in server logs, browser history, and third-party monitoring tools.

How It Happened:

Here’s how the issue was identified. (I am using a lab environment to demonstrate the issue, as I cannot reveal the client's information publicly.)

1. Login Functionality: The application requires an email, phone number, and DOB to authenticate.

   

2. URL Parameters: These credentials were passed as parameters in the URL, like so:

    http://offensivebytes.local:3000/login?email=test%40test.com&mobile=1234567890&dob=2000-01-01
   

   

   

3. Understanding that this application had likely been in production for a considerable amount of time, I decided to check if any of these URLs had been logged or archived by external services like archive.org and Google.

4. I quickly navigated to archive.org and began searching for the application's URLs. To my alarm, I found that several URLs containing user data had been archived. This meant that sensitive information, including email addresses, phone numbers, and DOB was publicly accessible and had been for an unknown period.

   

The Impact:

In total, I found personally identifiable information (PII) of over 5000+ customers. This type of data exposure can have serious implications, including:

• Identity Theft: Malicious actors could use the leaked information to impersonate users or commit fraud.

• Phishing Attacks: Leaked email addresses could be targeted for phishing campaigns, compromising further personal and financial information.

• Reputation Damage: The organization responsible for the application could suffer significant reputational damage and potential legal repercussions.

The Common Approach:

Most security professionals would report this issue to the client as it stands, highlighting the severity based on the exposure of sensitive information. This is a valid approach and highlights the immediate risk to the client.

Going the Extra Mile:

However, I chose to dig deeper to underscore the full extent of the vulnerability and its potential impact. By demonstrating that the data had already been archived and was accessible to anyone with basic search skills, I was able to provide concrete evidence of the exposure. This approach not only validates the finding but also helps the client understand the urgency and necessity of addressing the issue promptly.

Remediation

To remediate this vulnerability, the following steps are recommended:

• Stop Passing Sensitive Data in URLs: Refactor the application to ensure that sensitive information is not transmitted via URL parameters. Use POST requests with appropriate encryption for transmitting such data.

• Use Tokens: Implement session tokens or cookies for user authentication, reducing the need to pass sensitive information in URLs.

• Request Removal fromarchive.org: Contact archive.org to request the removal of the archived URLs containing sensitive information.

• User Notification: Notify affected users about the potential exposure and advise them to monitor their accounts for any suspicious activity.