Critical Thinking - Bug Bounty Podcast

Double URL encoding the # in OAuth flows can keep the code in the URL, preventing it from being consumed. This can be leveraged in account takeover chains. https://lnkd.in/egX-ikYR used it in a postMessage-based XSS against a chat widget to extract OAuth codes. The bug exploited double URL encoding to prevent the OAuth code from being processed. This left it sitting in the URL, where it could be extracted and reused. Then, by fixating the state parameter, he forced the OAuth flow to skip a strict COOP-protected step. The next move was dropping the OAuth code into a page with the Chat Widget, which had a postMessage XSS vulnerability. A crafted message forced the widget to load an iframe with javascript: in the URL, leading to JS execution. The attack escalated with iframe hopping. By using "window.open", he jumped between frames until reaching the login frame, which contained the OAuth code. With control over that frame, the code could be extracted. Cool bug!

Mizu found a client-side session fixation bug but needed an XSS to exploit it. After some digging, he found a legacy domain still trusted by the main app. Time to get creative. One of its subdomains had an image upload feature. He embedded an XSS payload inside EXIF metadata, which got executed via document.write. XSS secured. Now onto the session fixation part. The login page used UUIDv4 + two cookies: Host-Session & __Host-Session. The app synced sessions if login configs matched. By controlling cookies, he could force a victim’s session to match his. He used /; domain=; to delete the victim’s cookies except for his own. The app then reissued the __Host-Session automatically, cloning his session into the victim’s browser. The victim logs in, thinking it’s their session—but it’s actually Mizu’s. Account takeover complete. Clever mix of XSS, cookie manipulation & session mismanagement.

Unicode normalization can break sanitization. Some characters that look safe can transform into something dangerous when converted to uppercase/lowercase. If a filter blocks <style> but runs before .toUpperCase(), you could sneak it through. This works because sanitization happens before case conversion, meaning the bypass appears after. Some XSS filters use regex to block <script>, <style>, etc. But if Unicode transforms a string into one of those, game over.

Here’s the easiest way to extract DOMPurify’s config and look for potential security issues: Search for <!--> or \x3c!--\x3e in compiled JS files. This appears at the start of the sanitize function. - Add a log point or breakpoint at the beginning of the?sanitize?function. - Retrieve the?arguments?variable, which contains both the dirty string that needs to be sanitized and the configuration that is applied. To check DOMPurify’s version, log this.version or .isSupported. Remember that DOMPurify.sanitize can use different settings each time it runs, so security levels may vary between uses.

OAuth Client Confusion is an easy-to-overlook vulnerability that can lead to account takeovers. If an app doesn’t verify that an Access Token was generated for its specific Client ID, an attacker can hijack accounts. Here’s how it works: 1- The attacker sets up a public website with Google OAuth login (Implicit Flow). 2- Users log in, and their Google OAuth Access Tokens (for the attacker’s app) are stored. 3- If one of these users has an account on a vulnerable site that skips Client ID validation… The attacker can reuse the victim’s token (from their site) on the vulnerable site. Since the site isn’t checking if the token was issued for its Client ID, the attacker can log in as the victim. A secure OAuth Implicit Flow must verify the Access Token’s Client ID before granting access. In the images we have examples of a secure and a vulnerable flow. If steps 8-10 in the OAuth flow aren’t performed, this attack is possible. Always validate the Client ID. You should definitely take a look at Doyensec's article about Common OAuth Vulns, there’s a lot more there. Here’s the link: https://lnkd.in/ghbKkAXj

DomPurify is supposed to keep XSS out. But what happens when a browser and a security library don’t fully agree on what an HTML comment looks like? Someone found a way to bypass DomPurify by abusing a weird parsing issue. Here’s how it works. We all know HTML comments look like <!-- ... -->. But the HTML spec also allows <! ... >, which is a different way to write a comment. The problem? DomPurify wasn’t handling this alternative syntax properly, while browsers did. That mismatch opened the door for an XSS payload. By sneaking in <! inside a <style> tag, the payload bypassed DomPurify’s filtering and ended up being executed by the browser. DomPurify saw it as safe. but the browser didn’t. In the image you can see how the attack looked like. This kind of attack happens when security libraries and browsers don’t fully align on parsing rules. If a library and a component handle input differently, that’s an opportunity for an attacker. Full writeup by @Ensyzip(X): https://lnkd.in/eAa2u5Ut

The "cookie sandwich" attack bypasses HttpOnly by exploiting cookie parsing flaws. Using malformed cookies with special characters and $Version attributes, attackers can trick servers into exposing authentication tokens. If the app reflects the param1 cookie incorrectly or skips HttpOnly, attackers can view the entire cookie string, including any HttpOnly session cookies between param1 and param2. Python frameworks are particularly vulnerable since they handle quoted strings by default and use ; as cookie separators and encode special chars with \ + three octal digits. Check out their blog for the full article: https://lnkd.in/dQ62-fdQ

New episode is out! We break down a DOMPurify bypass, OAuth vulns, and creative attack techniques. Plus, we're cooking up some cool stuff for the community. Give it a listen and tell us what you think! https://lnkd.in/gnigpMKK

We recently talked about some creative recon techniques on the pod. Here's what you should be doing to step up your recon game: 1. URLScan: Great tool for finding pages that reference your target. Not very effective for large targets, but for specific subdomains or more niche scenarios it's really good. You’ll have to filter through a lot of stuff because it gives a lot of false positives. 2. Check Docker Containers for source code leaks: like GitHub code review, Docker container analysis can reveal vulnerabilities. Download containers, examine their contents and version history to find potential security issues and data leaks. 3. SSL Certificate Scanning helps discover new domains and subdomains linked to a target company, revealing acquisitions, partnerships, and other assets. This gives you an advantage in bug bounty programs that accept reports for all company-owned properties. 4. AI-Powered Recon automation could streamline target analysis by handling routine tasks like running Google dorks, scanning GitHub repos, and performing reverse searches. 5. Changelog Diffing/Analysis is highly reliable since it shows actual code changes. Each commit represents a concrete modification, whether new features or bug fixes.

You should check for these bugs on powerpage-based sites: Microsoft Power Pages is a low-code/no-code platform for building sites that integrate with MS services. Misconfigurations can expose sensitive data, including entire databases. — Here’s how to investigate Power Pages instances for data leaks 1. Find target instances – Most Power Pages sites follow a predictable domain format: [something].powerappsportals.com 2. Check the portal configuration – Look at how authentication and access controls are set up. Some portals allow guest access or have default web roles that expose more data than intended 3. Analyse OData endpoints – Identify which _api/[objname] endpoints are exposed. Misconfigurations here can lead to unauthorised data access. — Extracting Schema & Finding Data Exposures 4. Sign up as a portal user: if registration is open, this helps access additional schema data that wouldn’t be visible to unauthenticated users 5. Export the schema: the export includes a list of default object names. In some cases, misconfigurations grant access to additional tables that shouldn’t be public. 6. Enumerate objects and data fields: since object names are often customised, you may not be able to blindly guess them. However, schema exports and analysing _api/ calls in the front-end can help identify useful queries. Aaron’s research found over 1 million exposed healthcare records due to these misconfigurations. Understanding Power Pages’ access controls and API structure is key to identifying and reporting similar vulnerabilities. Check out the full research here by Aaron C.: https://lnkd.in/g3GFiccU