Drag-and-drop search causes NoScript XSS warning
Select some text and drag it onto the current tab or new tab to create a search.
Example warning:
NoScript detected a potential Cross-Site Scripting attack
from https://trac.torproject.org to https://duckduckgo.com.
Suspicious data:
(POST)
Activity
I just noticed this ticket, and confirmed that indeed the behavior does happen as described.
It looks like the intended behavior from the browser is that whatever text I drop into a tab should turn into a new search (using the default search engine).
I wonder what is triggering the noscript complaint... cross-site from where?
That's a fallout from working around https://bugzilla.mozilla.org/show_bug.cgi?id=1532530 I guess (see: #29733 (moved) for details). We'll pick the fix for that bug up with the next release and then Giorgio can remove the workaround causing this bug in NoScript. I'll leave this bug open for tracking our inclusion of that new NoScript version (which should fix this issue then).
Trac:
Keywords: N/A deleted, noscript, TorBrowserTeam201904 added
Cc: N/A to ma1-
ma1: We'll get a new Tor Browser out next week with the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1532530. Could you prepare a NoScript release without the workaround that is causing so many false positive XSS popup warnings? Thanks!
Replying to gk:
ma1: We'll get a new Tor Browser out next week with the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1532530. Could you prepare a NoScript release without the workaround that is causing so many false positive XSS popup warnings? Thanks!
Of course, thanks for the heads up. Would a NoScript release on Wednesday work for you?
-
Replying to gk:
Yes, that's perfectly fine, thanks. Sorry, I'm confused: did you already release yesterday after all? Which buildID should I look for the fix? >= "20190416010130" (per https://bugzilla.mozilla.org/show_bug.cgi?id=1532530#c19 ) or something else (the 8.5 I've just been updated to has buildID="20190307010101")? And I've just noticed https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/getBrowserInfo now exposes an isTorBrowser info property, apparently because of us (look at the "reference" link). Since when (not in 8.5 yet, apparently)?
-
Replying to ma1:
Which buildID should I look for the fix? >= "20190416010130" (per https://bugzilla.mozilla.org/show_bug.cgi?id=1532530#c19 ) or something else (the 8.5 I've just been updated to has buildID="20190307010101")?
OK, I'll assume anybody on with an up-to-date browser don't need the work around anymore, and to hell the others. Removing it unconditionally...
-
Removed the work-around in https://github.com/hackademix/noscript/releases/tag/10.6.2rc2
-
Now released as stable 10.6.2, too. https://github.com/hackademix/noscript/releases/tag/10.6.2
-
Replying to ma1:
Replying to gk:
Yes, that's perfectly fine, thanks. Sorry, I'm confused: did you already release yesterday after all? Which buildID should I look for the fix? >= "20190416010130" (per https://bugzilla.mozilla.org/show_bug.cgi?id=1532530#c19 ) or something else (the 8.5 I've just been updated to has buildID="20190307010101")? And I've just noticed https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/getBrowserInfo now exposes an isTorBrowser info property, apparently because of us (look at the "reference" link). Since when (not in 8.5 yet, apparently)?
We have a different buildID due to our reproducible builds. So, yes 8.5 is the one that needs to get out and that got out. The
isTorBrowserproperty was wrong on MDN. Someone just added that to the wiki. Thanks for tjr for correcting that. -
okay, this works for me.
bug_29969(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_29969&id=ffc98d9108cc6b420ec4cd17de475631013eecfe) has a fix for this bug (by bumping NoScript) for review.Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201905 deleted, TorBrowserTeam201905R added