pushState如何防范潜在的内容伪造？ [英] How does pushState protect against potential content forgeries?

问题描述

如 GitHub的博客所示，他们实施了用于树木浏览的HTML5的JavaScript pushState 功能（适用于现代浏览器），带来AJAX导航没有Hash Bangs 。

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.

代码很简单：

$('#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. 通过AJAX而不是通过AJAX请求新内容整页


2. 动画转换


3. 和更改浏览器URL （不仅仅是＃，正如Twitter所做的那样— twitter.com/stackexchange → twitter.com/#!/stackexchange ）

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 )

我的问题是，JavaScript如何防止一个网站使用 pushState 来模仿另一个网站，从而导致说服网络钓鱼攻击？

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

至少看起来域名无法更改，但网站内的多条路径又可能由多个不相关且不可信赖的内容提供商进行更改？一条路径（IE / joe ）是否可以模仿另一条路径（pushState / jane ）并提供模仿内容，可能是恶意目的？

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?

推荐答案

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

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.

这里是更多有关FireFox用户正在考虑的内容的详细信息 pushState - 这对他们来说似乎不是问题。关于可能的 pushState 安全漏洞的另一个讨论在这里，但它是一个不同的关注点，关于能够在其他人的URL的末尾隐藏恶意查询字符串。

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.

这篇关于pushState如何防范潜在的内容伪造？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！