PushState 如何防止潜在的内容伪造？
正如 GitHub 博客 所示，他们已经实现了 HTML5 的 JavaScript pushState 树浏览功能（适用于现代浏览器），带来AJAX 导航没有 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 来模仿另一个网站，导致令人信服的网络钓鱼攻击？
至少，域名似乎无法更改，但是站点内的多个路径（可能由多个不相关且不信任的内容提供商）又如何呢？一条路径 (IE /joe) 是否可以本质上模仿另一条路径 (pushState /jane) 并提供模仿内容，可能具有恶意目的？
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:
- Request the just the new content through AJAX instead of a full page
- Animate the transition
- 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我的理解是，这与管理
XMLHttpRequest同源策略 完全一致code>、设置 cookies 以及各种其他浏览器功能。假设是，如果它位于相同的域+协议+端口上，那么它就是可信资源。通常，作为 Web 开发人员，这就是您想要（和需要）的，以便您的 AJAX 脚本能够正常工作，并且您的 cookie 在整个站点上都可读。如果您正在运行一个用户可以发布内容的网站，那么确保他们无法对彼此的访问者进行网络钓鱼或键盘记录是您的工作，而不是浏览器的工作。这里有更多有关 FireFox 人员对
pushState的看法的详细信息 - 这对他们来说似乎不是问题。这里还有另一个关于可能的pushState安全漏洞的讨论，但这是一个不同的问题，即能够在其他人的 URL 末尾隐藏恶意查询字符串。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 possiblepushStatesecurity hole here, but it's a different concern, about being able to hide a malicious querystring on the end of someone else's URL.正如 nrabinowitz 所说，用更通俗的话来说：它仅限于同一个域，就像 ajax 调用和 cookie 一样。所以它是完全安全的——尽管对最终用户来说有点偷偷摸摸。
我们（开发人员）一直在使用哈希标签这样做，但它更好，因为：
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: