[FF 4.0b7 NS 2.0.5rc3] Further questions on ABE messages

[milithruldur]

Good day.

I was trying to find more information on the ABE messages logged in the console, from the site FAQs to the manual, but failed to find one that details the format of the message. I'm particularly interested on the details of <message> contained in

Code: Select all

Anonymize on { <message> }

I somehow deduce, if it is correct, that the relationship between <func> <site1> <<< <site2> is that <site2> made the resource request to <site1> using the function <func>. With this deduction I'm able to see how the rules affect requests in between sites, and from there determine the appropriate adjustments to make. However, it seems this deduction is premature without knowing the complete details of the entire <message>, as taking for example this message log:

Code: Select all

[ABE] <^https?://(?:\w*\.)*google\.com(?:\.\w{2})?/.*> Anonymize on {GET https://www.google.com/accounts/ServiceLogin?service=datasummary&passive=900&continue=https://www.google.com/dashboard/<snip>.cache.html&followup=https://www.google.com/dashboard/<snip>.cache.html <<< https://www.google.com/dashboard/<snip>.cache.html, about:blank, about:blank - 7}
USER rule:
Site ^https?://(?:\w*\.)*google\.com(?:\.\w{2})?/.*
Accept from ^https?://(?:\w*\.)*google\.com(?:\.\w{2})?/.*
Anonymize

Going by my deduction, this request should not have been anonymized and logged by ABE because both sites specified in <func> <site1> <<< <site2> will be matched by my regex rule, and thus allowed. But this is not the case, and it seems that the succeeding details (about:blank, about:blank - 7) affected this match.

Also, ABE intercepts browser-internal url resource requests to sites that are matched by the ABE ruleset, as can be seen here:

Code: Select all

[ABE] <^https?://(?:\w*\.)*google\.com(?:\.\w{2})?/.*> Anonymize on {GET https://www.google.com/dashboard/<snip>.cache.html <<< about:blank, about:blank - 7}
USER rule:
Site ^https?://(?:\w*\.)*google\.com(?:\.\w{2})?/.*
Accept from ^https?://(?:\w*\.)*google\.com(?:\.\w{2})?/.*
Anonymize

My questions would be:

(1) Where can one find more details on ABE messages?
(2) Why did the first case not match the same site request, and how did the other parameters of the message affect this match?
(3) Seeing that ABE can match browser-internal url resource request to sites, would it be safe to allow such urls? If they are benign, being internals of the browser, then why would NoScript intercept such requests? There may be some subtle security concerns over this that I am not aware of, which I would be very glad to know.

[Giorgio Maone]

(1) Where can one find more details on ABE messages?

http://noscript.net/abe/users.html

(2) Why did the first case not match the same site request, and how did the other parameters of the message affect this match?

Because there's "about:blank" in the origin chains. Notice that it should not be there, but it happens to be because of a known Firefox 4 bug which is causing also other origin-related issues.

(3) Seeing that ABE can match browser-internal url resource request to sites, would it be safe to allow such urls? If they are benign, being internals of the browser, then why would NoScript intercept such requests? There may be some subtle security concerns over this that I am not aware of, which I would be very glad to know.

Some of these origins can be spoofed by web page, either intentionally or because of browser bugs, like in this case.

[milithruldur]

Thank you for your informative responses, as always.

I would like to think that the origin-related Firefox bug has been fixed in beta 7, but Firefox 4 has a couple more betas to go. I will try searching for this bug at Bugzilla.

After looking up the message format, and taking the first case as an example, then can I expect that the ORIGINAL_ORIGIN will always be correct, or is it affected by the bug?

Also, if I understand correctly, for a successful match to occur, the origin chains should all match the rule, and not one of the chains should be different?

Regarding the potential spoofing of these internal urls, there shouldn't be a need to ever include any of these urls when creating rules for ABE?

[Giorgio Maone]

I would like to think that the origin-related Firefox bug has been fixed in beta 7, but Firefox 4 has a couple more betas to go. I will try searching for this bug at Bugzilla.

Unfortunately it's still unfixed. You won't find it unless you've got security bugs clearance, though, because is marked as security-sensitive and therefore not public (it just affects trunk and betas, anyway).

After looking up the message format, and taking the first case as an example, then can I expect that the ORIGINAL_ORIGIN will always be correct, or is it affected by the bug?

It is affected by the bug, and there's no work-around available.

Also, if I understand correctly, for a successful match to occur, the origin chains should all match the rule, and not one of the chains should be different?

Yes: for obvious safety reasons, it's an exclusive match for Accept rules (i.e. it matches only if all the origins in the chains match) and an inclusive match for Deny rules (it matches if any of the origin matches).

Regarding the potential spoofing of these internal urls, there shouldn't be a need to ever include any of these urls when creating rules for ABE?

Usually not.

[milithruldur]

I see. Thank you once again.

And I think exclusive match for Anonymize actions too.

On to resuming ABE experimentation.