Tuesday, May 13th, 2008
What’s in a window.name?
Sometimes it is interesting to see that knowledge from the 10,000 B.C. period of web development can be used in new ways to create - to play it safely - interesting ideas.
Each window in a browser has a name property which became pretty much useless when we stopped using pop-up windows and tried to make them communicate with each other by name.
Thomas Frank, however wrote a small library that uses window.name to store session variables without having to resort to cookies and his research seems to prove that you can store up to two megabytes of data in window.name. As this property is available across page reloads it is a sort of session, but as the comments show the security aspects of it are just scary:
There is a cross domain flag in
sessvars, but although it defaults tofalse, this just sees to that you don’t get any other siteswindow.namegarbage inside yoursessvarsby mistake. The actual data you set will be available for other scripts on other domains to look at – and also to anyone able to typejavascript:alert(window.name)in the browser’s address bar












Picked this up from Leslie Orchard’s del.icio.us a few days ago. Can’t believe it hadn’t surfaced before now!
This is huge.
Not to mention the ability it affords us in cross-domain messaging without iframe hacks or anything.
how long before this security hole is plugged in all real browsers though?
This is really useful, thanks for pointing it out!! However, I almost missed it because the title of the post was “clever” rather than informative.
Don’t want to spoil all the fun… but this is not that new of a thing. Check out Andrea Giammarchi’s JSTONE and Web RAM.
Cheers
A little hackish but it’s a pretty clever idea! Good example of “thinking outside the box”.
The fact that other sites could read the data without difficulty is a major issue and could keep this from ever really being used as a cookie replacement.
It could however be used as a state manager for Ajax/Flash apps that track movements throughout an app by storing the current state in an iframe/url hash combination (re: YUI History Manager).
I’m still surprised by the security threats that everyone is afraid of. It’s only an issue if someone uses window.name. Don’t make the world spin on a dime, when there’s bigger issues out there.
There are some obvious problems to this:
1) If the user opens a page in another tab, the window name is lost.
2) If a script on the page, maybe an advertisement script or what not, creates a global variable with the name “name”, it will override the window.name variable.
@KevinWeibell: +1
Andrea Giammarchi blogged about this more than one year ago…
Is this a security vulnerability (or information leakage)? It seems to me to be merely a way for consenting pages to pass information.