Tuesday, May 13th, 2008

What’s in a window.name?

Category: Security

<>p>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

Related Content:

  • What’s in your VMware toolbox?
    Every administrator needs a VMware toolbox, a set of tools, documents and scripts for any crisis. With a well-equipped VMware toolbox, you’ll be the...
  • What’s in YOUR Architecture?
    Integrating all key elements of your architecture will allow your business to meet goals and drive revenues to sustain a competitive edge in the...
  • What’s in store for IT in 2012?
    The global economy is creating an atmosphere of uncertainty in the IT sector, but what can we expect in...
  • What’s in store for SUSE Linux?
    SUSE Enterprise Linux has evolved from a company with confused direction to one that has big plans, which were announced at BrainShare 2011, including...
  • What’s in your virtualization home lab?
    A virtualization home lab is a great way to gain more experience, but it can be pricey. Even so, our advisory board thinks it’s worth the...

Posted by Chris Heilmann at 10:06 am
11 Comments

++++-
4.3 rating from 31 votes

11 Comments »

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.

Cheers

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.