window.name is persistent across torbutton toggle

If window.name is assigned by a website, it's value can be read by any JavaScript running in the same tab at any point in the future, regardless of what website the JavaScript is from.

Trac:
Username: katmagic

added MikePerryIteration20110305 TorbuttonIteration20110305 actualpoints::6 component::applications/torbutton owner::mikeperry points::8 priority::immediate reporter::katmagic resolution::fixed severity::normal status::closed type::defect version::torbutton 1.2.5 labels

It should be noted that window.name persists even when TorButton is toggled.

Trac:
Username: katmagic

Trac:
Priority: major to critical
Points: N/A to N/A

Do we have a simple repro page so I can test mitigations against this?

Reproduce: 1 Test fixes: 5 Cleanup: 2

Trac:
Points: N/A to 8

Test this in conjuction with bug #2465 (closed).

@mikeperry: http://samy.pl/evercookie/

Trac:
Username: katmagic
Actualpoints: N/A to N/A

Trac:
Priority: critical to blocker
Keywords: N/A deleted, TorbuttonIteration20110305 added

Trac:
Keywords: TorbuttonIteration20110305 deleted, TorbuttonIteration20110305 MikePerryIteration20110305 added

Just as an FYI, I did a quick hack to fix this by adding a 'window.name = null;' in jshooks.js.

The problem is that these hooks are not injected on Non-Tor pages, so window.name will still survive from Tor -> Non-Tor with this fix. Blech.

This means we have to reach in and directly manipulate the page DOM from extension-land. Fun, dangerous, and exciting.

Why not using the already implemented request observer? You could get the associated window (if there is any) with callbacks and check whether window.name is set and if so AND the user is requesting a new domain just reset it.

Trac:
Cc: N/A to g.koppen@jondos.de

gk: Two reasons:

1. My understanding though is that the wrappedJSObject that window lives in has changed behaviors in FF3.5 -> FF4.0. So it requires some extra testing for each one.

2. We only want to reset this property if there has been a torbutton state change, I believe. Which means we need to find the relevant content window during the toggle phase, rather than the observer.

We want to do this on Toggle because that is the codepath that is used for resetting browser state. I think we want to allow window.name to live for a single Tor session (or until the timer from #523 (closed) goes off).

Replying to mikeperry:

gk: Two reasons:

1. My understanding though is that the wrappedJSObject that window lives in has changed behaviors in FF3.5 -> FF4.0. So it requires some extra testing for each one.

2. We only want to reset this property if there has been a torbutton state change, I believe. Which means we need to find the relevant content window during the toggle phase, rather than the observer.

We want to do this on Toggle because that is the codepath that is used for resetting browser state. I think we want to allow window.name to live for a single Tor session (or until the timer from #523 (closed) goes off).

I'd definitely say that it should be reset every time a new domain is requested. I can't see any reason why someone would want it to persist between sites. It seems much cleaner to clear it.

Trac:
Username: katmagic
Cc: g.koppen@jondos.de to g.koppen@jondos.de, the.magical.kat@gmail.com

Trac:
torbutton-1.3.2pre5-alpha.xpi

Clear window.name on toggle

Ok, that attachment should clear the window.name attribute on toggle. It ended up being easy to toss in to where we also silence js events on the tab.

The .xpi is based off of fef8cb176662120197bf10d955c1175c1dad82a2 of origin/master.

Let me know if it has any issues.

Trac:
Status: new to needs_review

Replying to katmagic:

Replying to mikeperry:

We want to do this on Toggle because that is the codepath that is used for resetting browser state. I think we want to allow window.name to live for a single Tor session (or until the timer from #523 (closed) goes off).

I'd definitely say that it should be reset every time a new domain is requested. I can't see any reason why someone would want it to persist between sites. It seems much cleaner to clear it.

I don't think we want to mess with how this property works by default. I can envision websites breaking in the odd corners of the web if we try to disable window.name entirely.. I could also see using the same origin policy definitions to reset window.name to make this break less.. This would be a good option for NoScript, or a hidden Torbutton option, but I still don't think it should be a default.

I can see clearing window.name and any other state data periodically by default, a-la #523 (closed), if we can figure out a way to do that without causing users to perceive breakage.

If we want to create an option to apply the same-origin policy to window.name, that should be another ticket. I would like to use this ticket to only apply to window.name being persistent across tor toggle, which is a more serious problem, and a violation of Torbutton's security requirements: https://www.torproject.org/torbutton/en/design/#requirements

Trac:
Summary: window.name is persistent across websites to window.name is persistent across torbutton toggle

I created #2669 (closed) to note the same origin policy plan. However, I don't think it is one we want to do, and that we want something explicit handling this instead, like #523 (closed).

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Actualpoints: N/A to 6

Set all tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

closed

changed time estimate to 64h

added 48h of time spent

mentioned in issue #2465 (closed)

mentioned in issue #2591 (closed)

mentioned in issue #4364 (closed)