1315203 - XSHM: Cross Site History Manipulation (information leakage)

Status: NEW

(Core :: DOM: Navigation, defect, P3)

Description

[Vincent MONIER]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

Access the `window.history.length` property on a website page.


Actual results:

The `window.history.length` let a website knows the total number of entries in all the history, including entries for another domain (so the Same Origin Policy is broken).


Expected results:

The website should only know the number of entries concerning the domain it belongs to. So if you are on "https://reinom.com", `window.history.length` should only return the number of history entries concerning that domain.

See the complete Checkmarx report explaining the attack more deeply:
https://www.checkmarx.com/wp-content/uploads/2012/07/XSHM-Cross-site-history-manipulation.pdf

I may put an online showcase if needed, since the "Am I connected into Facebook?" exploit is no longer accessible.

Comment 1

[Vincent MONIER]

I put online a quick demonstration of that XSHM attack, since the Checkmarx's one is no longer available. This is the attack webpage:

https://tests.reinom.com/http/xshm/


Another page, the targeted vulnerable webpage ( https://dom2.tests.reinom.com/http/xshm/ ), uses a cookie to tell whether user is logged in (PHP sample), and redirects the user if not:

	if (!filter_input(INPUT_COOKIE, 'xshm-session')) {
		header('Location: xshm-redirect.php');
		exit;
	}


The attacker page cannot tell directly whether the cookie exists (because of SOP). But the attacker webpage can use window.history.length (which violates SOP) to check if the cookie is set on the targeted vulnerable webpage.


To do so, the attacker webpage is loaded in a tab (window.history.length == 1). Then, the attacker webpage creates the iframe and load the redirection destination webpage (RDW) in it (window.history.length == 2). Then the attacker webpage loads the targeted vulnerable page (TVW)in the iframe. The TVW will then redirect to the RDW if the cookie is not set, and the window.history.length won't change (window.history.length == 2) or it will do no redirection if the cookie is set, incrementing the window.history.length (window.history.length == 3).

Hence, since window.history.length violates the SOP principle. The attacker page can use it to tell whether the redirection occurred, so the attacker knows whether the redirection condition occurred (cookie set or not).

Comment 2

[Benjamin Smedberg]

Vincent, have you compared the behavior of other browsers and what the HTML spec says here? Reading through https://html.spec.whatwg.org/multipage/browsers.html#dom-history-length I don't see any restrictions in the specification, so we appear to be following the spec and this, if it is to be changed, would probably need to be changed at the spec level.

Comment 3

[Vincent MONIER]

That's right, I will check about that with WHATWG first ( https://github.com/whatwg/html/issues/2018 ) and come back here after, either ask for closing this issue as WONT_FIX or to leave it opened and make it CONFIRMED.

I have no idea how long it will take for WHATWG to consider this XSHM.

Comment 4

[Vincent MONIER]

Note that I've checked Opera (41) and Chrome (48) and this XSHM issue does not appear on both this browsers, because they look to always add an entry to the History interface, no matter whether you got redirected or no to the page you currently are.

So maybe it's a matter of how Firefox builds the "joint session history" ( https://html.spec.whatwg.org/multipage/browsers.html#joint-session-history ): "...all the entries that are current entries in their respective session histories removed *except for the current entry of the joint session history*.". Maybe Firefox uses the Document's URL to remove that "current entry", and if the last two History entries have the same URL (and so that URL is the current Document's), then Firefox ignores these two entries, returning a non-incremented History length when user got redirected to the page they already are?

Comment 5

[Daniel Veditz [:dveditz]]

This is a public paper (referenced in several places) so no point in hiding this bug.

Comment 6

[Andrew Overholt [:overholt]]

What we do here will depend on the outcome of the spec issue: https://github.com/whatwg/html/issues/2018 (which of course we can help drive :).

Comment 7

[Tom Ritter [:tjr] (OOTO until April)]

Hey Anne, do you think there's been any movement here, or sufficiently not-enough-movement that we could potentially do something our own way?

Comment 8

[Anne (:annevk)]

As long as we clearly document our strategy, yes (clear enough for standardization and testing efforts). And as long as that strategy has buy-in from Olli Pettay and perhaps also Nika Layzell or someone from her team.

(Session history is rather broken on the standards side, so the main concern here is web compatibility and willingness from other implementations to align with us down the road.)

Comment 9

[Nika Layzell [:nika] (ni? for response)]

(In reply to Anne (:annevk) from comment #8)
> As long as we clearly document our strategy, yes (clear enough for
> standardization and testing efforts). And as long as that strategy has
> buy-in from Olli Pettay and perhaps also Nika Layzell or someone from her
> team.
> 
> (Session history is rather broken on the standards side, so the main concern
> here is web compatibility and willingness from other implementations to
> align with us down the road.)

I've done some thinking about this a while ago when I was looking originally at what work we would need to get Session History information out of the content process. In most places it's impossible for webpages to glean any useful information from this variable, with the potential exception of whether there is a 'back' entry in history before this page (which will fail if the current page is in history).

See also bug 1436489 where I suggest just making up a number for the length of history & returning that.

Comment 10

[Nika Layzell [:nika] (ni? for response)]

See also bug 583886

Comment 13

[Simon Pieters [:zcorpan]]

https://github.com/whatwg/html/pull/9157 was merged to fix this in the spec.

Comment 14

[Daniel Veditz [:dveditz]]

Attachment: XSHM-Cross-site-history-manipulation.pdf

Attaching a copy of the original 2012 checkmarx document from the internet archive because the link is broken, despite them referencing it as recently as a 2021 blog post