[HackerNotes Ep.107] Bypassing Cross-Origin Browser Headers

Justin and Joseph are tackling the subject of cross-origin security headers. They also cover some news items including Google’s OAuth login flaw, RAINK, and gift card hacking

Author

Yujilik
January 27, 2025

Hacker TL;DR

  • Google’s OAuth Flaw: @TruffleSecurity found a vulnerability in Google's OAuth that affects expired company domains. Attackers can buy these domains, recreate email accounts, and access third-party services linked to former employees. The exploit works because Google's OAuth uses hd and email claims for authentication, which remain valid even after domain ownership changes.

  • Gift Cards Security Research: @w2w, who’s in the Full Time Hunters' Guild btw, shared a research on gift card security. He invested in premium features for testing, spending on 30+ gift cards and earning 6.5k in bounties.

    His key findings included two race condition vulnerabilities using turbo intruder: one allowing double redemption of top-up codes (Critical) and another enabling multiple uses of one-time promo codes (High). At the end of his research he shared a great tip: enable out-of-scope logging and all MIME types in your MITM proxy to catch checkout requests, so you don’t waste your gift cards.

    If you want to check out his post, his findings included:

    • Bug #1: Race condition in gift card redemption causing financial loss

    • Bug #2: Email HTML injection in notifications

    • Bug #3: Race condition allowing multiple promo code uses

    • Bug #4: Similar vulnerability

    • Bugs #5 & #6: Gift card IDOR vulnerabilities

    • Bug #7: Race condition in developer money transfers

    • Bugs #8 & #9: Email HTML injection issues

  • Top 10 Hacking Techniques of 2024: Voting for PortSwigger's top 10 web hacking techniques of 2024 is now open until Feb 1st. The nominees feature research we've covered on the pod, including work from CTBB community members, head over and show your support with a vote!

  • Cross-Origin-Opener-Policy: These headers help isolate sites from cross-origin access and prevent side-channel attacks. While they improve security by preventing cross-site leaks and isolating from untrusted content, they can limit functionality like auth flows and cross-domain sharing.

    • Same-Origin Policy Restrictions:The same-origin policy blocks cross-origin resource access by default unless CORS is enabled. JavaScript APIs can interact cross-origin via the Window object through:

      • iframe.contentWindow for iFrames

      • window.parent for parent windows

      • window.open() for new windows/popups

      • window.opener for opener windows

    • Accessible cross-origin properties and methods include:

      • window.close(), focus(), postMessage()

      • window.length, closed, opener, frames (read-only)

    • Cool tips from the Critical Research Team and Justin: COOP Header doesn’t apply to non-top-level pages. So if you’re getting stuck without a frame reference thanks to COOP, try to get your target page in an iframe

      • One of the best ways to get a page framed in is to find an XSS on 3rd party subdomain that is iframed into the site you’d like to attack, then use that XSS to redirect the frame to the page you’d like to attack.

    • Service-Worker, from a hacker’s perspective, can be a way for us to gain persistence on a victim’s browser. In order for this to work you need to be able to upload .js files or upload .html while having an XSS.

      Once a service worker is registered, it operates within the scope of the path where it was uploaded. If placed in the root directory (/), the attacker can persist malicious actions across the entire site. However, if uploaded to a subdirectory, its impact is limited to that scope.

    • X-Content-Type-Options: nosniff header instructs the browser to strictly follow the declared Content-Type of a resource and not attempt to infer or “sniff” the MIME type. The fun thing is that if you add another X-Content-Type-Options with an invalid value, it simply discards both of them and the browser ends up sniffing anyway.

The White House has recently banned the use of Kaspersky products across the United States, citing concerns over potential data access risks and allegations of incorporating "backdoors" in their software.


In response, ThreatLocker®, a prominent provider of Zero Trust cybersecurity solutions, has introduced a complimentary system cyber health report. This tool offers businesses insights into their IT environments, highlighting vulnerabilities associated with foreign software. This proactive measure assists organizations in assessing and securing their software ecosystems, ensuring compliance and preemptively addressing security threats. While acknowledging national security concerns raised by foreign software, ThreatLocker® emphasizes the broader scope of vulnerabilities, exemplified by incidents like the 2020 SolarWinds attack. The ThreatLocker® cyber health report comprehensively details all applications in use, their countries of origin, and potential data access implications, promoting informed decision-making and robust security protocols.

Learn More About the ThreatLocker® Cyber Health Report Here: https://www.criticalthinkingpodcast.io/chr

