Session/Auth Bugs

Two Session/Auth Bugs Hello, In this writeup I’m going to talk about two authentication/session related bugs I found, one is a replay attack on a user creation endpoint due to missing server-side session validation, and the other is a stale session issue on a connected portal after a password change. Target let’s call our target example.com, along with its connected admin portal portal.example.com Bug 1: Missing Server-Side Auth Validation on User Creation Endpoint Enables Replay Attack i found that the endpoint POST /api/v1/account/groups/xxxxx/users does not validate whether the session token is still active at the time of the request so even after logging out of the admin portal, previously captured API requests still work perfectly fine, the server accepts them, processes them, and creates new users as if the session were still valid on top of that, there’s no rate limiting or authorization re-check on this endpoint, so the request can be replayed an unlimited number of times with arbitrary user data basically, the backend is trusting the request data without checking: is this session token still active? (Authentication check) is this user still authorized to perform this action? (Authorization check) Attack Scenario log in to the admin portal and navigate to the add-user flow enable Burp Suite intercept and fill in all required fields to create a new user click submit, intercept the outgoing request in Burp and send it to Repeater drop the intercepted request (the user is never actually created via the browser) log out of the admin portal entirely in Burp Repeater, send the captured request, observe a 200 OK and a successful user creation response modify the required data fields and send again, a second user gets created, and this can be repeated indefinitely Impact an attacker who captures a single valid “add user” request can keep creating unlimited new users, even long after the original session has ended there’s no dependency on the session actually being active, meaning logging out or even session expiry does not stop this attack this breaks the fundamental trust between authentication state and privileged actions like user creation Bug 2: Session Not Invalidated on portal.example.com After Password Change on example.com i found that after changing a password on example.com, active sessions on the linked portal.example.com remain valid indefinitely since the portal is connected to the main domain and shares the same credential store, this means an attacker who maintains a portal session can keep performing privileged actions, including resetting other users’ passwords, even after the victim changes their own password Attack Scenario log into example.com and portal.example.com with the same credentials open an additional incognito tab and log into example.com change the password from the example.com account settings observe: example.com correctly logs out all tabs (expected behavior) observe: the portal.example.com session remains active (vulnerable behavior) confirm privileged portal actions can still be performed (e.g resetting other users’ passwords) using the stale session after changing the password, logging out of portal.example.com and logging back in confirms the new password is enforced there too, proving both applications share the same credential store this confirms the session persistence on portal.example.com after a password change is a clear security gap Impact an attacker with a previously valid portal session retains full administrative access even after the victim takes corrective action by changing their password

6-Bug_Bounty · 2026-06-25

XSS via Malicious PDF in Document Share Feature

XSS via Malicious PDF in Document Share Feature Leading to Session Token Exfiltration Hello, In this writeup I’m going to talk about a Cross-Site Scripting (XSS) vulnerability I found in the document sharing feature of a cobrowse platform, the platform allows a support agent to create a live session with a client to help fix issues, and the client can share a PDF if the agent asks for it. Target let’s call our target example.com, a cobrowse platform used to create live support sessions between an agent and a client. Discovery i was testing the document sharing feature during an active cobrowse session, and i noticed the app renders shared PDF content without any sanitization so i thought, what if the PDF itself contains embedded JavaScript? Attack Scenario I Started the session as a support agent in a second browser, i joind as client once the session is active, locate and click the Share Document button on the visitor side craft a malicious PDF file with an embedded JavaScript XSS payload, using PDF JavaScript actions upload and share the crafted PDF through the document share feature the JavaScript payload executes in the browser context of example.com the alert dialog reveals the full domain, confirming code execution in the app’s origin Escalation i didn’t stop at a simple proof-of-concept alert, i wanted to push it further to demonstrate real impact so i escalated the payload to dump the example_ssn_info object, which contains: a live session token the session ID session server routing info call metadata this means the payload can fully exfiltrate a live session token, which enables session hijacking Impact an attacker can share a malicious PDF during a live cobrowse session to execute arbitrary JavaScript in the victim’s browser context the payload can read and exfiltrate the example_ssn_info object, exposing the live session token, session ID, and routing/call metadata with the exfiltrated session token, an attacker could potentially hijack an active cobrowse session, impersonating either the agent or the client Unfortunately, this report was marked as a duplicate, but the program was incredibly generous. They found my recommendations valuable and rewarded me with a bonus. have a nice day , see you Soon

