TL;DR

Reflected input is often unexploitable because the attack ends up in a place which stops it working, such as inside a quoted attribute. However, the Range header can be used to force the server to send only the attack section from the document, making it fully-exploitable in the process.

Background

In recent months I’ve been doing quite a lot of research around improving my ability to detect desync and header injection vectors, and then make them fully exploitable. And as part of this, even though they are generally quite effective on their own, I also wanted to find better ways to insert XSS attacks into the responses which were sent back to the victims. Because, after all, there’s nothing quite like a bit of instant gratification to warm even the blackest of hearts, right?

Now, as I’m sure you know, one of the pleasing things about desync and header injection is that unlike anything delivered through a browser, you aren’t restricted by the limitations of CORS and fetch. Which means that you can pretty much put whatever you like into the requests.

As part of this, I allocated some time to looking at the Range header, and noticed a few useful things:

• all of the main browsers will happily accept an unsolicited Range response (206 Partial Content). Yay!

• and something like 30-40% of all endpoints will respond to a Range request

In the Red Corner

From an offensive perspective, this should be interesting as it lets you take an unexploitable vector, glue it together with desync or header-injection, and make it fully exploitable.

There are two bits you’re looking for. The first is endpoints with reflected input which ends up being incorporated into the response verbatim, but alas somewhere unexploitable (like inside quotes in an attribute). Then the second bit is whether the same endpoint will respond to the Range header.

To test for the latter, just add the following header to the request and look for a 206 Partial Content response:

Range: bytes=0-0

Putting it all Together

In practice (once you’ve found a target that meets all the requirements), the actual delivery ends up being straightforward.

Just remember to also strip the Accept-Encoding header from the request, so you get back the raw document, not an unusable chunk of binary noise.

GET /api/v1/web-cookie-privacy/config?locale=en&appId=(console.log(`XSS`));//&theme=default&tea=1 HTTP/1.1
Host: www.tiktok.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Cache-Control: no-cache
Connection: keep-alive
Range: bytes=80-99

HTTP/1.1 206 Partial Content
Content-Type: application/json; charset=utf-8
Server: TLB
Content-Range: bytes 80-99/105
Content-Length: 20

(console.log(`XSS`))

(no tiktok streamers were harmed in the making of this blog)

In the Blue Corner

This is actually pretty tough to defend against, as all the individual steps in the attack chain are relatively benign. Unexploitable reflected content, and an endpoint that responds to the Range header, don’t even warrant an informational note in a report.

The only way to spot this is to understand how the individual issues can be assembled into a working attack chain, and then keep an eye out for the combinations.

Additional Information

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range

“Thanks”

I just wanted to say a big “thanks” to my inability to say no to intrusive thoughts. It’s the little things, right?

TL;DR

The Google developer documentation includes CSP examples which use domain wildcards (which have been widely cut & pasted), and additionally there are numerous endpoints within the Google eTLDs which are vulnerable to Javascript XSS. These can be combined into an effective attack against any domain with an HTML injection vector that would be otherwise unexploitable.

Background

Whilst researching ways to make HTML injection vectors exploitable, I noticed that many of the vulnerable endpoints included similar CSP headers, which often had wildcards for the google eTLDs. It soon became obvious that the reason for this, was that they had been cut & pasted straight from the Google developer documentation. Oh dear.

So then I took a quick sweep through the Google eTLDs, to see if I could find any endpoints which were vulnerable to javascript XSS that I could use, and to my obvious delight I found that there were actually plenty to choose from.

It’s worth noting at this point that I did do the responsible thing, and flagged the issues to the Google security team, but as far as they were concerned this was “by design” and not a security problem. Though to their credit, they have updated the CSP documentation so that it no longer has the wildcards. Small victories.

In the Red Corner

From an attack point of view, the reason that you should be interested is that you can take an otherwise unexploitable HTML injection vector, and work it up into a full XSS.

