7135 2006-02-07 09:59:23 -0800 window.history object persists data across pages 2011-08-06 18:32:14 -0700 1 1 1 Unclassified WebKit History 417.x Mac OS X 10.4 RESOLVED WORKSFORME P2 Trivial --- 1 gazhay webkit-unassigned barraclough ddkilzer ian krishnamurty.podipireddy S60webkit oldest_to_newest 31734 0 gazhay 2006-02-07 09:59:23 -0800 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. 31735 1 6331 gazhay 2006-02-07 10:01:01 -0800 Created attachment 6331 quick page to setup history object exploit A quick example of window.history persisting across pages 31752 2 ggaren 2006-02-07 13:06:00 -0800 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. 31774 3 ddkilzer 2006-02-07 14:16:47 -0800 (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. 31803 4 ddkilzer 2006-02-07 20:17:09 -0800 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. 447660 5 barraclough 2011-08-06 14:06:27 -0700 I cannot reproduce this bug, I'll assuming this is an old vulnerability, since fixed? If you can still reproduce this, please reopen. 6331 2006-02-07 10:01:01 -0800 2006-02-07 10:01:01 -0800 quick page to setup history object exploit input.html text/html 261 gazhay PEhUTUw+CjxIRUFEPgo8U0NSSVBUPgp3aW5kb3cuaGlzdG9yeVs1ODc2OV09IlRoaXMgaXMgYSBo aXN0b3J5IGhpamFjayBhdHRlbXB0IjsKd2luZG93Lmhpc3Rvcnlbd2luZG93Lmhpc3RvcnkubGVu Z3RoXT0idGhpcyBpcyBhbm90aGVyIGhpamFjayI7CndpbmRvdy5oaXN0b3J5WzBdPSJUaGlzIGlz IGhpc3RvcnkgMSI7CjwvU0NSSVBUPgo8L0hFQUQ+Cgo8Qk9EWT4KPGEgaHJlZj0ib3V0cHV0Lmh0 bWwiPk91dHB1dCBpdDwvYT4KPC9CT0RZPgo8L0hUTUw+