Какова модель угрозы для той же политики происхождения? - PullRequest
12 голосов
/ 19 июля 2011

http://en.wikipedia.org/wiki/Same_origin_policy

Та же самая политика происхождения не позволяет сценарию с одного сайта общаться с другим сайтом. Вики говорит, что это «важная концепция безопасности», но мне не ясно, какую угрозу она предотвращает.

Я понимаю, что файлы cookie с одного сайта не должны передаваться другому, но это может быть (и применяется) отдельно.

Стандарт CORS http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing предоставляет легитимную систему для обхода той же политики происхождения. Предположительно, он не допускает никакой угрозы, которую должна блокировать та же политика происхождения.

Глядя на CORS, я еще менее ясно, кого от чего защищают. CORS обеспечивается браузером, поэтому он не защищает ни один сайт от браузера. И ограничения определяются сайтом, с которым скрипт хочет общаться, поэтому он не защищает пользователя ни от одного сайта.

Так для чего же нужна политика происхождения?

Ответы [ 3 ]

6 голосов
/ 27 мая 2012

В статье @EricLaw упоминается: " Одинаковая политика происхождения, часть 1: не заглядывать " - это хорошо.

Вот простой пример того, почему нам нужна «та же политика происхождения»:

Можно отображать другие веб-страницы на своей собственной веб-странице с помощью iframe («встроенный фрейм» помещает другой HTMLдокумент в рамке).Допустим, вы отображаете www.yourbank.com.Пользователь вводит свою банковскую информацию.Если вы можете прочитать внутренний HTML-код этой страницы (который требует использования скрипта), вы можете легко прочитать информацию о банковском счете и всплыть.Нарушение безопасности.

Поэтому нам нужна та же политика происхождения, чтобы убедиться, что одна веб-страница не может использовать скрипт для чтения информации другой веб-страницы.

1 голос
/ 19 января 2017

Целью той же политики происхождения является предотвращение угрозы со стороны вредоносного сайта M чтения информации с доверенного сайта A с использованием полномочий (то есть файлов cookie авторизации) пользователя A.Это политика браузера, а не политика сервера или стандарт HTTP, и она предназначена для уменьшения риска другой политики браузера - отправки файлов cookie с сайта A при обращении к сайту A.

Обратите внимание, что существуетничто не мешает M получить доступ к A вне браузера.Он может отправлять столько запросов, сколько захочет.Но он не будет делать это с полномочиями незнающего пользователя A, что в противном случае может произойти в браузере.

Также обратите внимание, что политика запрещает странице M чтение из A.Он не защищает сервер A от последствий запроса.В частности, браузер будет разрешать междоменные POSTS - куки и все - от M до A.Эта угроза называется Подделка межсайтовых запросов ;это не смягчается той же самой политикой происхождения, и поэтому для серверов крайне важно защитить себя от этого.

1 голос
/ 19 июля 2011

Например, он не позволяет Farmville проверять баланс на вашем банковском счете.Или, что еще хуже, возиться с формой, которую вы собираетесь отправить (после ввода PIN / TAN), чтобы они получили все деньги.

CORS - это в основном стандарт для веб-сайтов, которые уверены, что они не нужныэтот вид защиты.По сути, он говорит: «Сценарий с любого веб-сайта может быть нормальным для меня, я не могу нарушить безопасность».Таким образом, он действительно допускает вещи, которые были бы запрещены СОП, в местах, где защита не нужна, а междоменные веб-сайты выгодны.Подумайте о сетках.

...