Defined Misbehaviour

Web security, programming, reverse-engineering, and everything related.

Bypassing RequestPolicy’s Whitelist Using the Jar: URI Scheme

Here’s an interesting bug I found while looking at some cross-domain data-stealing issues. It’s possible to bypass RequestPolicy’s whitelist entirely by referencing a resource nested in a jar URI:

Exfiltration example
<img src="jar:!/foobar" />

Firefox will block the resource from being displayed even if it is valid (due to prior security issues with the jar URI scheme,) but a cross-domain request is made and it doesn’t require JS to execute. This can be verified through the network pane in Firefox’s dev tools. A limited amount of information may be sent back from the server by using timing information.

Requests to jar URIs don’t get processed by RequestPolicy because aContentLocation’s asciiHost is undefined when the jar URI scheme is used, and it gets treated as an internal request. Since all internal requests are implicitly allowed, the request goes through.

I emailed Justin the patch a few months ago, but he hasn’t responded. Hopefully this gets fixed on the version soon, since it limits RequestPolicy’s effectiveness at preventing data exfiltration.

For now, you can use my fork of RequestPolicy. I’m not sure if the patch has any interactions with extensions, but it should also fix issues with nested use of the view-source scheme (which for some reason doesn’t implement nsINestedURI)


If you’d like to see whether or not you’re vulnerable, I’ve made a Proof-of-Concept that detects whether or not RequestPolicy blocked an image from a jar URI.

Without the patch:

With the patch: