Русский
Русский
English
Статистика
Реклама

Cross-origin resource sharing

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

11.08.2020 12:12:28 | Автор: admin


Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи CS Visualized: CORS автора Lydia Hallie.

Каждому разработчику приходилось сталкиваться с ошибкой Access to fetched has been blocked by CORS policy. Существует несколько способов быстрого решения данной проблемы. Однако, давайте не будем спешить и подробно рассмотрим, что из себя представляет политика CORS.

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

Допустим, мы хотим получить информацию о пользователе на нашем сайте www.mywebsite.com с сервера, расположенного на сайте api.website.com.



Отлично! Мы только что отправили запрос на сервер и получили в ответ данные в формате JSON.

Теперь попробуем отправить аналогичный запрос на другой домен. Вместо того, чтобы отправлять запрос с www.mywebsite.com, отправим его с www.anotherdomain.com.



Что случилось? Мы отправили точно такой же запрос, но на этот раз браузер показывает какую-то ошибку.

Мы наблюдаем CORS в действии. Почему возникла данная ошибка и что она означает?

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


В вебе присутствует нечто под названием политика общего происхождения (далее ПОП). По умолчанию мы имеем доступ только к тем ресурсам, которые находятся в том же источнике, что и источник нашего запроса. Например, мы можем загрузить изображение, находящееся в https://mywebsite.com/image1.png.

Источник является другим, когда он расположен в другом (под)домене, протоколе или порте.



Круто, но зачем нужна ПОП?

Предположим, что ее не существует, и вы случайно кликаете по вирусной ссылке, которую прислала ваша тетя в Facebook. Данная ссылка перенаправляет вас на вредоносный сайт, имеющий встроенный iframe, который загружает сайт вашего банка и успешно авторизуется там с помощью куки.

Разработчики злого сайта позаботились о том, чтобы он имел доступ к iframe и мог взаимодействовать с содержимым DOM сайта вашего банка для перечисления денежных средств на свой аккаунт от вашего имени.



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

К счастью, существует ПОП. Эта политика ограничивает доступ к ресурсам из других источников.



В данном случае источник www.evilwebsite.com пытается получить доступ к ресурсу из источника www.bank.com. ПОП блокирует такой доступ и запрещает разработчикам плохого сайта доступ к вашим банковским данным.

Хорошо, но как это работает?

CORS на стороне клиента


Несмотря на то, что ПОП применяется только к скриптам, браузеры расширяют ее до любых JavaScript-запросов: по умолчанию мы имеем доступ только к ресурсам из одного источника.



Хм, но у нас часто возникает необходимость получить ресурсы из другого источника. Возможно, нашему фронтенду нужно обратиться к серверному прикладному интерфейсу для загрузки данных. Для безопасного получения ресурсов из других источников браузеры реализуют механизм под названием CORS.

CORS расшифровывается как Cross-Origin Resource Sharing (совместное использование ресурсов). Хотя браузеры запрещают получение ресурсов из других источников, мы можем использовать CORS для изменения этого ограничения, оставаясь при этом в безопасности.

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

Когда происходит запрос к другому источнику, клиент автоматически добавляет в HTTP-запрос заголовок Origin. Значением этого заголовка является источник запроса.



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

CORS на стороне сервера


Как разработчики серверной части приложения, мы можем разрешить получение наших ресурсов другими источниками посредством включения в ответ специальных заголовков, начинающихся с Access-Control-*. На основе значения таких заголовков браузер разрешает совместное использование ресурсов.

Существует несколько CORS-заголовков, но один из них является обязательным: Access-Control-Allow-Origin.

Значение данного заголовка определяет, какие источники могут получать наши ресурсы.

Если мы разрабатываем сервер, который должен быть доступен https://mywebsite.com, мы должны добавить этот домен в заголовок Access-Control-Allow-Origin.



Здорово. Данный заголовок теперь добавляется к ответу сервера, отправляемого клиенту. ПОП больше не запрещает нам получать ресурсы с https://api.mywebsite.com с помощью запросов, отправленных с https://mywebsite.com.



Механизм CORS, реализованный в браузере, проверяет совпадение значений заголовка ответа Access-Control-Allow-Origin и заголовка запроса Origin.

В данном случае источником нашего запроса является https://www.mywebsite.com, указанный в списке заголовка ответа Access-Control-Allow-Origin.



Отлично. Теперь мы можем получать ресурсы из других источников. Что произойдет, если мы попытаемся сделать это из источника, не указанного в Access-Control-Allow-Origin?



Да, CORS заблокировал доступ к ресурсам.

The 'Access-Control-Allow-Origin' header has a value  'https://www.mywebsite.com' that is not equal to the supplied origin. 

В данном случае источником является https://www.anotherwebsite.com, не указанный в Access-Control-Allow-Origin. CORS успешно запретил получение запрашиваемых данных.

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

Access-Control-Allow-Origin это один из многих заголовков, которые мы можем установить. Разработчик серверной части может настраивать CORS для разрешения (запрета) конкретных запросов.

Другим распространенным заголовком является Access-Control-Allow-Methods. CORS разрешает только те запросы из других источников, которые были отправлены с помощью указанных методов.



В данном случае разрешены только запросы, отправленные с помощью методов GET, POST или PUT. Другие методы, такие как PATCH или DELETE будут заблокированы.

Говоря о запросах, отправленных с помощью методов PUT, PATCH и DELETE, CORS обрабатывает их особым образом. Эти непростые запросы иногда называют предварительными (preflight).

Предварительные запросы


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

Запрос является простым, если он отправлен с помощью методов GET или POST и не содержит дополнительных заголовков. Любой другой запрос является предварительным.

Хорошо, но что означает предварительный запрос и зачем нужны такие запросы?

Перед отправкой фактического запроса, клиент направляет серверу предварительный запрос с информацией о фактическом запросе: о его методе, дополнительных заголовках, включая Access-Control-Request-* и т.д.



Сервер получает предварительный запрос и отправляет пустой предварительный ответ, содержащий CORS-заголовки. Браузер получает предварительный ответ и проверяет, будет ли разрешен фактический запрос.



Если да, то браузер отправляет фактический запрос и получает данные в ответ.



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

Для уменьшения количества повторных запросов мы можем закэшировать предварительный ответ посредством добавления заголовка Access-Control-Max-Age в CORS-запрос. Это позволяет избежать повторного направления предварительного запроса.

Полномочия (credentials)


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

Хотя CORS не содержит полномочий по умолчанию, мы можем изменить это с помощью заголовка Access-Control-Allow-Credentials.

Если мы хотим включить куки и другие заголовки авторизации в наш запрос из другого источника, нам нужно присвоить полю withCredentials значение true в запросе и добавить заголовок Access-Control-Allow-Credentials в ответ.



Готово, теперь мы можем включать полномочия в наши запросы из другого источника.

Надеюсь, статья была вам полезной. Благодарю за внимание.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru