E-commerce website vulnerability bounty practice sharing（II）

By Injamam

Hello everyone, do you remember the content we shared last time? In the previous article, we discussed a case involving a pre-authentication takeover vulnerability and an API security vulnerability (related to product information leakage) in an e-commerce website. Today, we will continue to share two more vulnerability cases discovered by researcher Injamam. We hope these examples will be enlightening for you.

Review of the previous chapter: E-commerce website vulnerability bounty practice sharing: Pre-Authentication takeover, API security vulnerabilities And Directory Brute Forcing（I）

3.3.1 Background of the Vulnerability

One day, redacted.com launched a new feature, and new features often mean potential new vulnerabilities, which made me excited. This feature was a social interaction function, similar to those on social media websites. It allowed users to post images, comment on posts, and create polls for voting.

3.3.2 Attack scenario

As there was a comment functionality, my first tests focused on common vulnerabilities such as HTML injection and cross-site scripting (XSS):

HTML Injection: I attempted to insert HTML tags into the comment section to see if they are rendered. Unfortunately, the application had proper sanitization mechanisms in place, preventing HTML injection.

XSS: Next, I tried to execute JavaScript code within the First name, Last name, Post titles and Comments to test for XSS vulnerabilities. Again, my attempts were unsuccessful, as the application effectively filtered out potentially harmful scripts.But i didn’t stop.

While exploring the comment section of various user posts, I noticed a odd feature. In the comment section, there were entries labeled as “the comment has been deleted by it’s author.”

This caught my attention because it seemed unusual that deleted comments would still be displayed in any form.

Clicking on a deleted comment,it brought up an option to report the comment. This struck me as odd — why would the platform allow users to report a comment that had already been deleted?

This strange thing piqued my interest, leading me to assume that there might be more information hidden within the report feature.So,I decided to intercept the request made when reporting a deleted comment. Here’s how I proceeded:

①I fired Up Burp Suite,then navigated to a deleted comment and clicked the “Report” button.

②As the report request was sent, I intercepted it with Burp Suite.

③After analyzing the intercepted API request, I discovered something interesting.This request was revealing the entire content of the deleted comment, along with associated metadata such as timestamps, user IDs, and other contextual information.

3.3.3 Impact About this Vulnerability

①Privacy violations: This exposure of deleted comments is a serious privacy violation. Users expect that once they delete a comment, it is permanently removed from the platform and cannot be accessed by anyone. Disclosing deleted comments compromises user trust and can reveal sensitive information that users intended to remove.

②Confidential Information Exposure: Deleted comments might contain sensitive or confidential information that users later regretted sharing. The exposure of such comments can lead to various issues, including reputation damage, harassment, or the unintended spread of personal information.

3.3.4 Lessons Learned

Always test new features thoroughly, as they can introduce unforeseen vulnerabilities.Give attention to small details, like the ability to report deleted comments, can lead to significant discoveries.Also,if you suspect a potential vulnerability, follow through with your hypothesis using various testing methods and tools.

3.3.5 Suggestion For Developers

①Data Minimization: Only include necessary data in API requests and in their responses. Sensitive information, especially deleted content, should never be exposed.

②Privacy by Design: Ensure that privacy considerations are integral to the design and implementation of features.

③Regular Security Audits: Conduct regular security audits, especially after introducing new features, to identify and mitigate vulnerabilities.

3.4.1 About the Vulnerability

While testing redacted.com, I discovered some low-level vulnerabilities, but I wanted to find something more impactful. One day, I suddenly thought of the directory brute forcing method. I believed there might be hidden directories containing sensitive information not intended for public access, so I decided to take action.

3.4.2 Testing Tool

①FFUF tool: It is a powerful and fast web fuzzer written in Go. It is primarily used for brute forcing directories and files on web servers, allowing security testers to uncover hidden resources and potential vulnerabilities. FFUF efficiency comes from its ability to handle large Wordlist and high-speed requests, making it a go-to tool for penetration testers looking to quickly and effectively identify unprotected directories, files, and other web server assets.

②The Wordlist I had used was Seclists：Seclists is a comprehensive collection of Wordlist designed for security testing and penetration testing. Maintained by the security community, it includes various lists for usernames, passwords, URLs, sensitive data patterns, payloads, and more. These Wordlist are invaluable for tasks such as brute forcing, fuzzing, and scanning, helping security professionals identify vulnerabilities and misconfiguration efficiently. Seclists is a go-to resource for anyone looking to enhance their testing toolkit.

The Wordlist I chose for this task was raft-small-words.txt from the Seclists repository.

After that,I have started the directory brute forcing process by running FFUF with the Wordlist. The command looked like this:

ffuf -u http://redacted.com/FUZZ -w /path/to/raft-small-words.txt

3.4.3 Attack scenario

As ffuf progressed through the Wordlist, it returned several directories with HTTP status code 302 (Found).Most of these directories did not contain anything particularly sensitive, but one directory stood out,which was: redacted.com/audit.

