Opened 8 years ago

Last modified 3 years ago

#4286 new enhancement

We cannot detect JavaScript redirection loops

Reported by: pde Owned by: pde
Priority: High Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: mikeperry, saint Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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 and #4285.

Child Tickets

#3104defectclosedpdeInfinite loops in Facebook settings pages
#6573defectclosedpdeJS redirect loop for
#7226defectclosedpdeCitibank Australia website gets stuck in endless HTTPS->HTTP->HTTPS redirection broken on Chrome
#8848defectclosedpdeJS redirection loop on tinychat
#8935defectclosedpdeendless redirects on subdomain

Change History (8)

comment:2 Changed 7 years ago by pde

Cc: mikeperry added


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?

comment:3 Changed 7 years ago by 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..

comment:4 Changed 7 years ago by pde

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.

comment:5 Changed 7 years ago by mikeperry

Hrmm, yeah, in the fourthparty code, content<->XUL IPC seems to flow through the Jetpack 'port' object (see

I think this is the Jetpack doc describing the IPC between content script and XUL context:

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....

comment:6 Changed 7 years ago by pde

Priority: normalmajor

comment:7 Changed 5 years ago by jsha

Type: defectenhancement

comment:8 Changed 3 years ago by saint

Cc: saint added
Severity: Normal
Note: See TracTickets for help on using tickets.