How does pushState protect against potential content forgeries?

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.

Answer 2

As nrabinowitz has stated and in more layman's terms: it's limited to the same domain, just like ajax calls and cookies. So it's completely safe—though a little sneaky to the end user.

Us (developers) have been doing this forever with hash tags forever but it's better because:

1. It looks cleaner.
2. On revisit of a deep link you can actually surface real html data to support things like SEO and Facebook Open Graph (both send spiders to scape the html of your page).
3. Servers don't have access to hash tags data so you don't see it in your server logs so it helps some with analytics.
4. It helps fix hash tag issues. For example I had an Nginx rewrite to redirect users visiting my app to the same https url. It works in all browsers but Safari which will redirect you to just the domain without the hash (so annoying!)