[WEB SECURITY] Cross-Site History Manipulation (XSHM)

Michele Orru antisnatchor at gmail.com
Mon Feb 1 08:16:52 EST 2010


I agree with Michal.

This is just another cross-domain probe.

>From many months I've seen a common behavior in this list where people
that wants
to gain more visibility tend to post "new attack vectors", where in
fact they are just
"ways to do things" that can be classified in already classified techniques.

Michele "antisnatchor" Orru'

On Sun, Jan 31, 2010 at 11:28 AM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
> From the post:
>
>> Checkmarx Research Labs has identified a new critical vulnerability in
>> Internet Explorer (other browsers are probably exposed the same way) that
>> would allow hackers to easily compromise web applications.
>
> I'm sorry if this response sounds harsh, but phrases such as "critical
> vulnerability" and "compromise web applications" caught my eye.
>
> The paper seems to focus on collecting information by navigating to
> pages that will conditionally redirect the browser somewhere else
> through certain types of client-side navigation (but as I understand
> it, not the more common HTTP 30x responses?). By looking at history.*,
> the attacking site may detect whether the redirect happened or not.
>
> The paper then enumerates a number of scenarios where this would be of
> particular concern (and presumably, meaningfully different from other,
> well-known cross-domain privacy leaks - see
> http://code.google.com/p/browsersec/wiki/Part2#Privacy-related_side_channels
> for a sample). Unfortunately, in my opinion, these scenarios do not
> seem to warrant being classified as "critical" (or really, anything
> but "low"); and for most part, are not unique to this vector at all:
>
> 1) "Login Detection" - if the site redirects to a login page when
> /myaccount is requested, we know the user is not logged in. Unless I
> am mistaken, the same information can be collected through a number of
> well-known vectors: image or script onload / onerror events, including
> remote CSS or scripts and testing for side effects, page unload
> timing, cache timing, CSS :visited, probing frames.length and other
> publicly visible global properties, etc.
>
> All of them are well-known (see "Resource inclusion probes" in BSH),
> and AFAICT, do not pose any appreciable security risk. They are a
> privacy nuisance, but completely dwarfed in comparison with other
> browser fingerprinting vectors.
>
> 2) "Resource Mapping" - if the site redirects to a "404" page when
> http://intranet/something.txt is requested, we know whether the file
> exists or not. The same information can be collected by timing page
> loads, frames.length, etc; in most cases I've seen, the 404 URL
> incorporates portions of the original URL, too (say,
> /NotFound.aspx?origURL=http://intranet/...), so CSS :visited probes
> and cache timing is on the table.
>
> Any direct benefit to attackers is probably negligible, especially
> keeping in mind they can, for example, also port-scan internal
> networks or execute XSRF / XSS / SQL injection attacks against
> internal targets freely. The problem of unconstrained Internet ->
> intranet fenceposts is very real, but not new - see:
> http://code.google.com/p/browsersec/wiki/Part2#Local_network_/_remote_network_divide
>
> 3)  "Error Leakage" and "State Detection" - if server errors result in
> a redirect to a "500" page, you can get additional feedback about
> whether a security attack such as XSS or XSRF succeeded. The same can
> be achieved through page load timing, frames.length or - in the
> aforementioned common case - with CSS :visited and friends.
>
> I fail to see a significant security impact: well-designed
> applications that account for known security issues are not any more
> at risk; buggy applications can be freely exploited without this
> direct feedback, too. While it may make some attackers a bit happier,
> it's not a critical bug.
>
> 4) "Information Inference" - gives a hypothetical application that
> accepts the URL of
> "http://Intranet/SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500",
> and returns a normal page if matching rows are found, but redirects to
> an error page if not (instead of the more intuitive "no matches found"
> response).
>
> Load timing, frames.length, and CSS :visited can probably be used to
> collect the same info - but that aside, it's an interesting case, if
> actually seen in the wild. The example strikes me as a bit unlikely;
> are you aware of any application that would, in fact, behave this way
> and disclose sensitive information in the process?
>
> 5) "Cross-Site User Tracking" - discusses staying in the background
> and probing history.length to detect certain page transitions for the
> purpose of detecting certain UI actions. The outlined phishing vector
> sounds somewhat plausible: it requires the attack page to be running
> in parallel in a separate window or a tab, and the user to be
> inattentive, but it could happen. It's not specific to history.*,
> though: probing frames.length and related properties is an equivalent.
>
> 6) "Cross-Site URL/Parameters Enumeration". Discusses calling
> history.go(url) to see if a particular URL appears in the current
> history
>
> This is actually sort of interesting: this behavior of history.go()
> seem to be specific to MSIE, and is a pretty bad idea. That said, the
> attack is conceptually similar to CSS :visited, frames, or cache
> probing. The author suggests that the fact this vector is restricted
> to the current session gives the attacker a distinct advantage; I
> would suggest that because it is restricted to short-lived, per-window
> history, it puts him at a significant practical disadvantage. It's a
> privacy issue, but conceptually similar to well-studied vectors that
> probably need to be considered holistically.
>
> ...
>
> Bottom line is, my impression is that it's a collection of interesting
> thought experiments along the lines of "what could you do with any
> generic cross-domain probing technique"; from that perspective, it's
> pretty good, and fits the existing body of research. Why this
> collection is framed in the context of history.*, or claimed to be a
> critical new vulnerability, is lost on me, though.
>
> Cheers,
> /mz
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list