But before we go any further, if you’re not already familiar with the way that CSP works, then I’d recommend reading the Mozilla CSP guide first, which is a good primer.

Content-Security-Policy

What you are looking for is an endpoint that is vulnerable to HTML injection, but with a CSP that blocks the full XSS. However, if the CSP has the wildcard google eTLDs in the script-src or default-src sections, then you are on to a winner.

Content-Security-Policy: default-src 'self' *.google.com *.googleapis.com

Javascript XSS

The easiest way of getting javascript from the google domains is to simply upload it to one of the containers (like storage.googleapis.com or firebasestorage.googleapis.com). However, if this isn’t possible for some reason, then there is currently a broken JSONP library that is widely used across the Google estate, which you can leverage too. You just need to add a callback query parameter containing your payload. Easy as cake.

Putting it all Together

In practice (once you’ve found a target that meets all the requirements), the actual delivery ends up being really simple.

<html>
<head>
<meta http-equiv="Content-Security-Policy" content="default-src https://*.google.com">
</head>
<body>
<script src=https://clients6.google.com/discovery/v1/apis?callback=%28alert%28%27XSS%27%29%29></script>
</body>
</html>

In the Blue Corner

The first thing to look at is to make sure that your CSPs are effective. As a general rule, avoiding inline code and any wildcard domains is a good place to start.

Google actually provide a CSP analyser tool which is useful (would have been nice if they’d used it to generate their developer examples ;)

Additional Information

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

https://bughunters.google.com/learn/invalid-reports/web-platform/xss/6619189462433792/xss-in-sandbox-domains

https://csp-evaluator.withgoogle.com/

“Thanks”

I just wanted to say a big “thanks” to the Google security team, who were efficient, professional and a complete pleasure to work with. Love you long-time!

TL;DR

The main browsers share their cache between Fetch requests and normal navigation. This means that any request that can be made with Fetch, which produces a cacheable response, can also be used to poison the browser navigation too. Given the right set of circumstances, this approach can unlock a raft of unexploitable vulnerabilities, and make them practical.

Background

The idea for this research came about after sitting through lots of penetration test washups, where the “Cacheable Response” finding was skipped over as irrelevant. However, you may have noticed that I find it really satisfying to chain a bunch of low impact issues into something more substantial, so I added browser caching to my never-ending research list.

The result was that I noticed that Fetch shares the same cache as the regular navigation, with the cache key being based upon the URI and originating state. However, because Fetch is able to add headers to the request that can change the response (but which are not included in the cache key), an attacker can pre-request resources to poison the private cache, then force the browser to navigate to the page, which activates the attack.

To make this work requires two things:

• the target endpoint must pass a pre-flight check, as adding headers to a Fetch request requires CORS; and

• the Fetch response (or if a redirect, then both the redirect and response) must be cacheable by the browser, either explicitly (cache-control, pragma or expires headers), or implicitly (301/308 status code, or last-modified header).

As an interesting observation, the response does not always have to be made available to Fetch for the browser cache to be updated. For example, if the pre-flight passes, but the actual response does not have an access-control-allow-origin header, then it will be blocked due to CORS. But even so, the cache will still be updated successfully.

In the Red Corner

From an attack point of view, the reason that you should be interested in poisoning the browser cache, is that you can use it to leverage vectors that would otherwise be unexploitable, and even better, to use them to pivot laterally between sites that share the same eTLD.

However, before we go any further, if you’re not already familiar with the way that caching and CORS work, then I’d recommend reading the Mozilla caching and CORS guides first, which are good primers.

You may also be thinking that this is exactly the kind of situation that browser state partitioning should prevent. And you’d be partially right. Originally it was introduced as a privacy measure, to stop information leaking between states. And in the same way that it broke shared CDNs, it should also have stopped a lot of the cache poisoning too. However, it only partially mitigates it. There are some browser implementation bugs that mean that different states are incorrectly treated as the same, but the biggest issue is that the null state is universally equal. So, if the attack can be delivered from the null origin, then it can be happily poisoned and exploited cross-site. Yay!

