How a Simple Profile Setting Revealed Sensitive Credentials in a Bug Bounty Program

Sometimes the most interesting security findings are not discovered in complex authentication flows or advanced exploitation techniques. Sometimes, they are hidden behind simple features that users interact with every day.

During a private bug bounty engagement on an e-commerce application, I was testing different profile functionalities and monitoring the application's behavior using Burp Suite.

At first, everything looked normal. Updating profile information did not reveal anything unusual. However, while exploring additional account settings, I noticed a feature that caught my attention: Preferred Contact Method.

This small feature led me to discover a sensitive issue related to how the application handled authentication data.

Discovery

My testing started with a simple approach: changing profile information and analyzing the generated HTTP requests.

I first tested the username update functionality and monitored the traffic through Burp Suite. The requests appeared normal, and I did not find any interesting behavior.

Instead of stopping there, I continued exploring other profile options.

One of the available settings was:

• Email
• SMS/MMS/Apps
• Telephone
• Mail

I changed the preferred contact method to Email and intercepted the related request flow.

While reviewing the traffic, I noticed something unexpected.

A request related to a profile update action was containing sensitive authentication information that should not have been included in this type of operation.

Technical Details

The application was sending username and password values during a profile-related request.

An example of the exposed data format:

username=<test@gmail.com>
password=<test@gmail.com>

username=<test@gmail.com>
password=<test@gmail.com>

This was unexpected because updating profile preferences does not require sending the user's password as part of the request.

The issue indicates improper handling of authentication data, where sensitive credentials are exposed during unrelated application functionality.

Authentication credentials should only be handled through secure authentication mechanisms and should never be unnecessarily included in normal application workflows.

Proof of Concept

The issue can be reproduced using the following steps:

1. Log in to an account.
2. Open the profile settings page.
3. Configure Burp Suite to intercept HTTP traffic.
4. Change the Preferred Contact Method to Email.
5. Save the changes.
6. Review the intercepted request.
7. Observe that sensitive credential values are included in the request.

For validation purposes, the exposed credentials were tested in a separate authentication session, confirming that they were valid.

Impact

Exposing valid authentication credentials creates a significant security risk.

Potential impacts include:

• Unauthorized access if credentials are exposed to an attacker.
• Account compromise if valid credentials are obtained.
• Exposure of sensitive user information.
• Increased risk to users who reuse credentials across multiple services.

For an e-commerce platform, account compromise may expose sensitive account information such as personal details, order history, and other stored account data.

Remediation

To prevent this issue, the application should:

• Never send passwords in profile update requests.
• Remove unnecessary sensitive fields from client-side requests.
• Use secure session-based authentication instead of transmitting credentials.
• Review frontend logic to ensure sensitive values are not stored or reused unnecessarily.

Happy hunting :

• Perform security reviews of all account management workflows.