Upon accessing the audit directory, I found around 20 subfolders.So I became excited.

Then, I navigated into one of these subfolders and discovered another folder named redacted/platform/entity/contract.

When I accessed this folder,I found this folder contained a list of users associated with redacted.com. Although the users were identified as anonymous.But at the end of the list, I found email addresses of users who had contracts with redacted.com.

To my surprise, this pattern was consistent across all 20 sub-folders within the audit directory. Each folder contained user email addresses, revealing sensitive information about individuals who had contracts with the target website.

The most concerning aspect of this discovery was that the audit directory and its contents were accessible without any authentication. I did not need to register an account or log in to access this information.Anyone with internet access could navigate to these directories and obtain the disclosed email addresses.

3.4.4 Vulnerability Impact

This scenario clearly illustrated an information disclosure vulnerability. The website’s failure to secure the audit directory and its sub-folders exposed sensitive user information to the public.

The exposure of user email addresses and other personal information can have severe consequences. Such data can be exploited in various ways, including phishing attacks, identity theft, and spamming. For the affected users, this can lead to significant privacy breaches and financial losses. For the organization, the fallout can include regulatory penalties, reputation damage, and a loss of user trust.

3.4.5 Cause of this Vulnerability

①Lack of Access Restrictions: The server did not have adequate access control mechanisms in place, allowing unauthorized users to access directories and files that should be restricted.

②Inadequate Directory Listing: The web server configuration allowed directory listing, making it possible for attackers to see and access files within directories that should be hidden.

③Poor Security Configuration: Security misconfiguration, such as leaving sensitive directories and files exposed without authentication or authorization checks, can lead to unintended information disclosure.

3.4.6 Mitigation Steps

To prevent such vulnerabilities, it is crucial to implement proper access controls and security measures. Here are some steps that can be taken to mitigate information disclosure vulnerabilities:

①Access Control: Ensure that sensitive directories and files are not accessible without proper authentication and authorization. Implement role-based access controls to restrict access to authorized users only.

②Sensitive Information Storage: Avoid storing sensitive information, such as user email addresses, in publicly accessible directories. Use secure storage mechanisms and databases with appropriate access controls.

③Security Audits: Perform regular security audits and penetration tests to identify and fix vulnerabilities. Automated tools and manual testing can help uncover hidden directories and other security issues.

④Monitoring and Logging: Implement monitoring and logging to detect unauthorized access attempts. Analyzing logs can help identify potential attacks and take proactive measures to mitigate them.

In this article, I have journeyed through my four security vulnerabilities.And in this article, I have shown the intricate world of security vulnerabilities, exploring four distinct threats that can compromise online experiences.I’ve navigated the Pre-Authentication takeover,a tactic exploiting weak email verification and social logins.Then I’ve dissected the perils of API vulnerabilities, exemplified by the leakage of sensitive store product information.And shed light on the exposure of seemingly deleted comments, a privacy concern lurking beneath the surface. Finally,I’ve embarked on a journey to unveil the hidden — directory brute forcing and its potential for information disclosure.

These vulnerabilities highlight the importance of a multifaceted approach to security. Robust email verification, enhanced social login validation, and stringent API security measures are crucial to safeguards user’s data and privacy.Platforms must prioritize user privacy and implement mechanisms to truly delete unwanted content. Finally, proper server configuration and diligent security practices are essential to prevent directory brute forcing and its associated information disclosure risks.

By acknowledging these vulnerabilities and implementing appropriate mitigation strategies, we can create a more secure digital landscape for all.Through collaboration and a proactive approach, we can foster a secure online environment where trust and transparency reign supreme.

①Be Creative: As a bug bounty hunter, creativity is your greatest asset. Think outside the box and explore various techniques to uncover hidden vulnerabilities. Standard methods may not always reveal the most critical issues, so always look for unconventional ways to uncover vulnerabilities. This creative approach can often lead to the discovery of overlooked weaknesses.By doing so, we can help organizations improve their security posture and protect user data from unauthorized access.

②Understanding the Application: Take the time to thoroughly understand the application’s logic, architecture, and flow. Familiarize yourself with how different features interact and the purpose behind various features. This in-depth knowledge can help you find potential weaknesses and identify areas worth targeting in your testing. By comprehending the application’s intended functionality and user behavior, you can better anticipate where vulnerabilities might exist and craft more effective attacks.

③Combining Techniques: Relying on a single technique or tool is not sufficient enough to find vulnerabilities. To maximize our chances of discovering vulnerabilities, combine multiple approaches. Techniques such as directory brute forcing, parameter tampering,testing API endpoints, SQL injection, and cross-site scripting (XSS) should all be part of our toolkit. By using a diverse set of methods, we can uncover a broader range of vulnerabilities, from simple misconfiguration to complex logic flaws. Each technique provides a different perspective, and when used together, they create a comprehensive testing strategy.