Pre-request with Fetch

The crux of the issue is that Fetch and the normal navigation share the same cache, but requests made with Fetch can include headers which change the response, but not the cache key. Ooops.

For the pre-request step to work, any useful Fetch request (which typically triggers an exploit using headers), will first need to pass the CORS preflight check. After this, the actual response will need to be cacheable. However, if the response itself does not pass CORS, then it will end up being cached anyway (after all it was successful at the HTTP layer). The detail varies per browser brand, so you’ll need to verify this manually.

And that’s it. All you need is to follow-up with a normal navigation to load the content from cache and activate it within the target DOM. Pow!

Putting it all Together

In practice (once you’ve found a target that meets all the requirements), the actual delivery ends up being really simple. For some browsers, you’ll need to wrap the below in an iframe, to force the state partition check to work.

           
      window.nonce = Math.random( ).toString( 36 ).substr( 2, 5 )

      fetch( 'http://a.gvj.io/200?n=' + window.nonce, {
            method: 'GET',
            mode: 'cors',
            cache: 'reload',
            redirect: 'follow',
            credentials: 'include',
            headers: {
                  'x-original-url': '/poisoned'
            }
      } )
      .catch( ( ) => { } )
      .then( ( ) => { 

        setTimeout( function( ) { 

            window.location.replace( 'http://a.gvj.io/200?n=' + window.nonce );

        }, 200 );

      } );

Browser Test Cases

Although it seems like there are a lot of browsers to choose from, there are basically three: the Chromium variants, Firefox, and Safari. Obviously, they all implemented state partitioning slightly differently, and so also respond differently to cache poisoning. On top of that, in the months since I first notified the vendors of this bug, the teams have also been merging patches that subtly change the caching behaviour.

So, if you want to know if a particular version of a browser is vulnerable, the test cases below should give you a definitive answer. These are divided by direct and iframe (forcing a null origin), then further subdivided by same-origin, same-site and cross-site states:

http://a.gvj.io/direct

http://a.gvj.io/iframe

In the Blue Corner

As all the magic is happening in the browser, it might seem that there isn’t a lot you can do to prevent this kind of attack. However, there are a few things you can try.

The first is to ensure that dynamically generated content isn’t being cached when it shouldn’t be (remember that “cacheable response” finding in the report? It’s time to triage those). Then if a response really must be cached, you can explore the use of the vary header, which will force the cache key to include any headers of your choosing. Using this approach, you can effectively make Fetch and the normal navigation use separate cache keys.

Then from a detection perspective, for an attacker to find a vulnerable target typically requires scanning for broken CORS, which you can detect in your SIEM (look out for large volumes of failed OPTIONS requests).

Additional Information

https://fetch.spec.whatwg.org/#http-cache-partitions

https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-1554

“Thanks”

I just wanted to say a big “thanks” to the teams from Firefox, Google and Apple, who were efficient, professional and a complete pleasure to work with. Love you long-time!

TL;DR

According to data from RIPE, over 40% of computers attached to the Internet have a few seconds of clock drift, which with the right combination of headers, will make an HTTP response unintentionally cacheable.

Background

Like many parts of the HTTP model, caching has been extended and revised multiple times over the years. The result is a confusing set of response header values, which affect the way that the browser may or may-not cache the response.

If you are not already familiar with the browser caching model, I’d recommend reading the Mozilla caching guide, which is a good primer.

For this article, the two interesting bits are the expires header (which explicitly directs the browser to cache), and the last-modified header (which implicitly triggers heuristic caching). Both of these use a standard HTTP date format response.

So, as long as a response does not have a pragma or cache-control header, then the browser will use expires and last-modified if they are present.

In the Red Corner

