Exploiting POST-based XSSI
We know, more and more client-side attacks are dying. But sometimes, with introduction of new features, an unexploitable becomes exploitable. Yes, combined with the power of Service Worker, XSSI is no longer limited to GET requests.
This essentially means we can also include resources with POST requests and CORS-safelisted headers. The idea is simple- intercept the request and modify to send no-cors POST request. For demonstration purpose, I’ve built a rough POC at https://cm2.
Forging Content-Type Header With Flash
You might already know how you can forge HTTP request headers using flash. So, to keep it short, I’m talking about Content-Type only.
Lately, I’ve been seeing tweets & reports about CSRF attack involving JSON data. In fact, I saw a tweet asking if it was safe to rely on Content-Type: application/json for CSRF protection. And, going through the replies, I found it was concluded safe- because browsers don’t yet support application/json in HTML form submission.
Referrer Policy
There are, atm, 5 different ways referrer policy can be delivered as defined by W3C. Setting referrer policy via meta is supported by all modern browsers (as shown above). The other ones, however, are new and aren’t widely supported or used.
The HTML Standard defines the concept of referrerpolicy attributes which applies to several of its elements, for example:
<a href="http://example.com" referrerpolicy="origin"> In general, the order in which these signals are processed are