[Webkit-unassigned] [Bug 7135] window.history object persists data across pages
bugzilla-daemon at opendarwin.org
bugzilla-daemon at opendarwin.org
Tue Feb 7 20:17:10 PST 2006
http://bugzilla.opendarwin.org/show_bug.cgi?id=7135
------- Comment #4 from ddkilzer at kilzer.net 2006-02-07 20:17 PDT -------
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.
--
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list