6-Bug_Bounty · 2026-06-15

Race Conditions Bypassing Free Plan Limits

Race Condition Vulnerabilities: Bypassing Free Plan Limits Hello, In this writeup I’m going to talk about two Race Condition vulnerabilities I found that allowed bypassing free plan restrictions. What is a Race Condition? A Race Condition happens when an application processes multiple requests at the same time without properly synchronizing or locking shared resources (like a counter or a limit check). If the app checks a condition (e.g “is the limit reached?”) and updates the value in two separate steps, sending many requests simultaneously can make all of them pass the check before any of them updates the value, this leads to the limit being bypassed entirely. this is usually exploited using Burp Suite’s Repeater with the single-packet attack feature, which sends multiple requests at the exact same time to win the race before the server can properly validate and update the state. Bug 1: Bypassing the 5-User Limit on Free Plan the free plan on this platform only allows owner/admin accounts to add up to 5 users to the test management product, i managed to bypass this limit and add an unlimited number of users using a race condition Discovery while testing the User Management functionality with an owner/admin account, i noticed the user count restriction was enforced on the backend, so i wanted to see if the check could be raced Attack Scenario logged in with the owner/admin role and navigated to the User Management page attempted to modify some users’ access to add them to the test management product intercepted the “add user” requests using Burp Suite sent all these requests simultaneously via Burp Repeater using the single-packet attack technique, creating a race condition the system failed to correctly enforce the user count limit, and all users were added successfully, completely bypassing the 5-user restriction Impact free plan users can bypass the 5-user restriction and add unlimited team members this results in potential financial loss, since users no longer need to upgrade to a paid plan to add more participants Bug 2: Bypassing the 50-Scan Limit on accessibility.example.com similar idea, but this time on accessibility.example.com, the free plan restricts users to a maximum of 50 web scans, and i was able to bypass this limit using the same race condition technique Discovery i started creating scans normally until i hit the limit, a pop-up appeared confirming that the free plan cap of 50 scans had been reached, so i decided to test if this limit could be raced the same way Attack Scenario navigated to accessibility.example.com and attempted to create a new scan until hitting the 50-scan limit, confirmed by the limit pop-up intercepted the New Scan request and sent it to Burp Repeater duplicated the request multiple times in Repeater to match the desired number of new scans deleted the 50th (last) scan in the account to reset the state before firing the race sent all duplicated requests in parallel (single-packet attack), creating a race condition most of the scan creation requests succeeded, allowing me to bypass the 50-scan limit completely Impact free plan users can create an unlimited number of scans, bypassing the 50-scan restriction results in potential financial loss for the platform, since users no longer need to upgrade to a paid plan to exceed the scan limit

6-Bug_Bounty · 2024-11-01

Hunting E-Commerce

