We cannot detect JavaScript redirection loops

We have code to detect redirection loops, but only if they happen via HTTP redirections. With JS redirects, things go out of control, leading to bugs like #3104 (moved) and #4285 (moved).

added component::https everywhere/eff-https everywhere owner::pde priority::high severity::normal status::new type::enhancement labels

And

https://mail1.eff.org/pipermail/https-everywhere/2011-November/001237.html

Mike/universe,

does anyone know if there's a way we can get a callback during JavaScript redirection events, in order to be able to block the ones that stupidly remove the "s" from a URL?  Or is this a question for Giorgio?

Trac:
Cc: N/A to mikeperry

Hrmmm. When I tried to find a way to recognize JS redirects way back in the Firefox 2.x days, I failed. In fact, iirc, it wasn't even possible to differentiate JS redirects from the user typing in to the URL bar, aside from having a referer present as a side channel hint.. :/

I am interested in this though. Having a solution to detect JS redirects could help me improve url origin isolation in TBB as well. Unfortunately, I'm rather short of spare dev cycles at the moment..

Could we maybe wrap the call(s) that Content uses to perform these redirects?  This seems conceptually similar to what Jonathan Mayer did withfourth party (code here) to detect fingerprinting and other nefarious JavaScript, although I think he is using Jetpack.

Hrmm, yeah, in the fourthparty code, content<->XUL IPC seems to flow through the Jetpack 'port' object (see https://github.com/fourthparty/fourthparty/blob/038c04fa90c76913754f7877337b8b72f4eadbb5/extension/data/content.js).

I think this is the Jetpack doc describing the IPC between content script and XUL context: https://addons.mozilla.org/en-US/developers/docs/sdk/1.4/dev-guide/addon-development/web-content.html

How much overhead is Jetpack, I wonder? Is it stupid to start using it just for content scripts?

Back when I wrote Torbutton's javascript content hooks, this 'port' IPC channel didn't exist, and this type of 2-way page-to-XUL communication was fraught with risk of code execution bugs due to XUL XSS.. If we decide to re-implement it, we should do so with caution to make sure we don't miss anything.

On the other hand, we'll need to make sure that the Jetpack injection loads early enough, and in all child iframes (including javascript: urls). This was a huge pain with Torbutton, and I had to write a content policy-based injector path to get all cases.. So it's also possible JetPack does a sloppy job by our standards :/.

Before we even get to that point, though, we need to make sure that window.location, meta tag creation, and form-submit based redirects (and others?) are all hookable with Object.defineProperty and/or other mechanisms. Unfortunately, when I try a quick test in the web developer console, my Firefox crashes....

Trac:
Priority: normal to major

Trac:
Type: defect to enhancement

Trac:
Sponsor: N/A to N/A
Cc: mikeperry to mikeperry, saint
Severity: N/A to Normal

mentioned in issue #6573 (moved)

mentioned in issue #7226 (moved)

mentioned in issue #7820 (moved)

mentioned in issue #8056 (moved)

mentioned in issue #8935 (moved)

moved to tpo/applications/https-everywhere-eff#4286 (closed)