Tuesday, May 13th, 2008

What’s in a window.name?

Category: Security

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 to false, this just sees to that you don’t get any other sites window.name garbage inside your sessvars by mistake. The actual data you set will be available for other scripts on other domains to look at – and also to anyone able to type javascript:alert(window.name) in the browser’s address bar

Posted by Chris Heilmann at 10:06 am

4.3 rating from 31 votes


Comments feed TrackBack URI

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.

Comment by PaulIrish — May 13, 2008

how long before this security hole is plugged in all real browsers though?

Comment by Jamie — May 13, 2008

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.

Comment by timwhunt — May 13, 2008

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.


Comment by KevinWeibell — May 13, 2008

A little hackish but it’s a pretty clever idea! Good example of “thinking outside the box”.

Comment by JeromeLapointe — May 13, 2008

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

Comment by arapehl — May 13, 2008

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.

Comment by ibolmo — May 13, 2008

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.

Comment by Jordan — May 13, 2008

@KevinWeibell: +1
Andrea Giammarchi blogged about this more than one year ago…

Comment by paftek — May 14, 2008

Is this a security vulnerability (or information leakage)? It seems to me to be merely a way for consenting pages to pass information.

Comment by newz2000 — May 14, 2008

The interesting thing to note about window.name is that it:

1) Persists within across page refreshes, and
2) is specific to a tab

This allows us to provide tab-specific information while using a site. Without this hook it becomes quite difficult for a user to have multiple tabs open into the same site under the same session and have them not interfere with each other. Some web frameworks specifically address this issue, but are quite heavy and do so by adding information to all internal links, however this breaks when a user right-clicks and opens a new tab on a link.

Comment by tourque3000 — March 23, 2011

Leave a comment

You must be logged in to post a comment.