Multiple Vulnerabilities on E-Commerce (Password Reset + 3 IDORs) Hello, In this writeup I’m going to talk about multiple vulnerabilities I found on ecommerce.com, an e-commerce app for used products where users can add items to cart, buy them, or bid on live auctions. in this writeup i have 4 bugs: one password reset token issue, and three different IDORs Target: let’s call our target ecommerce.com Bug 1: Password Reset Token Doesn’t Expire i started testing the main auth functions: sign-in, sign-up, password reset, and OAuth while testing password reset i noticed something interesting, the reset token doesn’t expire until a new one is requested so i decided to dig deeper, i changed the email address on one of my test accounts, then tried to use the OLD reset token again and guess what? it worked! Attack Scenario so i built a realistic scenario out of this: victim creates an account, and receives a reset/create password link on their registered email victim changes their email to a new one (e.g from victim@old.com to victim@new.com) attacker, who already has access to victim@old.com, still has the old reset link attacker uses that old link to reset the password attacker successfully takes over the victim’s account at first i thought they would close it as informative/N-A, but they accepted it as Low severity, the scenario was realistic enough to make sense to them Bug 2: Cancel Any User’s Purchase via IDOR after a couple of days i moved to testing other functions: add to cart, complete order, and view purchases how the purchase flow works user adds a product to cart user clicks complete order the product moves to the purchases list, and the user has to pay for it, otherwise the account could get blocked for having uncommitted purchases Discovery before payment, a POST request is sent to /api/webapi/shopping/ordercheckout/createuncommittedpurchaseorder this marks the order as uncommitted until payment happens if this request is sent more than once: the purchase disappears from the account, so it can’t be paid for later after a while, the account gets blocked for having too many uncommitted purchases so i created an order on my second account and replaced the purchaseOrderId with the one belonging to the first account and it worked, i canceled the other account’s purchase Bypassing the GUID/UUID Policy but there was a catch, the program’s policy states that any IDOR depending on a GUID/UUID gets downgraded to Low severity so i challenged myself to find something better i crawled the site, went through the purchasing flow as a regular user, and checked my Burp history i searched for purchaseOrderId and found another vulnerable parameter tied to it how i got the purchaseOrderId: when you attempt to purchase a product, a transactionId is generated and tied to the purchaseOrderId, when completing the purchase, the app sends a GET request with the transactionId to retrieve the purchaseOrderId, then uses it to complete the process Attack Scenario write a simple python script (or use Burp Intruder) to brute force valid transactionId values (0 to 999999999) retrieve all corresponding purchaseOrderIds uncommit/cancel any purchase order on ecommerce.com, for any user Impact attacker can cancel any purchase for any user without their knowledge attacker can spam this behavior to get random users’ accounts blocked i initially thought account blocking was fully automated based on uncommitted purchases, but the team clarified it’s controlled manually on their end Result we reported this as Critical, they accepted it as Medium, still a solid finding Bug 3: IDOR via cartId Allows Viewing/Modifying Victim’s Cart while testing the cart functionality i noticed the cartId parameter is trusted without checking who actually owns it Attack Scenario attacker has the victim’s cartId attacker performs a normal action on their own cart (add, remove, or view), intercepting the request with Burp Suite and sending it to Repeater attacker replaces their own cartId in the intercepted request with the victim’s cartId attacker successfully adds to, removes from, or views the contents of the victim’s cart by sending the modified request Impact attacker can view a victim’s private cart contents attacker can add unwanted items or remove items from a victim’s cart without their knowledge Bug 4: IDOR on /cartoverview/ Endpoint i found another related issue on a different endpoint that handles cart overview, /api/webapi/shopping/checkout/cartoverview/<cartId>, it has improper access control checks on the cart identifier Same impact as Bug 3, and it was also a duplicate. I hope you enjoyed my writeup — see you soon! —

6-Bug_Bounty · 2024-10-18

Chain self xss + CSRF lead to Reflected XSS

Reflected XSS via Self-XSS + CSRF Chain Hello, in this writeup I’m going to walk through the technique I used to achieve Reflected Cross-Site Scripting (RXSS) by chaining a Self-XSS with CSRF. Let’s first briefly define XSS and its types before diving into the actual bug. What is XSS? Cross-Site Scripting (XSS) is a vulnerability that allows an attacker to inject malicious scripts into trusted web pages, causing them to execute within the victim’s browser session. Types of XSS: Stored XSS: the payload is permanently stored on the server (database, comments, etc.). Reflected XSS: the payload is immediately reflected back in the server’s response (search results, error messages, etc.). DOM-Based XSS: the vulnerability exists purely in client-side JavaScript, with no server involvement required. Now let’s get into the actual bug. Let’s call our target example.com Recon I started with some basic recon: subfinder -d example.com Going through the results, one subdomain caught my attention: banking.example.com Discovery I opened it and created an account. I started by checking the profile page and testing the parameters, injecting simple HTML and XSS payloads to see what would reflect in the page source. I found a parameter called iban that reflected my input without any sanitization. So I crafted the following payload: "><body onpageshow=alert(document.domain)>< Upon saving, the alert fired, as shown in the screenshot below: At this point, it was still just a Self-XSS with zero impact on other users. Escalation To turn this into a real, impactful vulnerability, I inspected the request further and noticed it had no CSRF token, which gave me the idea to chain it with CSRF. I opened the request in Burp Suite Pro: Right click -> Engagement tools -> Generate CSRF PoC I then hosted the PoC on GitHub Pages. Now, sending this link to a victim causes the JavaScript payload to execute within their authenticated session, effectively escalating the Self-XSS into a fully Reflected XSS.

6-Bug_Bounty · 2024-04-28

Mostafa Ashraf

Contact

6-Bug_Bounty