Question

As seen in GitHub’s blog, they’ve implemented HTML5’s JavaScript pushState feature for tree browsing (for modern browsers), bringing AJAX navigation without Hash Bangs.

The code is simple:

$('#slider a').click(function() {
  history.pushState({ path: this.path }, '', this.href)
  $.get(this.href, function(data) {
    $('#slider').slideTo(data)
  })
  return false
})

This quite elegantly allows them to:

1. Request the just the new content through AJAX instead of a full page
2. Animate the transition
3. And change the browsers URL (not just the #, as Twitter does — twitter.com/stackexchange → twitter.com/#!/stackexchange )

My question is, how does JavaScript prevent against the use of pushState by one website to imitate another, resulting in a convincing phishing attack?

At the very least it seems that the domain can’t be changed, but what about multiple paths within a site, potentially by multiple unrelated and untrusting content providers? Could one path (I.E. /joe) essentially imitate another (pushState /jane) and provide imitative content, with possibly malicious purposes?

Answer 1

My understanding is that this is perfectly consistent with the Same Origin Policy that governs XMLHttpRequest, setting cookies, and various other browser functions. The assumption is that if it’s on the same domain + protocol + port, it’s a trusted resource. Usually, as a web developer, that’s what you want (and need) in order for your AJAX scripts to work and your cookies to be readable throughout your site. If you are running a site where users can post content, it’s your job, not the browser’s, to make sure they can’t phish or keylog each other’s visitors.

Here’s some more detail on what the FireFox folks are thinking about pushState – it doesn’t seem like this is an issue for them. There’s another discussion of a possible pushState security hole here, but it’s a different concern, about being able to hide a malicious querystring on the end of someone else’s URL.