Repository navigation
Should History.length really be cross-domain [XSHM breach]? #2018
Description
Current status of History length
As stated in https://html.spec.whatwg.org/multipage/browsers.html#dom-history-length:
The length attribute of the History interface, on getting, must return the number of entries in the top-level browsing context's joint session history.
This means that the length attribute of the History interface is cross-domain.
Consequence: Cross Site History Manipulation
Generic attack scenario
A webpage can guess the browing history of a nested browing context by keeping a trace of the History length value. As an example, a document can store the value of History length, then open a nested browsing context to another domain, and track the browing actions in that nested browsing context by smartly testing when History length changed.
Online example
An attacker document (called [AD], like https://tests.reinom.com/http/xshm/ ) opens a nested browsing context [NBC] and loads a redirection's target (called [RT], https://dom2.tests.reinom.com/http/xshm/ ) in that [NBC]. Then, [AD] stores the History length value, changes [NBC] URL to a vulnerable page [VP] that does a conditionnal redirection. Once the [NBC] is loaded, the [AD] checks whether History length has changed. If it has not, it means that the [VP] redirected to [RT]. If it has, it means [VP] redirected to another page than [RT] (or did no redirection at all). So [AD] knows whether the redirection from [VP] to [RT] occured (so they knows if the condition of that redirection was true).
Suggested solution
If History length violates the SOP principle, then it can be used to guess informations about a nested browsing context navigation that does not share the same domain-origin. I suggest that the History length attribute should be filtered before being accessed by a Document and only return entries that matches its domain.
Either like the short:
The length attribute of the History interface, on getting, must return the number of entries in the top-level browsing context's joint session history. These entries must be first filtered to keep only the ones sharing the same origin-domain that this Document associated to the History object.
Or the longer but closer to "joint session history" definition ("with all entries ... removed"):
The length attribute of the History interface, on getting, must return the number of entries in the top-level browsing context's joint session history, with all entries that do not share the same domain-origin than the Document associated to the History object removed.
With a link to https://html.spec.whatwg.org/multipage/browsers.html#same-origin-domain on "same origin-domain".
Impact
IMO, the impact this may have is very minor. It will only break reliance on cross domain History, like knowing whether the Document was directly loaded in a browsing context or if it was loaded after clicking a link from another domain. This can still be known with HTTP's Referer header.
But it will break XSHM attacks and enhance privacy security for Web users.
Activity
zcorpan commentedon Nov 8, 2016
This is the same issue as https://www.owasp.org/index.php/Cross_Site_History_Manipulation_(XSHM) correct? Has any browser taken any steps to mitigate the attack?
Checking the demo https://tests.reinom.com/http/xshm/ in Chrome, the malicious page thinks the cookie is set both when it is actually set and when it isn't.
SpyroTEQ commentedon Nov 8, 2016
Yes, it's the same issue.
Firefox team member Benjamin Smedberg said that this is a spec issue ( https://bugzilla.mozilla.org/show_bug.cgi?id=1315203#c2 ) so Mozilla won't mitigate it if the spec remain unchanged.
It appears the XSHM occurs in Firefox (47) and IE (11). In Chrome (48), Opera (41), it doesn't. So it may be related to the way History entries are added when a 3xx redirect occurs. I'm not very sure about what the specs says in such situation, so I cannot tell which of (Firefox+IE) or (Opera+Chrome) is wrong about the spec's implementation.
annevk commentedon May 4, 2017
This is blocked on #1454.
Would be interested to hear what @mikewest and @johnwilander think about this one. (Apologies for all the recent pings. I've been looking at older unsolved issues.)
jakearchibald commentedon Aug 11, 2020
Not only is this a security/privacy issue, it's also really difficult to manage in a world where nested navigables can be in different processes.
history.lengthchanges synchronously in the following cases:pushState. This involves decementing history length by the number of forward session history items, and adding 1. Onward session history items may be spread across a series of processes, so the current thread needs some copy of this number, which means it can get out of sync.Chrome is currently the only browser that ships other-process iframes, and it's pretty easy to end up with
history.lengthbeing out of sync, and we don't currently discard session history items when iframes are removed.I asked folks what they used
history.lengthfor, and it seems like the use-cases are pretty unreliable without an accompanyinghistory.index, which would just make the implementation & security problems worse.Some thoughts on ways forward:
history.lengthalways returns 42.This solves the implementation complexity/races, and the security issues. It will break script that relies on
history.lengthchanging.history.lengthupdates async.This solves the implementation races. It doesn't solve the security issues. It will break script that relies on
history.lengthchanging synchronously.history.lengthis updated synchronously, but it's per tuple [origin, event loop, browsing session].history.lengthwill start at 1, and the following will modify that value synchronously:pushStateor changing the hash.The following will not modify that value:
history.lengthassociated with that [origin, event loop, browsing session].history.length.This may act inconsistently in browsers that create new event loops for pages that are in the same origin & browsing session. But I'm not sure that's any more inconsistent than
history.lengthcurrently is across browsers.I think this solves the implementation complexity/races, and the security issues. It isn't clear to me if this would still break scripts that rely on the current behaviour of
history.length. It might even be more reliable for those scripts?Any takers for the above? I'm not trying to "fix" the history API, I'm just trying to resolve the security and race conditions around
history.lengthwithout breaking too much of the web.emilio commentedon Aug 11, 2020
cc @mystor @smaug----
jakearchibald commentedon Aug 11, 2020
If folks are using
history.lengthto answer "can I go back" then I guess we can make it 1 or 2 when navigating to a new [origin, event loop, browsing session] depending on whether there's a previous entry at the time.smaug---- commentedon Aug 11, 2020
It would need to be 3 to answer to the question "can I go back and can I go forward". And also if pushState or fragment navigation is used, it would be odd if .length didn't increase.
jakearchibald commentedon Aug 11, 2020
Actually, I'm talking shit, just because
history.lengthis 2 doesn't answer "can I go back", as you'd need the current index too.jakearchibald commentedon Aug 11, 2020
Right, but
history.lengthis already odd in implementations. But yes, I agree that might be too odd.domenic commentedon Mar 16, 2022
This generic attack is worse than just
history.length. It is inherent in the joint session history design plus anything that lets you tell whether ahistory.back()/etc. has traversed the joint session history.For example, here is a version that uses
history.stateupdating: http://boom-bath.glitch.me/session-history-leak.html . (Note that it is cross-origin to the https: nested iframe. You can also test with the same code in jsbin for a jsbin-spying-on-glitch example that is cross-site: https://output.jsbin.com/wepicaqewo .)You could do a similar thing without
history.stateby using URL fragments: http://boom-bath.glitch.me/session-history-leak-hash.html . (Or using URL paths withhistory.pushState()/history.replaceState().)Both versions require potentially navigating the child frame which might be a bit destructive for an attacker, but it's possible there are clever ways around that.
Of course this attack is also possible using
iframeload events, without any history stuff involved!In conclusion, telling when nested browsing contexts navigate is not really hard on the current platform, so I am not sure how concerned we should be.
domenic commentedon Mar 16, 2022
I guess maybe I misunderstood the original attack. It's not the fact that the page navigated that we consider sensitive. It's the URL the page navigated to.
That can be mitigated, as Chromium has done, by avoiding the same-URL-replace behavior when the initiator is cross-origin: https://bugs.chromium.org/p/chromium/issues/detail?id=1208614 (although I don't think that bug is public).
camillelamy commentedon Mar 18, 2022
I am wondering if there is additional information being revealed by the joint history state compared to listening to onload events from the iframes, beyond the potential URL issue you point to. For example, if a cross-origin iframe were to navigate in a manner that causes the current history entry to be replaced rather than a new one being added, this is something that could be seen through the evolution of the joint history but not by listening to the iframe load events, which I think would be similar in both cases.
Additionally, the history API is accessible from iframes I believe, which makes it possible for an iframe to leak data from siblings iframes right? Which wouldn't be possible from just listening to onload callbacks.
So overall, it would seem to me that the history API has XSite leak capabilities that go beyond listening to load callbacks. Since it also seems that it is not the most handy API anyway, it would be good if the XSite leak capabilities were mitigated.
domenic commentedon Mar 31, 2022
Sort of. It would need to be joined with other information, such as load events, to be distinguishable from the cross-origin iframe doing nothing at all.
Well, you cannot access
parent.frames[0].history. But,window.history(which you can access) gives indirect information about sibling iframes, of the type we're discussing. So yeah, you can tell whether a sibling iframe navigated.Do you have any ideas how to do that? If our goal is not just to protect the URL, but instead to protect any information leakage beyond load events, I think the type of attacks I mentioned in #2018 (comment) where you use
history.back()orhistory.go(N)to manipulate the iframe, and then read back the impact on yourself, make this pretty hard to mitigate.