Camille (12) and Corinne (11), daughters of Chainguard’s VP of Engineering, found P1 and a P2 vulns in nothing less than Google. Camille figured out how to bypass Family Link by reusing a rotating code, while Corinne cracked their Chromecast PIN with some good old button mashing. They reported both bugs to Google and got paid for it. It’s such a funny story to kick off this week’s pod. Good job to both of them! hahah

@TruffleSecurity’s research highlights a vuln in Google’s OAuth system that affects former company employees that failed (or maybe just switched email domains). This flaw allows an attacker to purchase an expired domain, recreate old email accounts and use the “Sign in with Google” feature to access a variety of third-party services that were previously linked with these accounts.

Exploiting this vulnerability is quite simple because Google’s OAuth relies on hd (hosted domain) and email claims to authenticate users. Even if the ownership of the domain changes, this data remains unchanged, making it easy for the attacker to impersonate old former users of that domain’s email.

At first, Google classified this issue as fraud/abuse and marked it as “won’t fix”, but 3 months later they changed their minds and said they were working on it.

Recently, a tweet by Rez0 blew up where he said that "AI agent security is a MASSIVE industry being slept on". Since it got so much traction, here's a brief explanation and a few tips about AI Security:

When agents are interacting with code, they need to be really secure. Rez0 also talked about on the pod that in the future it would be cool to have security implementations at the DNS level - like when a request is coming from an AI agent and it's trying to do something, it shouldn't be allowed. It's just an idea, but his whole point is that this industry is still really small and if you want to stay ahead of everybody else, this is something you should pay attention to.

Here's another point of view: how are you going to hack the programs you already hack on when they start implementing AI tools? Because this is going to happen, and you should be ready for that.

It doesn't matter which side of the battle you're on - you'll fall behind if you don't study AI right now because it's here to stay.

Here's the link to another tweet from Rez0 where he talks about three areas of AI security we should all be aware of if you want to give it a read and share your opinions.

Here’s a new tool from BishopFox that helps hackers analyze code diffs to figure out which changes are most likely fixing a useful bug. It processes the code, understands its context, and ranks the most relevant modifications, making it easier for security researchers to focus on what’s really important, speeding up research and exploit development.

But it’s not just for code analysis. This tool can do some pretty cool reasoning across different types of data. In a demo on their blog, they used it to rank the “mathiest” sounding TLDs from over 1.4k options, it’s pretty impressive because all the consumer-level LLMs do a lazy job when dealing with such tasks. It’s a powerful tool that could definitely come in handy. Go check it out!

@w2w, a member of the community and the Full Time Hunters' Guild, gifted us with some really cool research on gift cards. It's always great when someone chooses a niche and dives deep into everything around it. He starts off by saying that paying for extra features and access is often a great investment because most people stick to free access when testing an application. But when the potential ROI is good, paying for some extra features can help us land more bugs. He bought over 30 gift cards and was awarded 6.5k in bounties.

My favourite bugs from his research were 1 and 3, which are actually quite similar. In both cases, he leveraged race condition vulnerabilities that allowed him to apply the same top-up code twice with turbo intruder in the first one, and in the third one, he was able to use the same one-time promo code to make two orders. As you would imagine, these findings were classified as Crit(1) and High(3).

Here’s the entire list of gift card-related bugs he found:

  • Bug #1: Race condition at gift card code redeeming and money transfer to the creator leads to financial loss for a company

  • Bug #2: Email HTML injection in gift card notification email via /gift card

  • Bug #3: Race condition at promo code redeeming leads to getting free items on an unlimited amount of orders

  • Bug #4: Same, but different

  • Bugs #5 & #6: IDORs at gift card view and edit endpoints

  • Bug #7: Race condition at gift card code redeeming and money transfer to the developer leads to financial loss for a company

  • Bugs #8 & #9: Email HTML injection in gift card notification email

For anyone planning to research gift cards, w2w shared valuable advice at the end of his post: make sure you enable out-of-scope logging and all MIME types in your MITM proxy tool to catch the checkout finalisation request. He wasted a lot of gift cards to learn that lesson.

Voting for the top 10 hacking techniques of 2024 is now live on PortSwigger's website. There is some research there that we covered on the pod, and some of it was even covered by members of the CTBB community. So if you want to support our fellow hackers, you have until Feb 1st to go vote for their research.

This set of headers is related to Cross-Origin Isolation, which was implemented to deal with side-channel attacks. Before we start, we first need to understand the reasons why someone would opt to/not to implement Same Origin Restrictions. By implementing these restrictions you’d get better protection against cross-site leaks, you’d isolate your site from untrusted third-party content, and more. But by doing so, you’d also lose some functionalities that are key to a lot of applications like an auth flow, things that facilitate content sharing across domains and such.

