Page 1 of 1
<noscript> elements on trusted sites bypassing RequestPolicy
Posted: Wed Apr 04, 2012 10:51 pm
by Thrawn
I just recently came across a situation (on addons.mozilla.org, no less), where the 'Show the NOSCRIPT element which follows a blocked script' option for trusted sites came into play. It seems that the clever ppl at AMO use this to insert a web bug for statse.webtrendslive.com if you block the full webtrendslive tracking script. Fair enough; if the tracking bothers me enough, I'll probably switch off that option.
What concerned me, though, was that RequestPolicy didn't block it either, or even show it up. I'm guessing that this is because NoScript deliberately runs after everything else, allowing RequestPolicy or Adblock Plus or Ghostery to remove things from the page first. Unfortunately, this means that a site can use NoScript to hide its tracking from those other extensions; just add a script element for evil.com, put your tracking requests inside a noscript element immediately afterward, and voila, tracking gets inserted after everything else has finished looking for it.
Is there a way to fix this without switching off that option? If not, that's OK, I can switch it off, but I wondered.
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Thu Apr 05, 2012 5:29 am
by Tom T.
Thrawn wrote:I just recently came across a situation (on addons.mozilla.org, no less), where the 'Show the NOSCRIPT element which follows a blocked script' option for trusted sites came into play. It seems that the clever ppl at AMO use this to insert a web bug for statse.webtrendslive.com if you block the full webtrendslive tracking script. Fair enough; if the tracking bothers me enough, I'll probably switch off that option.
What concerned me, though, was that RequestPolicy didn't block it either, or even show it up. I'm guessing that this is because NoScript deliberately runs after everything else, allowing RequestPolicy or Adblock Plus or Ghostery to remove things from the page first.
Correct.
Note that ABP doesn't remove the item from the page; it just prevents it from being displayed -- "annoyance-blocking" -- IIUC a recent post by Giorgio, as I'm not an ABP user.
And I see the bug:
Code: Select all
<script defer src="https://static-ssl-cdn.addons.mozilla.net/media/js/webtrends/webtrends-v0.1.js?b=23a0b43"></script>
<noscript>
<img class="hidden" id="DCSIMG" width="1" height="1"
src="https://statse.webtrendslive.com/dcso6de4r0000082npfcmh4rf_4b1e/njs.gif?dcsuri=/nojavascript&WT.js=No&WT.tv=8.6.2" />
</noscript>
So if we allow static-ssl-etc., we get the webtrends script. How nasty of MZ not to run webtrends under its own name. Almost makes you not trust those people...
And if we block that script, we get the web bug.
Unfortunately, this means that a site can use NoScript to hide its tracking from those other extensions; just add a script element for evil.com, put your tracking requests inside a noscript element immediately afterward, and voila, tracking gets inserted after everything else has finished looking for it.
Is there a way to fix this without switching off that option? If not, that's OK, I can switch it off, but I wondered.
I could be mistaken here, so I'll check with Giorgio, but IIUC, the "Show noscript element..." means, "Show it
to the user" -- something like the "alt" attribute for images, etc. ... and who is going to "see" a 1x1 image, even without the "hidden" attribute?
IOW, I don't believe that switching off the "Show" option would *block* the web bug; it would only prevent that 1x1 image from being *displayed on the screen".
I'd like Giorgio to confirm or correct me on this, but in any event, if he has a work-around, yes, we'd all love to hear about it.
And shame on Mozilla! Mass protests, everyone!
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Fri Apr 06, 2012 6:01 am
by Thrawn
I can confirm (using Tamper Data addon) that ABE can block the web bug:
Site .webtrendslive.com
Deny
I guess that's extra encouragement to push ahead with my pet project of making an addon that would use an adapted version of RequestPolicy's interface to write ABE rules
.
Is there an about:config preference to control NoScript's run-last behavior? I couldn't immediately see one, but it would fix this problem, for those who don't mind seeing NoScript placeholders for things that ABP or RequestPolicy would normally block.
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Fri Apr 06, 2012 6:16 am
by Tom T.
Thrawn wrote:I can confirm (using Tamper Data addon) that ABE can block the web bug:
Site .webtrendslive.com
Deny
Well done. Now, can you explain why *I* didn't think of that? [headbang]
I guess that's extra encouragement to push ahead with my pet project of making an addon that would use an adapted version of RequestPolicy's interface to write ABE rules
.
Yes!
Is there an about:config preference to control NoScript's run-last behavior? I couldn't immediately see one, but it would fix this problem, for those who don't mind seeing NoScript placeholders for things that ABP or RequestPolicy would normally block.
Yes.
Giorgio Maone wrote:By default, NS comes always the last: this was introduced years ago to allow ABP users to see stuff blocked later by NoScript among ABP's "Blockable objects".This is controlled by the
noscript.cp.last about:config preference: if you turn it to false, content policy execution order will depend on component registration order, which isn't always obvious.
Note the caveat at the end, which could well vary from user to user. That might be a nightmare for you, as a developer, to provide a coping mechanism.
Or not.
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Fri Apr 06, 2012 6:41 am
by Tom T.
Additional thoughts and data:
I had previously tried (after our last discussion) to block the bug by using Firefox image blocking, via
Tools > Options > Content > Load Images Automatically > add Exception for webtrends.
But Page Info context menu > Media still showed it loading.
Tried blocking it there, too, by selecting and clicking "Block images from .... etc."
Still shows the image in Page Info > Media upon leaving/return, even browser restart.
I added your ABE rule.
If we allow the script, there's no bug, but of course the script does the evil.
If we block the script, then even with your ABE rule, the image shows in View Page Info > Media.
I'm not familiar with Tamper Data add-on. Firefox is still clearly showing this image as present in the page; does TD *prove* that it's not actually called/loaded, with more certainty than the r-click View Page Info menu? Or is it, again, just "hidden" (which it already has that attribute, anyway.) Thanks.
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Fri Apr 06, 2012 11:00 am
by Thrawn
I added your ABE rule.
If we allow the script, there's no bug, but of course the script does the evil.
If we block the script, then even with your ABE rule, the image shows in View Page Info > Media.
Based on a quick test on Google, it appears that images blocked by ABE will be listed in Page Info > Media, but when you click on the entry, the image preview will not be updated; it will still show whichever image you last previewed (because the request to retrieve the image is being blocked). And when I use ABE to block the web bug, that's what I see; clicking on the web bug's entry doesn't update the preview pane. So I think it's working
.
I'm not familiar with Tamper Data add-on. Firefox is still clearly showing this image as present in the page; does TD *prove* that it's not actually called/loaded, with more certainty than the r-click View Page Info menu? Or is it, again, just "hidden" (which it already has that attribute, anyway.) Thanks.
I think it does give more certainty, yes. Tamper Data captures all HTTP requests and responses made by the browser (a bit like Wireshark). I actually came across this issue by accident when I saw the calls to webtrendslive in Tamper Data while doing something else. With the ABE rule, the calls disappear
.
Thanks for pointing me to noscript.cp.last. I've changed it...but I have no idea at this point in which order things will actually execute. Still, I don't mind NoScript placeholders. And kudos to Giorgio for making all new behaviors configurable!
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Sat Apr 07, 2012 7:31 am
by Tom T.
Thrawn wrote:I think it does give more certainty, yes. Tamper Data captures all HTTP requests and responses made by the browser (a bit like Wireshark).
A mini-Wireshark as a browser add-on? I must look into that, thanks!
And appreciate the confirmation on the rule. Ran out of donate-able time, and didn't have time to test.
Thanks for pointing me to noscript.cp.last. I've changed it...but I have no idea at this point in which order things will actually execute.
Giorgio's clue was "component registration order", but ATM, IDK where to find that (the order of registration). It wouldn't be something easy, like, say, the order listed in Profiles\*\Extensions, or the date of creation or modification -- or he'd have said so.
Firefox Help is as useless as always. Searching "component registration order" gives > 1,000 results, none of the front page being remotely related.
Guess you could try various tests of items that are normally blocked by ABP, RP, and/or NS, and see which get through which add-on -- PITA.
Anyone know where this order might be found?
Giorgio?
And kudos to Giorgio for making all new behaviors configurable!
I can't swear that 100% are, but if one would make a difference, I know he tries.
Those that are unquestionable security improvements, maybe not.
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Mon Apr 16, 2012 9:27 am
by Giorgio Maone
The component registration order has no bearing here, since the <NOSCRIPT> element forced display does not happen during the ContentPolicy round call (that's where multiple implementation can compete for "seen and handled first").
What NoScript does is just scanning for script elements after the page finishes loading and reinserting the disabled <NOSCRIPT> content where needed, just like any content script could do by itself.
If RequestPolicy can't see it, that looks like a RequestPolicy bug.
Re: <noscript> elements on trusted sites bypassing RequestPo
Posted: Tue Apr 17, 2012 9:22 am
by Tom T.
Justin Samuel is
already aware of the issue.
Response:
by Justin Samuel (Developer) on April 9, 2012 ยท permalink
Thanks for noticing this. This is probably due to addons.mozilla.org being treated differently by RequestPolicy to avoid breaking parts of Firefox. More info here:
https://github.com/RequestPolicy/reques ... issues/185
Link to the github thread.
Apparently, only the following sites are affected:
Code: Select all
http(s)://download.mozilla.org/
http(s)://addons.mozilla.org/
http(s)://releases.mozilla.org/
... and this was necessary to avoid breaking Fx updates.
No other sites could exploit this. That is some comfort, but considering that AMO itself is implanting web bugs....
Giorgio, can you talk them out of this? (AMO web bugs)