Overlong Sec-Required-CSP header: CVE-2021-37989

It's been quite some time since I found this bug, but I thought I'd do a short post on it.

Basically, chrome added a csp attribute to <iframe> elements. What it does is as follows (from mdn):

The csp property of the HTMLIFrameElement  interface specifies the Content Security Policy that an embedded document must agree to enforce upon itself.

So, you specify a CSP, and the framed document must return that CSP (or a superset of it) in a header, or the document will fail to load.

When the document is requested (your browser sends the initial GET request), the requested CSP is sent via the Sec-Required-CSP header.

The issue at hand was – no length validation was done on this header! You could specify an arbitrarily long CSP, and send a super long request.

At first, you might wonder why this is an issue, but this has previously been an issue with the Referer (sic) header.

The gist is: it allows for a website to do cache probing - detect if certain resources have been cached by your browser.

Most webservers will return an HTTP error when the headers are too large. HTTP errors will not be cached. But, if the resource was successfully loaded previously and is in your browser's cache, the request will never be sent to the webserver in the first place (since the cache key does not depend on the presence of the Sec-Required-CSP request header)

Cache probing is not as big of an issue anymore, especially since Chrome now has a partitioned cache, but it is still possible in certain circumstances, and easy to exploit when it is. Additionally, as showcased in my UIUCTF'21 challenge pwnyide, you can also abuse long requests for other things, such as cross protocol smuggling. Read more about that in this writeup.

Chrome VRP awarded me $2k for this bug :)