Такая же политика происхождения и CORS (совместное использование ресурсов)

Ответ 1

Политика одинакового происхождения

Что это такое?

Политика одинакового происхождения - это мера безопасности, стандартизованная среди браузеров. "Начало" в основном относится к "домену". Это предотвращает взаимодействие разных сторон друг от друга, чтобы предотвратить атаки, такие как Cross Site Request Forgery.

Как срабатывает CSRF-атака?

Браузеры позволяют веб-сайтам хранить информацию на клиентском компьютере в виде файлов cookie. Эти куки имеют некоторую информацию, прикрепленную к ним, например имя файла cookie, когда оно было создано, когда оно истечет, кто установил cookie и т.д. Файл cookie выглядит примерно так:

Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]

Итак, это шоколадное печенье, которое должно быть доступно из http://bakery.com и всех его поддоменов.

Этот файл cookie может содержать некоторые конфиденциальные данные. В этом случае эти данные... chocolate. Очень чувствительный, как вы можете видеть.

Таким образом, браузер сохраняет этот файл cookie. И всякий раз, когда пользователь делает запрос в домен, на котором доступен этот куки файл, cookie будет отправлен на сервер для этого домена. Счастливый сервер.

Это хорошо. Супер классный способ для сервера хранить и извлекать информацию с клиентской стороны.

Но проблема в том, что это позволяет http://malicious-site.com отправить эти файлы cookie в http://bakery.com, без ведома пользователя! Например, рассмотрим следующий сценарий:

# malicious-site.com/attackpage

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();

Если вы посещаете вредоносный сайт и выполняете вышеуказанный код, а политика того же происхождения не существует, злоумышленник отправит заказ от вашего имени и получит заказ у него... и вы можете не так.

Это произошло потому, что ваш браузер отправил ваш шоколадный cookie в http://bakery.com, который сделал http://bakery.com считают, что вы делаете запрос на новый заказ, сознательно. Но это не так.

Это, проще говоря, атака CSRF. Поддельный запрос был сделан через сайты. "Подделка запросов на межсайтовый запрос". И это не сработает, благодаря политике одного и того же происхождения.

Как политика такого же происхождения разрешает это?

Он запрещает malicious-site.com делать запросы в другие домены. Простой.

Другими словами, браузер не разрешает любому сайту делать запрос на какой-либо другой сайт. Это предотвратило бы взаимодействие разных источников друг с другом посредством таких запросов, как AJAX.

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

токены CSRF

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

<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>

И браузер попытается загрузить изображение с этого URL-адреса, в результате чего GET-запрос на этот URL-адрес отправит все файлы cookie. Чтобы это не произошло, нам нужна защита на стороне сервера.

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

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

CORS

При необходимости политика может быть обойдена, когда требуются запросы на межсайтовый сайт. Это называется CORS. Перекрестный ресурс ресурсов.

Это работает, когда "домены" сообщают браузеру о охлаждении и разрешают такие запросы. Эта "говорящая" вещь может быть выполнена путем передачи заголовка. Что-то вроде:

Access-Control-Allow-Origin: //comma separated allowed origins list, or just * Поэтому, если http://bakery.com передает этот заголовок в браузер, а страница, создающая запрос http://bakery.com присутствует в списке происхождения, затем браузер отправит запрос вместе с файлами cookie.

Существуют правила, согласно которым определяется начало координат ¹. Например, разные порты для одного и того же домена не совпадают. Таким образом, браузер может отклонить этот запрос, если порты отличаются. Как всегда, наши дорогиеИсключение составляет Internet Explorer. IE обрабатывает все порты одинаково. Это нестандартный, и никакой другой браузер не ведет себя таким образом. Не полагайтесь на это.

JSONP

JSON с Padding - это всего лишь способ обойти политику одного и того же происхождения, когда CORS не является вариантом. Это рискованная и плохая практика. Избегайте использования этого.

В чем заключается эта технология, это запрос на другой сервер, например:

<script src="http://badbakery.com/jsonpurl?callback=cake"></script>

Поскольку политика такого же происхождения не предотвращает этот запрос ² ответ этого запроса будет загружен на страницу.

Этот URL-адрес, скорее всего, будет отвечать содержимым JSON. Но просто включение содержимого JSON на странице не поможет. Это приведет к ошибке, конечно. Таким образом http://badbakery.com принимает параметр обратного вызова и изменяет данные JSON, посылая его, завернутый в то, что передается параметру обратного вызова.

Поэтому вместо возврата

{ user: "vuln", acc: "B4D455" }

который недействителен JavaScript, бросающий ошибку, он вернется,

cake({user: "vuln", acc:"B4D455"});

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

В основном это используется API для отправки данных в другие домены. Опять же, это плохая практика, может быть рискованной и ее следует избегать.

Почему JSONP плохо?

Прежде всего, он очень ограничен. Вы не можете обрабатывать какие-либо ошибки, если запрос не работает (по крайней мере, не разумно). Вы не можете повторить запрос и т.д.

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

Наконец, вы вставляете случайный код JavaScript в DOM. Если вы не на 100% уверены, что удаленная служба вернет безопасные пирожные, вы не можете положиться на это.

Ссылки

^{1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin}

^{2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details}

Другие достойные чтения

http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html

http://tools.ietf.org/html/rfc3986 (извините: p)

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Ответ 2

Одинаковая политика происхождения (SOP) - это браузер политик для предотвращения уязвимостей через Cross Site Scripting (XSS). Это в основном для защиты сервера, так как есть много случаев, когда сервер может иметь дело с аутентификацией, куки, сеансами и т.д.

Использование ресурсов Cross Origin Resource (CORS) - один из немногих методов расслабления SOP. Поскольку по умолчанию SOP "on", установка CORS на стороне сервера позволит отправить запрос на сервер через XMLHttpRequest, даже если запрос был отправлен из другого домена. Это становится полезным, если ваш сервер должен был обслуживать запросы из других доменов (например, если вы предоставляете API).

Я надеюсь, что это очистит различие между SOP и CORS и целями каждого из них.