From an attack point of view, the reason that you should be interested in responses that are unintenionally cacheable, is that you can use them with cache poisoning to leverage vectors that would otherwise be unexploitable.

Expires

The expires header normally works by setting the value to a point in the future, which tells the browser it can cache the response until that time. The potential for unintentional caching is introduced when the application attempts to signal that the resource should not be cached, by setting the expires value to the current time (“now”). That’s because, if the server clock is fast, or the browser clock is slow, then “now” is actually a point in the future, and the browser will cache the response. Ooops.

Last-Modified

The last-modified header works in a similar way. If the last-modified value is in the past, then the heuristic caching algorithm in the browser may add the response to the cache.

Putting it all Together

What you are looking for are responses that:

• do not contain a cache-control or pragma header that explicitly stops the browser caching the response (so cache-control could contain the private parameter, but not the no-store parameter); and

• do contain an expires or last-modified header that is set to the same value as the date header.

HTTP/1.1 200 OK
Date: Sat, 10 Feb 2024 07:08:02 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Expires: Sat, 10 Feb 2024 07:08:02 GMT
Content-Language: en

In the Blue Corner

The expires and last-modified headers are only used by the browser when the cache-control and pragma headers are not present:

• always set the cache-control header on every response, to explicitly control whether you want the browser to cache it or not;

• if you absolutely must use an expires header to signal that a response should not be cached, set it to a value waaaay in the past; and

• do not rely on last-modified alone to signal caching behaviour to the browser, as the heuristic model varies between browsers, and you may not get what you expected.

Additional Information

https://labs.ripe.net/author/gih/is-the-internet-running-late/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

TL;DR

The presence of the TRACE method is generally considered to be at best an informational finding (and in isolation, I wouldn’t disagree with that). But before you deploy your meh, if you know what to look for, the TRACE method (and any other mechanism that reflect requests) can be added to a practical attack chain, and will dramatically increase the impact of an exploit.

Background

The TRACE method was originally introduced as a diagnostic tool, to reflect back the request that was received by the server. But as is the way, it didn’t take too long before enterprising individuals realised that it could be combined with any old XSS, to provide a practical way of getting around the HttpOnly cookie flag (which is intended to stop sensitive cookies being accessible to javascript).

At this point, you’ll probably be thinking “yeah, but changes to the XMLHttpRequest and fetch standards mean that you can’t send the TRACE method anymore”, and you’d be right.

But don’t you think it would be cool if you could bypass those restrictions, or there were other ways to achieve the same, reflected request? Well, you’ve come to the right place!

In the Red Corner

From an offensive point of view, this should be interesting as it enables two useful things:

• firstly, the diagnostic response itself often contains sensitive information from the app stack, like keys and tokens that have been added by internal systems, along with evidence of hidden issues, like missing encryption on internal connections etc. Scrutinise carefully!

• and secondly, it allows you to dramatically increase the impact of other exploits, turning a hum-drum XSS into a full account takeover etc.

Override headers

Although it is true that changes to the XMLHttpRequest and fetch standards have stopped the direct use of the TRACE method, up until last year you could still use the standard override headers (x-http-method-override etc.) to deliver the same attack. And even better, with the right set of CORS misconfigurations, you didn’t even need to chain it to anything else to deliver the attack.

That said, only the most common override headers are blocked by the standard, so it is still possible to find and exploit the less common ones in the wild (like _method, x-method and x-tunneled-method).

GET /path.html HTTP/1.1
Host: yomama.com
_method: TRACE

Query and body parameters

A collection of the common app stacks will accept a method override parameter by default, which functions the same as the TRACE method. You’ll need to deploy your google-fu and tweak your approach to match the target environment (I’ve included a handful of references at the end of this blog to get you started). And once again, check for CORS misconfigurations, as if present, these are fully exploitable all on their own.

GET /path.html?_method=TRACE HTTP/1.1
Host: yomama.com

Weird shit

