This used to trouble me with IE and Mozilla. The window.history object is protected from reading for obvious reasons, however, try this :- 1. On a page call any of the following (or all) window.history[58769]="This is a history hijack attempt"; window.history[window.history.length]="this is another hijack"; window.history[0]="This is history 1"; 2. On another page attempt to read window.history[58769], [0], or [length-1] The result - data transfered across pages. (This also used to be considered a security problem, so much so that MS went to great lengths to stop you doing such things without cookies) A trivial 'problem' - but one that a malicious page writer could exploit to gain information. (I won't elaborate on the details) Just interested in your thoughts on whether or not this is a bug.
Created attachment 6331 [details] quick page to setup history object exploit A quick example of window.history persisting across pages
I can verify that Safari does persist the data, whereas FF doesn't. It's not immediately clear to me why this is a vulnerability. A malicious site can only read the data if another site has explicitly made it available.
(In reply to comment #2) > I can verify that Safari does persist the data, whereas FF doesn't. It's not > immediately clear to me why this is a vulnerability. A malicious site can only > read the data if another site has explicitly made it available. NOTE: I have NOT tested any of these theories (since I'm not in front of my PowerBook G4 at the moment). 1. Can some sort of denial of service attack may be launched to consume memory? <script> for (i = window.history.length; 1 == 1; i++) { window.history[i] = "...a really, really long string..."; } </script> 2. Can the index for window.history[] be overflowed if it's willing to accept any index value? <script> window.history[2147483647] = "INT_MAX"; window.history[2147483647+1] = "INT_MAX+1"; </script> 3. Can a "future" history item be added to window.history[] and then window.history.forward() or javascript:goForward() be used to run it? <script> window.history[window.history.length] = "javascript:alert('Hello world!');"; window.history.forward(); </script> 4. The window.history[] array provides a cross-site scripting (XSS) attacker a large storage space for keeping cookie values or usernames/passwords. If the attacker can plant XSS code to store sensitive data (such as session cookies) in the history array, they can store a lot of information that could be sent if they are able to trick the user into visiting a "harvesting" site later. http://www.cert.org/advisories/CA-2000-02.html I do remember the original brouhaha about the window.history issue in MSIE and that many people felt it was overblown, but Microsoft definitely got dinged for it at the time. I can't find any good web pages that talk about it, though.
Summary: In Firefox 1.5.0.1, an exception is thrown any time the user attempts to access the window.history[] array (either for reading or writing). Implementing this behavior will solve all of the four issues below (although not all of them are exploitable). I have not tested MSIE 6 behavior. (In reply to comment #3) > 1. Can some sort of denial of service attack may be launched to consume memory? Yes, this is very easy to do, although I imagine there are other ways perform this kind of DoS attack simply by using a JavaScript array defined in the browser instead of the windows.history[] array. > 2. Can the index for window.history[] be overflowed if it's willing to accept > any index value? This has no effect. I didn't check the source code, but it's probably hashing the numeric value rather than using it literally. > 3. Can a "future" history item be added to window.history[] and then > window.history.forward() or javascript:goForward() be used to run it? A "future" history item can be added, but browser navigation completely ignores it--in both directions. > 4. The window.history[] array provides a cross-site scripting (XSS) attacker a > large storage space for keeping cookie values or usernames/passwords. If the > attacker can plant XSS code to store sensitive data (such as session cookies) > in the history array, they can store a lot of information that could be sent if > they are able to trick the user into visiting a "harvesting" site later. The original poster has already demonstrated this. Again, throwing an exception when accessing the window.history[] array would prevent this.
I cannot reproduce this bug, I'll assuming this is an old vulnerability, since fixed? If you can still reproduce this, please reopen.