pushState 如何防止潜在的内容伪造？答案

【问题标题】：How does pushState protect against potential content forgeries?pushState 如何防止潜在的内容伪造？
【发布时间】：2011-05-31 21:50:42
【问题描述】：

正如在GitHub's blog 中看到的，他们实现了HTML5's JavaScript pushState 的树浏览功能（适用于现代浏览器），带来了AJAX 导航without Hash Bangs。

代码很简单：

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

这非常优雅地允许他们：

通过 AJAX 而不是整页请求新内容
动画过渡
并且更改浏览器 URL（不仅仅是 #，就像 Twitter 所做的那样 — twitter.com/stackexchange → twitter.com/#!/stackexchange）

我的问题是，JavaScript 如何防止一个网站使用pushState 来模仿另一个网站，从而产生令人信服的phishing attack？

至少域似乎无法更改，但是站点内的多个路径可能由多个不相关且不信任的内容提供者提供呢？一条路径 (I.E. /joe) 是否可以本质上模仿另一条路径 (pushState /jane) 并提供模仿内容，可能出于恶意目的？

【问题讨论】：

标签： javascript security html phishing pushstate

【解决方案1】：

我的理解是，这与管理XMLHttpRequest、设置cookies和其他各种浏览器功能的Same Origin Policy完全一致。假设是，如果它在同一个域 + 协议 + 端口上，它是一个受信任的资源。通常，作为 Web 开发人员，这就是您想要（和需要）的，以使您的 AJAX 脚本能够工作并且您的 cookie 在整个站点中都是可读的。如果您正在运营一个用户可以发布内容的网站，那么确保他们不会对彼此的访问者进行网络钓鱼或键盘记录是您的工作，而不是浏览器的工作。

这里还有更多detail on what the FireFox folks are thinking about pushState - 这对他们来说似乎不是问题。还有另一个关于 possible pushState security hole here 的讨论，但这是一个不同的问题，即能够在其他人的 URL 末尾隐藏恶意查询字符串。

【讨论】：

【解决方案2】：

正如 nrabinowitz 所说，用更通俗的话来说：它仅限于同一个域，就像 ajax 调用和 cookie 一样。所以它是完全安全的——尽管对最终用户来说有点偷偷摸摸。

我们（开发人员）一直在用哈希标签做这件事，但这样做更好，因为：

看起来更干净。
在重新访问深层链接时，您实际上可以显示真实的 html 数据以支持诸如 SEO 和 Facebook Open Graph 之类的东西（两者都发送蜘蛛来修饰您页面的 html）。
服务器无权访问哈希标签数据，因此您不会在服务器日志中看到它，因此它可以帮助某些人进行分析。
它有助于解决哈希标签问题。例如，我进行了 Nginx 重写，以将访问我的应用程序的用户重定向到相同的 https url。它适用于所有浏览器，但 Safari 会将您重定向到没有哈希的域（太烦人了！）

【讨论】：