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

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

12 голосов
/ 01 июня 2011

Как видно из блога GitHub , они реализовали HTML5 JavaScript pushState функцию просмотра дерева (для современных браузеров), обеспечивающую навигацию 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 одним веб-сайтомподражать другому, приводя к убедительной фишинговой атаке ?

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

Ответы [ 2 ]

9 голосов
/ 02 июня 2011

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

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

2 голосов
/ 18 мая 2012

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

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

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