Welcome back people! Today we will be digging into how to find XSS that others are not finding.
Bug Number 1: Stored and Reflected XSS on settings page
Looking for a XSS in this site was interesting, no code was popping but I was getting some parsed data like this:
Instead of my full payload as:
"><img src=x onerror=alert("XSS");>
This meant that the application was taking in my data and not blocking it. From here I went through the entire website seeing if the payload would pop up anywhere else and it did. Upon further investigation, I discovered that the XSS vulnerability I identified on the settings page has a wider impact on the entire website. The issue is related to improper input validation and output encoding, allowing malicious payloads to be executed both in a stored and reflected manner. This meant I could exfiltrate data of the users from their settings page because the data that was shared in the settings page is able to be viewed by other people (Administrators or Researchers).
- Data Exfiltration: Attackers can steal sensitive user data stored in the settings page, which is accessible to administrators and researchers. This data may include personal information, email addresses, or even authentication tokens.
- Session Hijacking: An attacker can use this vulnerability to hijack user sessions, potentially gaining unauthorized access to the victim’s account
Tips for finding this type of XSS
- Once a payload is past filters, don’t remain on one page, try to visit every page on the site because it could be getting displayed somewhere else.
- Check for Variations in Input Handling: After successfully injecting a payload, test different variations of the payload (e.g., different encodings, payloads with special characters) to ensure that the vulnerability is not limited to a specific input format or context.
- Investigate Cookie Manipulation: If the XSS…