quipt (via) Extremely clever idea: Cache JavaScript in window.name (which persists between page views and can hold several MB of data), but use document.referrer to check that an external domain hasn’t loaded the cache with malicious code for an XSS attack. UPDATE: Jesse Ruderman points out a fatal flaw in the comments.
Sign in with 
OpenID
That sounds really fragile. If an attacker sets window.name, then links to a page on your site that doesn't run this script, I think it will be compromised when the user clicks a link to a page on the site that does use the script.
It won't work between tabs, so it's not as effective as localStorage. And browser developers might limit the length of window.name in the future.
Jesse Ruderman - 4th July 2008 18:53 - #
Excellent point - I'd been trying to think of a way round this but I missed that really obvious one.
Crazy as it sounds, one way you could get this working would be with public/private key cryptography - sign the JavaScript that gets cached in window.name with your private key, then have the JavaScript on the page check the signature with a public key. Unfortunately I imagine the size needed for a full RSA implementation in JavaScript would completely kill the speed benefit from caching the rest of the script!
I don't think RSA is necessary to secure this hack; a salted hash should be enough to do the trick. When the javascript is initially downloaded, a random string could be generated, temporarilly appended to to the javascript, and an md5 hash taken. Then the randomly-generated characters and the resultant hash could both be stored in a session cookie. No other page would be able to destructively interfere with window.name without detection, regardless of computing power, since they would not know the target hash. A full (gzipped) implementation of the MD5 hash algorithm in javascript only occupies 1.94kb.
henrah - 7th July 2008 08:36 - #