Как 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 на одном веб-сайте для подражания другому, что приводит к убедительной фишинг-атаке

По крайней мере, кажется, что домен не может быть изменен, но как насчет нескольких путей внутри сайта, потенциально нескольких несвязанных и ненадежных поставщиков контента? Может ли один путь (I.E. /joe) по существу имитировать другой (pushState /jane) и предоставлять имитирующий контент, возможно, в злонамеренных целях?

Ответ 1

Я понимаю, что это полностью согласуется с Same Origin Policy, которая регулирует XMLHttpRequest, устанавливает файлы cookie и другие другие функции браузера. Предполагается, что если он находится на одном домене + протокол + порт, он является надежным ресурсом. Обычно, как веб-разработчик, это то, что вам нужно (и нужно), чтобы ваши сценарии AJAX работали, и ваши файлы cookie могли быть прочитаны на вашем сайте. Если вы используете сайт, на котором пользователи могут размещать контент, это ваша работа, а не браузер, чтобы убедиться, что они не могут фишировать или класть в журнал друг друга посетителям.

Здесь еще несколько подробно о том, что люди FireFox думают о pushState - похоже, что это не проблема для них, Там было другое обсуждение возможного дыра в безопасности pushState здесь, но это другое беспокойство, о том, что можно скрыть злонамеренный запрос в конце URL другого пользователя.

Ответ 2

Как заявил nrabinowitz и в более простых условиях: он ограничивается одним и тем же доменом, точно так же, как ajax-вызовы и файлы cookie. Таким образом, он полностью безопасен, хотя и немного подлый для конечного пользователя.

Нас (разработчики) вечно делают это с хэш-тегами навсегда, но это лучше, потому что:

Он выглядит чище.
При повторном использовании глубокой ссылки вы можете реально отображать реальные html-данные для поддержки таких вещей, как SEO и Facebook Open Graph (оба посылают пауки, чтобы просмотреть html вашей страницы).
Серверы не имеют доступа к данным хэш-тегов, поэтому вы не видите их в своих журналах сервера, поэтому это помогает некоторым аналитикам.
Он помогает исправлять проблемы с хэш-тегами. Например, у меня была перезапись Nginx, чтобы перенаправить пользователей, посещающих мое приложение, на тот же https-url. Он работает во всех браузерах, но Safari, который перенаправляет вас только на домен без хеша (так раздражает!)