There are a lot of app instrumentation products around now, which gather user statistics at a low level, by passing the raw request on to an instrumentation stack for analysis. Usually this happens via a collection of client-side javascript plugins, but I’ve seen some really awful implementations that put the raw request into a JSON blob embedded within the main page, which in-turn gets sent on to the instrumentation.

Gaining access to the reflected request obviously works just fine in a chain with XSS, but if you can combine it with something else, like cache deception, this is a really elegant way of gaining access to a user’s session tokens, which can often be leveraged into a full account takeover.

In the Blue Corner

There are two things you can immediately do to defend against these kinds of reflected request attacks.

Firstly, add signatures to your IDS/SIEM that trigger on the main override headers and parameters (this should be as early in your app stack as possible, so it catches headers entering your environment, not those added by any of your internal components). Monitor the output closely, as you may find that you have apps deployed that depend on some of these headers.

Secondly, strip (or reject) any of the headers and parameters that your apps don’t need as early as possible in your app stack.

References

https://www.rfc-editor.org/rfc/rfc2068#section-9.8

https://owasp.org/www-community/attacks/Cross_Site_Tracing

https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/#_method-or-x-http-method-override-header

https://docs.spring.io/spring-framework/docs/5.0.2.RELEASE/kdoc-api/spring-framework/org.springframework.web.filter/-hidden-http-method-filter/

TL;DR

The modern frameworks are often very flexible with what they accept, and will happily treat a POST with a JSON body as interchangeable with a URL encoded body, or even with query parameters. Due to this, an unexploitable JSON XSS vector can sometimes be made exploitable by flipping it to one of these alternative approaches.

Background

In the dim and distant past, most web apps were almost entirely bespoke creations, and they were often riddled with vulnerabilities that were unique to that particular site. These days, a lot of the generic issues have been addressed through the use of the modern app frameworks, which take care of a lot of the heavy lifting when it comes to generating HTML and providing database access etc.

However, those same app frameworks are also very flexible by default when it comes to the ways that they accept data, and they will happily take parameters, whether they are in a JSON body, URL encoded body, or a query string. Yay!

In the Red Corner

From an offensive point of view, this should be interesting as it allows you to take a vector that is otherwise unexploitable, and make it useable.

For example, a POST with a JSON body that returns an HTML response with an XSS payload. It’s a good find, but as it stands, it can’t be practically exploited. However, if you can swap the JSON body to URL encoded (or a query) then you can happily use a self-submitting form to make the XSS work without any interaction at all (no CORS, and the HTML response is rendered).

As if this wasn’t enough, you’ll often also find that the encoding/decoding sequence is different for a parameter that is received from JSON as opposed to the alternatives: this may be enough to enable an attack to work when it otherwise wouldn’t.

Simple

For a simple JSON object, the transposition is really straight forward: you just flip the attribute/value pairs between encoding styles.

{"attribute1":"value1","attribute2":"value2"} 

becomes

attribute1=value1&attribute2=value2

Nested

For nested JSON objects/arrays there are a bunch of competing (and incompatible, obviously) approaches. Mostly though, this just means serialising the object into a set of paths.

The main standards for the transposition are Rack, Spring and Stripe. I’ve included a few references to get you started at the end of this blog, but beyond that, you’ll need to deploy your google-fu and tweak your approach to match the target environment.

{"object":{"attribute1":"value1","attribute2":"value2"}}

  becomes

object[attribute1]=value1&object[attribute2]=value2

Weird Shit

I have also seen some weird endpoints in the wild, that ignore the content-type altogether, and will instead dynamically detect the data in the body. For these, you can try making the entire JSON request into a text/plain or URL encoded attribute and it may parse just fine.

{"object":{"attribute1":"value1","attribute2":"value2"}}

becomes for text/plain (note the JSON comment suffix to stop the equals sign tripping up the parser)

{"object":{"attribute1":"value1","attribute2":"value2"}}//=

