On level "safer" of our security slider we want to prevent executing JavaScript if the URL bar domain is loaded over HTTP. That means even if embedded content is loaded over HTTPS it's not allowed to load and execute JavaScript that way. We used the cascadePermissions and the globalHttpsWhitelist prefs for that in the XPCOM NoScript.
ma1: I have not looked closer yet, but is this a NoScript issue or do we need to pass some particular flag to Noscript when we want that behavior in the WebExtensions world as well? We were under the impression we'd get this feature by only having frame, font, object and , other as UNTRUSTED caps on that slider level.
Huh, I could have sworn that I was able to reproduce this issue. But testing older bundles and clean 8.0.4 and 8.5a6 ones work as expected. Thus, closing this as WORKSFORME now barring some good steps to reproduce.
Trac: Resolution: N/Ato worksforme Status: needs_information to closed
Okay, I found a better URL: http://www.worldstarhiphop.com/featured/131466. It seems that the blocking works correctly if the video is not shown because of non-supported video format/MIME type (which is suddenly happening for the original URL) but that might be a coincidence.
However, I feel chances are high this needs to get fixed on the NoScript side... I reproduced the bug with Tor Browser 8.0 as well.
Trac: Description: On level "safer" of our security slider we want to prevent executing JavaScript if the URL bar domain is loaded over HTTP. That means even if embedded content is loaded over HTTPS it's not allowed to load and execute JavaScript that way. We used the cascadePermissions and the globalHttpsWhitelist prefs for that in the XPCOM NoScript.
On level "safer" of our security slider we want to prevent executing JavaScript if the URL bar domain is loaded over HTTP. That means even if embedded content is loaded over HTTPS it's not allowed to load and execute JavaScript that way. We used the cascadePermissions and the globalHttpsWhitelist prefs for that in the XPCOM NoScript.
It seems that an http page loading javascript with https using <script src="https://.../"> is correctly blocked. What is not blocked is an https iframe containing scripts, inside an http page.
An afterthough: some users are complaining that having TRUSTED subframes constrained by DEFAULT/UNTRUSTED parent document is annoying, if not disfunctional: for instance if you've set Youtube to TRUSTED, embedded movies used to work without the need of raising privileges of the parent page. One may object that you could always use "show only this frame", but do we really have a strong case here for cascading inline restrictions to trusted subdocuments? What's the threat model we're guarding against (beside clickjacking, which is orthogonal to scripting though)?
An afterthough: some users are complaining that having TRUSTED subframes constrained by DEFAULT/UNTRUSTED parent document is annoying, if not disfunctional: for instance if you've set Youtube to TRUSTED, embedded movies used to work without the need of raising privileges of the parent page. One may object that you could always use "show only this frame", but do we really have a strong case here for cascading inline restrictions to trusted subdocuments? What's the threat model we're guarding against (beside clickjacking, which is orthogonal to scripting though)?
The idea is to defend against malicious exit nodes or other attackers on the wire who want to inject and execute malicious JavaScript despite the user setting the security slider to "safer", which means (among other things) "only execute JavaScript loaded over HTTPS provided the URL bar domain got loaded over HTTPS as well".
E.g. it should not be possible that an exit node owner rewrites URLs in a document loaded over HTTP, pointing to malicious JavaScript loaded over HTTPS from a domain they control and getting that JavaScript executed in Tor Browser if the user is on "safer".
I am fine adding additional code on our side for interacting with NoScript to get that property if that helps you and other users of NoScript who where complaining.
That said, this bug got fixed with the update to NoScript 10.2.1 on master (commit b32e182633bba7733b635bc5dd0fcbd55436f4d7) and maint-8.0 (commit b35cea6792f294d0a625fde5595f1c96a8a2a72a).
(FWIW: the .xpi on AMO does not have an "an" anymore indicating it works on Android, is that intentional? Diffing 10.2.0 and 10.2.1 I think 10.2.1 should still do its job on Android, too, or am I overlooking something?)
Trac: Resolution: N/Ato fixed Status: needs_information to closed
"only execute JavaScript loaded over HTTPS provided the URL bar domain got loaded over HTTPS as well".
E.g. it should not be possible that an exit node owner rewrites URLs in a document loaded over HTTP, pointing to malicious JavaScript loaded over HTTPS from a domain they control and getting that JavaScript executed in Tor Browser if the user is on "safer".
OK, so as long as this is kept guaranteed (e.g. by checking whether the subdocument has been granted its TRUSTED status by a domain-specific rule or just by the generic "https:", as Tor does, and in the latter case enforcing this "HTTPS only" policy) we're fine, right?
I am fine adding additional code on our side for interacting with NoScript to get that property if that helps you and other users of NoScript who where complaining.
I'd actually like to at least have a sure-fire mean to tell whether we're running in the Tor Browser or not, in order to enforce special cases which are important for Tor users without affecting the general population.
(FWIW: the .xpi on AMO does not have an "an" anymore indicating it works on Android, is that intentional? Diffing 10.2.0 and 10.2.1 I think 10.2.1 should still do its job on Android, too, or am I overlooking something?)
No it was not intentional, it's just the AMO submission processwhich doesn't default to both platforms being checked anymore, making mistakes like this easier for stable releases, whose submissions cannot be automated :(
"only execute JavaScript loaded over HTTPS provided the URL bar domain got loaded over HTTPS as well".
E.g. it should not be possible that an exit node owner rewrites URLs in a document loaded over HTTP, pointing to malicious JavaScript loaded over HTTPS from a domain they control and getting that JavaScript executed in Tor Browser if the user is on "safer".
OK, so as long as this is kept guaranteed (e.g. by checking whether the subdocument has been granted its TRUSTED status by a domain-specific rule or just by the generic "https:", as Tor does, and in the latter case enforcing this "HTTPS only" policy) we're fine, right?
I think so, yes.
I am fine adding additional code on our side for interacting with NoScript to get that property if that helps you and other users of NoScript who where complaining.
I'd actually like to at least have a sure-fire mean to tell whether we're running in the Tor Browser or not, in order to enforce special cases which are important for Tor users without affecting the general population.