Requests via javascript: violate FPI

With your nightlies http://f4amtbsowhix7rrf.onion/reports/r/tor-browser-2017-06-05/tor-browser_build.html click the link

javascript:togglecontent('test_nightly-linux-x86_64');

near the red cross and get

Torbutton INFO: tor SOCKS: http://f4amtbsowhix7rrf.onion/reports/r/tor-browser-2017-06-05/test_nightly-linux-x86_64 via
                       --unknown--:b3bb40be24aec95a7d8c35608707fc28

added TorBrowserTeam201709R in Legacy / Trac component::applications/tor browser in Legacy / Trac noscript in Legacy / Trac owner::pospeselr in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac severity::major in Legacy / Trac status::closed in Legacy / Trac tbb-linkability in Legacy / Trac type::defect in Legacy / Trac labels

Nice catch! This happens for me with Tor Browser 6.5.2 already it seems.

Trac:
Severity: Normal to Major
Priority: Medium to High

I guess this is due to javascript:, adapting the summary accordingly.

Trac:
Summary: Some requests violate FPI to Requests via javascript: violate FPI

You were asking about new issues so persistently on tor-qa (as if you lack them :) that I couldn't pass by :) How many new issues will be enough for you? What are you going to do with all of them?

Replying to cypherpunks:

You were asking about new issues so persistently on tor-qa (as if you lack them :) that I couldn't pass by :) How many new issues will be enough for you? What are you going to do with all of them?

We'll try to get them fixed. Just let them coming.

Trac:
Owner: tbb-team to pospeselr
Status: new to assigned

Extra repro step, need to set security slider to 'Medium'

So the problem here is NoScript with 'noscript.global' preference enabled (hence why only happens when in Medium or Higher security setting).

When an element is clicked and the href attribute starts with 'javascript:' NoScript tries to heuristically extract a URI from the source by looking for a string between " or ' characters that does not contain invalid URI characters ( https://github.com/avian2/noscript/blob/8e12f5ce4f2ddf169da3867ca80323cbbd789948/xpi/chrome/content/noscript/Main.js#L4168 ) and uses that as the href string instead, passing this new href on to an XMLHttpRequest at which point everything happens as normal.

It will interpret the href as relative to the document's URI, unless the href is itself an absolute URL (per https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService#newURI() ).

This has some really cool consequences such that this element will go to github when clicked with NoScript enabled:

Hello!

proof: https://pste.eu/p/pWdf.html

Thanks for tracking this down. Giorgio: could you have a look at that one? I guess the intended behavior is: if we need to issue a request due to clicking on a javascript: link then it should adhere to our first-party isolation. That probably means NoScript itself should not issue that request as this is treated as a browser internal request which gets put onto the catch-all circuit (due to lack of URL bar domain information).

Does that make sense to you, Giorgio?

Trac:
Keywords: N/A deleted, noscript added
Status: assigned to needs_information
Cc: N/A to ma1

It's the "Attempt to fix Javascript links" (noscript.fixLinks in !about:config) feature.

Do you need me to modify the HEAD XHR preflight request in order to fit into your navigation restrictions, or to omit it outright? Or would it be better for you to just flip the preference?

Replying to ma1:

It's the "Attempt to fix Javascript links" (noscript.fixLinks in !about:config) feature.

Do you need me to modify the HEAD XHR preflight request in order to fit into your navigation restrictions, or to omit it outright? Or would it be better for you to just flip the preference?

It seems to me flipping the preference might not be that bad. Richard: can you take a look whether that could be a viable way for solving our issue (without introducing other unintended ones)?

Trac:
Status: needs_information to assigned

So the noscript.fixLinks will disable the custom onclick handler (which is what does the above described behaviour) but also disables a custom onchange handler (for select and option elements).

However, for Tor Browser that's a good thing, as it has a similar feature whereby it will automatically try to navigate to a selected option if it looks like a URL (the threshold for 'looks like a URL' is even lower though: value contains '/' or '.' and does not contain '@'). This URL will try to be navigated through the same code-path, so would have the same browser internal request gk mentioned.

Updating TorButton to set turn off the noscript.fixLinks option should work, will have a patch up in a bit.

Trac:
22501-pospeselr0.patch

disables NoScript's fixLinks feature

Trac:
Keywords: N/A deleted, TorBrowserTeam201709R added

No, that's for Security Slider options only.

Trac:
Status: assigned to needs_revision
Keywords: TorBrowserTeam201709R deleted, TorBrowserTeam201709 added

Replying to cypherpunks:

No, that's for Security Slider options only.

What else needs to be modified? NoScript settings don't seem to be currently set in torbrowser's 000-tor-browser.js config file.

Trac:
22501-tor-browser-build-0.patch

Put noscript.fixLinks option override in per-platform extension-overrides.js rather than torbutton (since it does not change)

Verifying works as intended with rbm build.