window.name can be used as an XSS attack vector
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox82 | --- | fixed |
People
(Reporter: johnhoogstrate, Assigned: timhuang)
References
(Blocks 3 open bugs)
Details
(Keywords: dev-doc-needed, parity-safari, Whiteboard: [tor][tor-standalone][tor 16620][domsecurity-backlog1] , [wptsync upstream])
Attachments
(10 files, 12 obsolete files)
19.87 KB,
patch
|
Details | Diff | Splinter Review | |
34.61 KB,
patch
|
Details | Diff | Splinter Review | |
1.22 KB,
text/html
|
Details | |
669 bytes,
application/x-xpinstall
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Comment 1•17 years ago
|
||
Comment 3•17 years ago
|
||
Comment 5•17 years ago
|
||
Comment 8•17 years ago
|
||
Comment 11•17 years ago
|
||
Updated•17 years ago
|
Comment 12•17 years ago
|
||
Updated•17 years ago
|
![]() |
||
Comment 14•17 years ago
|
||
![]() |
||
Comment 15•17 years ago
|
||
![]() |
||
Comment 17•17 years ago
|
||
Comment 18•17 years ago
|
||
![]() |
||
Comment 19•17 years ago
|
||
![]() |
||
Comment 20•17 years ago
|
||
Comment 21•17 years ago
|
||
Comment 24•17 years ago
|
||
Comment 26•16 years ago
|
||
![]() |
||
Comment 27•16 years ago
|
||
Comment 28•16 years ago
|
||
![]() |
||
Comment 29•16 years ago
|
||
Comment 30•16 years ago
|
||
Comment 31•16 years ago
|
||
![]() |
||
Comment 32•16 years ago
|
||
![]() |
||
Comment 34•16 years ago
|
||
Comment 35•16 years ago
|
||
![]() |
||
Comment 36•16 years ago
|
||
Comment 37•16 years ago
|
||
![]() |
||
Comment 38•16 years ago
|
||
![]() |
||
Comment 39•16 years ago
|
||
Comment 40•16 years ago
|
||
Updated•16 years ago
|
Comment 41•16 years ago
|
||
![]() |
||
Comment 42•16 years ago
|
||
Comment 43•16 years ago
|
||
![]() |
||
Comment 44•16 years ago
|
||
Comment 45•16 years ago
|
||
![]() |
||
Comment 46•16 years ago
|
||
Comment 47•16 years ago
|
||
![]() |
||
Comment 48•16 years ago
|
||
Updated•16 years ago
|
Comment 49•16 years ago
|
||
Comment 50•16 years ago
|
||
Updated•16 years ago
|
![]() |
||
Comment 51•16 years ago
|
||
Comment 52•16 years ago
|
||
Updated•16 years ago
|
![]() |
||
Comment 53•16 years ago
|
||
Comment 54•16 years ago
|
||
![]() |
||
Comment 55•16 years ago
|
||
![]() |
||
Updated•16 years ago
|
![]() |
||
Updated•16 years ago
|
Comment 56•16 years ago
|
||
![]() |
||
Comment 57•16 years ago
|
||
Comment 58•16 years ago
|
||
Comment 59•16 years ago
|
||
![]() |
||
Comment 60•16 years ago
|
||
Comment 61•16 years ago
|
||
Comment 62•16 years ago
|
||
Comment 63•16 years ago
|
||
![]() |
||
Comment 64•16 years ago
|
||
Comment 65•11 years ago
|
||
Comment 66•11 years ago
|
||
Comment 68•11 years ago
|
||
Updated•11 years ago
|
Comment 69•11 years ago
|
||
Comment 70•11 years ago
|
||
Comment 71•11 years ago
|
||
Comment 72•11 years ago
|
||
Comment 73•11 years ago
|
||
Comment 74•10 years ago
|
||
![]() |
||
Updated•10 years ago
|
Comment 75•10 years ago
|
||
Comment 76•10 years ago
|
||
Comment 77•10 years ago
|
||
Comment 78•10 years ago
|
||
Comment 79•10 years ago
|
||
Comment 80•10 years ago
|
||
Comment 81•10 years ago
|
||
Comment 82•10 years ago
|
||
Comment 83•8 years ago
|
||
Updated•8 years ago
|
Updated•8 years ago
|
Comment 84•8 years ago
|
||
Comment 85•8 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 87•7 years ago
|
||
Comment 88•7 years ago
|
||
Updated•7 years ago
|
![]() |
||
Comment 89•7 years ago
|
||
Comment 90•7 years ago
|
||
Updated•7 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 91•5 years ago
|
||
Updated•5 years ago
|
Comment 92•5 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 94•4 years ago
|
||
Depends on D81335
Assignee | ||
Comment 95•4 years ago
|
||
Depends on D81361
Assignee | ||
Comment 96•4 years ago
|
||
Depends on D88416
Updated•4 years ago
|
Assignee | ||
Comment 97•4 years ago
|
||
Depends on D88417
Comment 98•4 years ago
|
||
Comment 100•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0d63bc41097d
https://hg.mozilla.org/mozilla-central/rev/ec03ae5444a2
https://hg.mozilla.org/mozilla-central/rev/99b73703fc41
https://hg.mozilla.org/mozilla-central/rev/b9293b1ffe1c
https://hg.mozilla.org/mozilla-central/rev/0301da1359e0
https://hg.mozilla.org/mozilla-central/rev/a2e9a24387c2
Comment 102•4 years ago
|
||
Hi Tim,
Can I please confirm my interpretation of what the implementation ended up as (for docs):
- window.name is shared among all tabs/pages that use the window, meaning that any site opened in the same window can potentially access information stored in this field. This "feature" is being leveraged by frameworks for cross-domain sharing.
- The main change is that if a page opens a document in another domain, the
window.name
is reset to an empty string. The new document then can't get whatever data was stored in the original. - There are associated changes to ensure that navigation still works - ie if a user select the original tab or navigates back then the window.name is restored.
I'm a bit confused because the original discussion was around having page-specific window names. I THINK that what has happened is that there is still a global window.name
for the window, but now if a new page was created programmatically the value is cleared. However if you got back to the original page it is restored. Also if a new page was created by a user in the same window and then assigned to another domain, does it also have the window name reset.
Assignee | ||
Comment 103•4 years ago
|
||
(In reply to Hamish Willee from comment #102)
Hi Tim,
Can I please confirm my interpretation of what the implementation ended up as (for docs):
- window.name is shared among all tabs/pages that use the window, meaning that any site opened in the same window can potentially access information stored in this field. This "feature" is being leveraged by frameworks for cross-domain sharing.
There is something inaccurate here. The window.name is for the content window, not the chrome window. So, it is only shared among pages in one tab.
- The main change is that if a page opens a document in another domain, the
window.name
is reset to an empty string. The new document then can't get whatever data was stored in the original.- There are associated changes to ensure that navigation still works - ie if a user select the original tab or navigates back then the window.name is restored.
I'm a bit confused because the original discussion was around having page-specific window names. I THINK that what has happened is that there is still a global
window.name
for the window, but now if a new page was created programmatically the value is cleared. However if you got back to the original page it is restored. Also if a new page was created by a user in the same window and then assigned to another domain, does it also have the window name reset.
We follow the spec when doing the reset/restore window.name. As I mentioned above, the window.name is per content window, so pages will have separate window.name if they are in different tabs. We don't reset the window.name when there is a new page created in a different tab since it is a separate one. We only do reset/restore when we navigate in a tab. Back to your question, yes, we reset the window.name if a user navigate the content window to another domain
Comment 104•4 years ago
|
||
I'm still noticing that window.name can be used as an XSS attack vector.
My web-browser version: Firefox Browser 84.0.1 (64 bits) on Windows 10.
The attack reproduction:
-
Open: http://www.fit.vutbr.cz/~polcak/nnnnn.html
The window.name property is set to the value "uni". -
Open in the same tab: http://rover.borec.cz/
The value of the window.name property is written on the web page and is "uni", although window.name should have been reset.
If I understand correctly, websites should not be able to share value through the window.name property. But that is exactly what I managed to achieve. Has this security bug really been resolved?
Comment 105•4 years ago
|
||
We haven't shipped this to release yet, see https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#9408. I'll file a bug on doing that since we haven't encountered any problems.
Description
•