Политика того же происхождения в основном предназначена для предотвращения сценариев для других доменов для выполнения запросов AJAX (XMLHTTP) в контексте загруженного домена, а также ограничивает доступ сайтов другого домена к ресурсам сайтов, таким как файлы cookie, локальное хранилище и т. д. как стандартная спецификация, сформулированная для мер безопасности, и каждый браузер по-своему реализует ее, придерживаясь спецификаций.
Говоря «запретить сценариям для других доменов выполнять запросы AJAX (XMLHTTP)», я имею в виду запросы из разных источников, которые не принадлежат одному и тому же домену.
Например, domain.com и test.domain.com принадлежат одному и тому же домену, а test — это поддомен, а test.domain2.com принадлежит совершенно другому домену.
Теперь давайте рассмотрим его последствия для безопасности:
1. Допустим, на сайте site1.com есть вызов API для обновления пароля. Когда пользователь вводит необходимые данные, на серверную часть выполняется вызов HTTP, и подлинность пользователя проверяется с помощью данных сеанса, содержащихся в файлах cookie.
2) Теперь, с учетом сказанного, если злоумышленник создает сайт с именем site2 и имеет код javascript для выполнения HTTP-вызова конечной точке изменения пароля site1. По поведению браузера по умолчанию он прикрепляет все данные cookie, которые у него есть для site1, к запросу, что делает HTTP-вызов успешным, что позволяет злоумышленникам добиться успеха.
3) Чтобы иметь возможность смягчить это, браузеры внедрили SOP, который предписывает движку javascript браузера блокировать любой запрос на междоменные запросы, например, с сайта 2 на сайт 1, если не указано, что это разрешено.
4) Теперь, в этом растущем современном мире с микросервисной архитектурой и множеством поддоменов, это будет очень проблематично. Чтобы обойти это, браузеры поддерживают запросы между источниками, если ответ API говорит об этом с такими заголовками, как Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Credentials и т. д.
5) Чтобы выдвинуть его вперед, когда запрос ajax выполняется с сайта 2 на сайт 1, браузеры проверяют заголовки ответа API и разрешают запрос, если в ответе присутствует какое-либо из этих значений: - Access-Control-Allow-Origin: * или Access -Control-Allow-Origin:site2.com или Access-Control-Allow-Origin:*.site2.com (запись с подстановочным знаком)
6) При этом здесь есть серьезная лазейка, даже если политика поддержки блокирует запрос, это фактически означает, что браузер блокирует доступ site2 для чтения данных ответа, что означает, что запрос уже был отправлен на сервер. Этот сценарий применим только к нескольким запросам при определенных условиях, которые не вызывают предварительный вызов опций. Когда вызов опций выполнен, браузер не позволит пройти запросу на основе ответа заголовка в вызове опций.
7) Теперь идет вторая часть, которая называется Access-Control-Allow-Credentials. В ответе сервера на вызов опций, если сервер устанавливает для заголовка значение true, все конфиденциальные данные сеанса, такие как заголовок авторизации, безопасные файлы cookie будут добавлены к запросам между источниками с сайта 2 на сайт 1.
Примечание. Этот заголовок добавляется только в том случае, если Access-Control-Allow-Origin очень специфичен для домена, что означает, что он не будет работать для значения * в заголовке. Если заголовок Access-Control-Allow-Origin имеет значение *, тогда сработает политика SOP браузера и заблокирует доступ к защищенным данным, если для параметра Access-Control-Allow-Credentials установлено значение true.
Политика происхождения SOP не касается источников изображений и включает внешние сценарии. Чтобы иметь возможность использовать контроль над ними, пройдите через Content Security Policy (CSP). Используя его, вы можете контролировать доступ к внешним сайтам в отношении изображений, скриптов, шрифтов, стилей и т. д. Вы также сможете блокировать небезопасные встроенные оценки на сайте, такие как окна предупреждений, чтобы предотвратить некоторые атаки XSS. Это новый стандарт де-факто, и многие веб-сайты начали его внедрять.
Чтобы иметь возможность предотвращать такие атаки (CSRF-атаки), веб-сайты также внедряют csrf-токен вместе с формой, которая меняется при каждом изменении состояния. Даже если злоумышленник каким-то образом сделает запрос с site2 на site1, запрос не пройдет, так как сервер на site1 проверяет токен csrf вместе с запросом, через который злоумышленник не может получить доступ. Другие меры могут добавить проверку на основе источника, если присутствует заголовок источника.
JSONP предназначен для использования такого механизма с помощью обратных вызовов.
Извините за такой длинный ответ, тема гораздо шире. Это только мое собственное понимание этого, и дайте мне знать, если я где-то ошибаюсь.
person
Hemachand Sai
schedule
11.02.2020