which becomes for URL encoded

%7B%22object%22%3A%7B%22attribute1%22%3A%22value1%22%2C%22attribute2%22%3A%22value2%22%7D%7D%2F%2F=  

Self-Submitting Form

And obviously, once you get the transposition working, you’ll want to be able to practically exploit it. A URL encoded POST is treated as a CORS simple request, and so it’ll happily work cross-origin, and will also include the authentication cookies too. Whoop!

<body onload=document.getElementsByTagName('form')[0].submit();>

    <form method=post action=https://yo.mama>

        <input type=hidden name=attribute1 value=value1>
        <input type=hidden name=attribute2 value=value2>

    </form>

</body>

In the Blue Corner

The thorough way to defend against this is to hunt out all your endpoints that accept JSON by default, and if they also accept URL encoded and queries (which aren’t used by your apps) then disable the functionality.

However, if you’re in a rush and need to monkey-patch an active attack, then you can always use your WAF to block content-types other than application/json. It’s not pretty, but it’ll get the job done.

References

https://brandur.org/fragments/application-x-wwww-form-urlencoded

TL;DR

If you can find an unrestricted CORS endpoint, that also responds to the HTTP override headers, then potentially you can use it to access endpoints that aren’t enabled for CORS, bypass CSRF protections, and also deliver an XST (which will give you access to cookies protected by the httpOnly attribute).

Background

The idea for this research came about after repeatedly hearing people say that CORS issues are irrelevant (which to be fair, the generic “allows any origin” alert you get from many scanners mostly is).

But I really don’t like being told something isn’t possible, so instead I set out to have a proper rummage and see what I could actually do with CORS. Apart from being fun, along the way I found a quirk that affected all the main browsers, and also some web platform zero-days too. What’s not to like about that?

Anyway, back in the Dark Ages, before CORS existed, we just had the same-origin policy, which limited the types of requests that could be sent between sites. The introduction of CORS brought a huge amount of flexibility to cross-origin requests, and made the web the rich experience that it is today. But it is also a bit fiddly to setup, and because of that, is easy to get wrong. Which is a bad thing, if you’re looking to secure your site.

It’s a bit like the classic firewalling problem. The engineer spends the morning trying to make a fiddly rule work well, then just gives up, clicks the any button, and makes a mental note to come back and fix it properly sometime (i.e. when hell freezes over).

CORS is the same. Out in the real world, there are a lot of sites configured with a * for methods, origins and headers. Either because that is the default the platform ships with, or because someone gave up and clicked the any button.

In the Red Corner

From an attack point of view, the reason that you should be interested in CORS is that you can get a request to fire within a user’s session, and in doing so leverage their credentials and network access.

However, before we go any further, if you’re not already familiar with the way CORS works (and CORS Preflight in particular), then I’d recommend reading the Mozilla CORS guide which is a good primer.

Override Headers

Once upon a time, an engineer (let’s call her Karren) was struggling to make an application work through a firewall, when she had an epiphany. She would fix the problem by implementing a shadow set of method, host and URI headers that the firewall didn’t know about. And in that moment, she created dozens of possible combinations for accessing an app through a restrictive firewall. And even better, she then told the rest of her engineer buddies, who spawned similar abominations. Love you Karren!

Anyway, wouldn’t it be cool if you could take an unrestricted CORS configuration, and use these override headers to basically ignore CORS and access whatever part of the app stack you wanted to? Well, as it turns out, that’s exactly what you can do. Yay!

The reason that this works is that any useful CORS request will generate two separate HTTP requests. The first is the Preflight (which has minimal headers, and no overrides) and then the second is the actual CORS request (which has your override headers). That means that each HTTP request will get a response from a different part of the app stack. The Preflight will be answered by the unrestricted CORS endpoint, but the actual request goes elsewhere. OooOOoooh!

Recon

