Как pushState защищает от возможных подделок контента?

Как видно из блога GitHub , они реализовали JavaScript HTML5pushState функция для просмотра дерева (для современных браузеров), приносящая AJAX-навигацию без хэш-челок.

Код прост: 

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

Это довольно элегантно позволяет им:

  1. запрашивать только новый контент через AJAX вместо полной Страницы
  2. анимировать переход
  3. и измените URL браузеров (не только #, как Twitter делает - twitter.com/stackexchange → twitter.com/#! / stackexchange )

Мой вопрос в том, как JavaScript предотвращает использование pushState одним сайтом для имитации другого, что приводит к убедительной фишинг-атаке?

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

2 12
javascript html5 security phishing pushstate

2 ответа:

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

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

9

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

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

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