Same-Origin Policy Restrictions

The same-origin policy prevents resources from one origin from accessing resources from another origin in the browser. Cross-origin requests via fetch() are blocked by default unless CORS is enabled.

Besides fetch(), there are JavaScript APIs that can interact with cross-origin documents through the Window object:

  • iframe.contentWindow for iFrames

  • window.parent for parent windows

  • window.open() for new windows/popups

  • window.opener for opener windows

In cross-origin scenarios, only specific properties and methods are accessible:

  • window.close(), focus(), postMessage()

  • window.length, closed, opener, frames (read-only)

Despite these limitations, these APIs can still be exploited for cross-context information leaks. The full list is available here.

Here’s a tip from the Critical Research Lab team:

  • You got a vuln in www.site.com and you get it iframed into a page that does not have COOP headers (iframe.site.com)

  • You can now do a window.open() to iframe.site.com and it will iframe www.site.com.

  • Then you can send a message from your attacker-controlled page through iframe.site.com to www.site.com.

Even if www.site.com has the COOP header it will be ignored because it’s not a top-level page, so you can send the data through. If you can figure out a way to get an iframe in, that’s your best way to exploit this scenario.

Justin added that from his own experience, it’s easier to get an iframe injection when you’re dealing with third-party libraries. He’s not telling you to hack things you’re not supposed to… Just to leverage the third-party trust relationship. Yeah, ok, Justin. hahahah As long as it’s reported it’s all good.

So let’s start over, this time with Justin’s tip added in. This is weird and took me quite a while to understand, so pay attention:

  • We get a www.victim.com page that has COOP Headers and we need to send a postMessage to it to exploit a bug, but we can’t get a frame reference because of COOP.

  • We hunt around, and find a page on victim.com that doesn’t have COOP, and has an iframe to a 3rd party support site.

  • We find an XSS on that 3rd party support site, allowing us control over the embedded frame.

  • We window.open the victim.com page with the 3rd party frame embedded from our attacker-controlled page, then use an iframe in the attacker-controlled page to the XSS on the 3rd party support site to then reach into the victim tab, and redirect the 3rd party iframe to our page on www.victim.com that has the postMessage bug.

  • We then exploit the bug with our frame reference, since COOP headers are now ignored.

The Cross-Origin-Opener-Policy (COOP) header impacts both the page that opens another page and the page being opened. When a page with COOP headers opens a new one, the relationship with pages of different origins is severed, providing isolation and preventing cross-origin access.

There are four COOP header options:

  • unsafe-none: the default value with no isolation, opener relationship is maintained across origins

  • same-origin-allow-popups: allows popups to maintain an opener relationship but only isolates documents if they have the same origin

  • same-origin: provides strict isolation, severing opener relationships with pages from different origins

  • noopener-allow-popups: similar to same-origin-allow-popups but prevents the popup from having a reference back to the opener

Cross-Origin-Embedder-Policy has three options:

  • unsafe-none: default setting. Allows fetching cross-origin resources without CORS or CORP permissions.

  • require-corp: only loads same-origin resources or those explicitly allowed via CORS/cross-origin/CORP headers.

  • credentialless: sends cross-origin requests without credentials (no cookies). Responses are allowed without CORP header, except for navigation which requires CORP like require-corp mode.

Cross-Origin-Resource-Policy has three options as well:

  • same-site: allows only requests from the same site (including subdomains)

  • same-origin: restricts access to the exact same origin (protocol, host, and port must match)

  • cross-origin: allows any origin to access the resource

Since we’re talking about it, here are two bonus headers: Service-Worker-Allowed & X-Content-Type-Options.

Service-Worker, from a hacker’s perspective, can be a way for us to gain persistence on a victim’s browser. In order for this to work you need to be able to upload .js files or upload .html while having an XSS.

Once a service worker is registered, it operates within the scope of the path where it was uploaded. If placed in the root directory (/), the attacker can persist malicious actions across the entire site. However, if uploaded to a subdirectory, its impact is limited to that scope.

X-Content-Type-Options: nosniff header instructs the browser to strictly follow the declared Content-Type of a resource and not attempt to infer or “sniff” the MIME type. The fun thing is that if you add another X-Content-Type-Options with an invalid value, it simply discards both of them and the browser ends up sniffing anyway.

If you want to jump into these more and have a bunch of great resources to bookmark, check these out below:

You’ll find Andrew Lock’s 3 part research on COOP in the link below:

That’s it for this week’s episode.

As always, keep hacking!