imported trac comment
created: 2009-11-10 17:44:38
author: justin

I actually missed the specific problem the user was pointing out, which isn't cross-site request from images and such but rather link clicks. The origins of link clicks are moz-nullprincipal:, such as:

• moz-nullprincipal:{bd2a 1e0b-82f6-4078-af6b-4f5 356 256e 79}

I have this comment in [browser:src/components/requestpolicyService.js?rev=289%3A0d3416431910#L1438 _isInternalRequest in requestpolicyService.js]:

{{{
// Note: Don't OK the origin scheme "moz-nullprincipal" without further
// understanding. It appears to be the source when test8.html is used. That
// is, javascript redirect to a "javascript:" url that creates the entire
// page's content which includes a form that it submits. Maybe
// "moz-nullprincipal" always shows up when using "document.location"?
}}}

Plus, the way things currently are it doesn't appear to be possible for a user to work around this by whitelisting the origin 'moz-nullprincipal:', anyways, because of:

{{{
[RequestPolicy] [INFO] [INTERNAL] Unable to getIdentifier from uri moz-nullprincipal:{bd2 a1e0b-82f6-4078-af6b-4f53 5625 6e79} using identifier level 1
}}}

Another note: that uuid seems to change with each click of a given link. Just figured I'd mention this as it may be important when looking into this again.

In short, as it stands, there is no workaround at all at the moment for enabling link clicks from pages or diffs stored by Update Scanner, other than "temporarily allow all requests".

Note: edited comment to break up nullprincipal addresses that might look like revisions. Bug in mercurial trac: http://trac.edgewall.org/ticket/8927

imported trac comment
created: 2009-11-19 08:18:23
author: updatescanner

A good summary Justin - thanks for looking into this.

As you mentioned, the requests are coming from a !data:// URL in an iframe, so it's difficult for you to identify whether they are safe.

Using a !data:// URL has been the only secure solution I've been able to find to display untrusted content inside a chrome iframe. It is a slightly unusual solution however, and has caused a few extension conflict problems. I'd be eager to hear any other ideas you might have to do this (my email is attached).

Pete

imported trac comment
created: 2011-02-11 17:32:16
author: justin

The problem with link clicks from Update Scanner webpage versions/diffs being blocked has been resolved as of !RequestPolicy 0.5.17. Specifically, r380 and r381 (the fix for #134) translates moz-nullprincipal origins to the true origin so !RequestPolicy can use the true origin to determine if the request was from a link click.

The remaining conflict with Update Scanner, afaik, is that there is no way to selectively whitelist requests made when viewing a specific version or diff with Update Scanner. One can allow most of these requests by whitelisting the origin about:blank. Whitelisting the origin about:blank will open up the ability for malicious or crafty sites to bypass !RequestPolicy, but arguably if one is going to disable RP because of the conflict with Update Scanner, one might as well just allow the origin about:blank and get the rest of the protection that RP can offer.

imported trac comment
created: 2011-02-11 17:33:55
author: justin

One more problem I'm aware of: the !RequestPolicy menu gets confused/confusing sometimes when viewing versions/diffs with Update Scanner.

imported trac comment
created: 2011-02-13 15:37:41
author: justin

Fixed in r407 and r408.

This solution is a combination of:

• When RP's nsIContentPolicy::shouldLoad implementation is called, try to convert origins of "about:blank" to something more useful by looking in the context argument. In the case of Update Scanner (and probably others), this allows converting "about:blank" origins to the corresponding "data:text/html..." document that actually originated the request.
• Consider "data:[MIME-type]" to be a URI identifier. RP used to use the entire data URI as an identifier by not giving it special treatment and allowing the URI identifier determination to fail.
• Add a concept of top-level document translation rules. This allows RP to decide to pretend that the current tab's top-level document URI is different than it actually is.
• Add a top-level document translation rule for Update Scanner that pretends that document URIs starting with "chrome://updatescan/content/diffPage.xul" are actually just "data:text/html".
• Rely on some unintuitive implementation details of RP that, when combined with these changes, allow the correct destinations to be shown in the RP menu when viewing Update Scanner diff pages (partly explained in r408).

I tried to make these changes as general as possible in the hope that they would be applicable in cases other than Update Scanner.

I don't doubt there may be other conflicts with Update Scanner or blocked requests that turn out not to be easy to whitelist. Separate tickets should probably be opened for those issues unless the current changes aren't really working as well as I believe they are.

Note that I see some different behavior with Firefox 3.6.13 + Update Scanner 3.1.3 (most recent for Firefox 3) vs. Firefox 4.0b12pre + Update Scanner 3.1.4 (most recent for Firefox 4). I don't know if these differences are due to Firefox changes or Update Scanner changes. The major difference I've seen is that the RP menu with Firefox 3 + Update Scanner 3.1.3 doesn't show individual destinations but one can still "temporarily allow all from data:text/html". When using Firefox 4 with Update Scanner 3.1.4, one does see the individual destinations and can "temporarily allow all from data:text/html to example.com". Given that the better behavior is on Firefox 4, I'm not inclined to look into this further nor to try to fix this for Update Scanner + RP on Firefox 3.

imported trac comment
created: 2011-02-13 17:07:02
author: justin

These changes are included in !RequestPolicy 0.5.19a2.

https://www.requestpolicy.com/releases/requestpolicy-0.5.19a2.xpi