Smashing the token limit with overlapping fragments (CSS injection token exfiltration, PortSwigger Research)

[u/theomkamble]

https://portswigger.net/research/smashing-the-token-limit

[u/theomkamble]

I'm a student and I read this a few times, so correct me if I got something wrong.

With a CSS injection, the stylesheet can make the browser send a request when a short chunk (like 3 characters) appears in a token. That tells you which chunks exist, but not where they are.

Alex's idea was to treat overlapping chunks like a path: c2e, then 2e1, then e16, and so on, and join them to rebuild the token. Checks for the start and end show where the path begins and ends.

In his tests, a 12-character hex token went from about 257 MB of CSS (Gareth's original generator) to 223 KB when up to five candidates are allowed. 96,398 of 100,000 randomised test URLs left five or fewer candidates. That comes from his own test harness, not from real attacks. It also needs an existing CSS injection and a token that CSS can see, like one in an attribute.

The article says recursive imports aren't needed for this. Does that change how seriously a CSS injection should be treated if it was written off before because imports were blocked?

[u/garethheyes → u/theomkamble]

Your analysis is correct and yes it fundamentally changes CSS injection since an import is no longer required to exfiltrate long hex tokens. This technique does have limitations, technically you can use it to exfiltrate tokens that have a mixture of alphaumeric characters outside the hex range but you are limited by the char space e.g. a-f0-9 vs a-zA-Z0-9, you can choose to brute-force the latter but it requires a lot of CSS for every 3 character combination.

You can reduce the enumeration to 2 combinations instead of 3 but then you are more likely to get collisions. We saw Burp AT do this automatically when it realised the CSS generated would be too large which were quite impressed with so we added to the tool.