To make this work in practice, you will need to do your recon thoroughly, then glue all the separate bits together into a workable attack.

The first thing to do is to find the unrestricted CORS endpoints: the ones which allow authentication plus the override headers. In practice, this means making a lot of CORS Preflight requests, to enumerate the possible origin, method and header combinations (because when authentication is enabled, a * in the response is treated as a literal, not a wildcard).

It’s also worth noting that some CORS endpoints will take an access-control-request-headers populated with all the desired headers, then respond with an access-control-allow-headers that contains the subset of allowed headers. You can use this to cut the number of requests you need to send. However, some other CORS endpoints will reject the request outright if they do not support one of the requested headers. These you will need to enumerate empirically.

The second thing to do is to check whether these unrestricted CORS endpoints also respond to one of the override headers too. If this isn’t something you are already familiar with, then it is time to deploy your google-fu. What am I, your mother?

Putting It All Together

Ok, so you’ve found an unrestricted CORS endpoint that also accepts the override headers, now what? Well, the actual detail depends on the app stack in use, and what you want to achieve.

Let’s say that your target responds to one of the host override headers (forwarded, x-forwarded-host, x-forwarded-server, x-host and x-http-host-override). Because the typical app stack has a common set of load balancers and reverse-proxies, you can often use these headers to redirect your request between servers.

Then there are the URI override headers (x-original-url, x-rewrite-url and x-url), which allow you to redirect your request to other endpoints on the same host.

And finally, the method override headers (x-http-method, x-http-method-override, x-method and x-method-override), which allow you to swap methods.

It’s worth noting that any combination of overrides that redirect the request to a non-CORS endpoint may not return the correct CORS headers, and so will “fail” from the perspective of the browser (and block access to the response). However, that will not stop the request from working.

CSRF

This is where it gets fun. A lot of CSRF protection mechanisms rely on the token only being available from an endpoint that doesn’t allow CORS requests. However, that isn’t strictly true, is it ;)

XST

XST hasn’t been a thing for years now, because the browsers have blocked direct access to the TRACE method. However, again, that isn’t strictly true.

Also, because this is CORS, all it takes is the right combination of misconfigurations on a site, and you can use XST to completely compromise the user accounts with one fetch call (bypassing any cookie httpOnly restrictions). Full account compromise, and all from a CORS misconfiguration. Boom!

I had a lot of fun with this in the last few months, whilst the main browsers were busy implementing fixes. However, as of now, this shouldn’t be possible with the latest browser code (though there will of course be vulnerable versions hanging around for years to come).

In the Blue Corner

There are three things you can immediately do to defend against these kinds of request header issues in general, and the CORS issues specifically.

Firstly, add signatures to your IDS/SIEM that trigger on the main override headers (this should be as early in your app stack as possible, so it catches headers entering your environment, not those added by any of your internal components). Monitor the output closely, as you may find that you have apps deployed that depend on some of these headers:

• forwarded

• x-forwarded-host

• x-forwarded-server

• x-host

• x-http-host-override

• x-http-method

• x-http-method-override

• x-method

• x-method-override

• x-original-url

• x-rewrite-url

• x-url

Secondly, strip (or reject) any of these headers that your apps don’t need as early as possible in your app stack.

And finally, find all your endpoints that respond to CORS Preflight requests, and ensure that they accept the minimum set of headers required to make the app work. Pay special attention to the access-control-allow-headers response (which should not be a * and also should not simply reflect back the request either).

XST PoC Site

If you want to see it work for real, then there is an XST PoC site available that you can experiment with here: https://xst.scarlet.ae 

Additional Information

https://fetch.spec.whatwg.org/

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

https://www.mozilla.org/en-US/security/advisories/mfsa2022-47/#CVE-2022-45411

“Thanks”

I just wanted to say a big “thanks” to the teams from whatwg, Firefox, Google and Apple, who were efficient, professional and a complete pleasure to work with. Love you long-time!