Closed Bug 1348270 Opened 9 years ago Closed 8 years ago

window.name transfers across Origins

Categories

(Core :: DOM: Security, defect, P3)

52 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 444222

People

(Reporter: afanen01, Unassigned)

Details

(Whiteboard: [domsecurity-backlog1])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 OPR/43.0.2442.1165 Steps to reproduce: * In Firefox 52 (tested), if you set window.name, this data persists across browser origins. Example, if you go to mozilla.org and set via the javascript console: window.name = 'Evil Code'; And then navigate to google.com and type: window.name in the console, you will get 'Evil Code' back. Actual results: javascript set a variable that persisted across different and unrelated origins. This can potentially be an avenue for XSS considering that when you iterate over an Object using 'with', and obj.name doesn't exist, it is translated into window.name. So a malicious site (say evil URL shortener) could set window.name = "some javascript" and then when users happen to land on a website which is creates a DOm node based on object.name, then you find yourself potentially with code injected across browser origins, seemingly from a script running from the correct origin. I can't reproduce this behaviour in Latest Opera browser. Expected results: the window.name should be reset on navigation, or alternatively: window.name='chunk'; var point = {'x': 9, 'y': 99}; with (point) { console.log(name) } should not produce "chunk" as output. [disclosure: i'm not the one who discovered this]
i was too hasty perhaps. I think the example i gave in expected results is not valid. However, the point remains that window.name can carry across origins in Firefox, and this is a vector for XSS.
Group: firefox-core-security → core-security
Component: Untriaged → DOM
Product: Firefox → Core
This is historical and spec'd behavior so it doesn't need to be a hidden bug. It's also known as a potential source of "DOM XSS" and unintentional data leakage across domains. The standards groups are discussing whether or not to null out window.name on navigation and maybe some browsers are already experimenting with this. However, there are some sites relying on historical behavior that will break so it's an interesting juggling act.
Group: core-security
Component: DOM → DOM: Security
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Daniel, it's not specified as such actually. The HTML Standard requires resetting it when you navigate across origins. Safari removed it already and it seems like Chrome is following.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.