CORS и заголовок ответа Access-Control-Allow-Origin
В этом разделе мы объясняем, что такое заголовок Access-Control-Allow-Origin в контексте CORS и как он является частью реализации CORS.
Спецификация межисточникового совместного использования ресурсов (CORS) обеспечивает контролируемое ослабление политики одного источника (SOP) для HTTP-запросов к одному домену веб-сайта с другого посредством набора HTTP-заголовков. Браузеры разрешают доступ к ответам на межисточниковые запросы на основании инструкций в этих заголовках.
Что такое заголовок ответа Access-Control-Allow-Origin?
Заголовок Access-Control-Allow-Origin включается в ответ одного веб-сайта на запрос, исходящий с другого веб-сайта, и указывает разрешенный источник (origin) запроса. Веб-браузер сравнивает Access-Control-Allow-Origin с источником (origin) запрашивающего веб-сайта и разрешает доступ к ответу, если они совпадают.
Реализация простого межисточникового обмена ресурсами
Спецификация межисточникового совместного использования ресурсов (CORS) предписывает содержимое заголовков, обмениваемых между веб-серверами и браузерами, которое ограничивает источники для запросов веб-ресурсов за пределами домена origin. Спецификация CORS определяет набор протокольных заголовков, из которых Access-Control-Allow-Origin является наиболее значимым. Этот заголовок возвращается сервером, когда веб-сайт запрашивает кросс-доменный ресурс, при этом браузер добавляет заголовок Origin.
Например, предположим, что веб-сайт с origin normal-website.com инициирует следующий кросс-доменный запрос:
GET /data HTTP/1.1
Host: robust-website.com
Origin : https://normal-website.comСервер на robust-website.com возвращает следующий ответ:
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://normal-website.comБраузер позволит коду, выполняющемуся на normal-website.com, получить доступ к ответу, поскольку источники совпадают.
Спецификация Access-Control-Allow-Origin допускает несколько источников, значение null или подстановочный символ *. Однако ни один браузер не поддерживает несколько источников, и существуют ограничения на использование подстановочного символа *.
Обработка межисточниковых запросов ресурсов с учетными данными
Поведение межисточниковых запросов по умолчанию — передавать запросы без учетных данных, таких как cookie и заголовок Authorization. Однако кросс-доменный сервер может разрешить чтение ответа при передаче ему учетных данных, установив заголовок CORS Access-Control-Allow-Credentials в значение true. Теперь, если запрашивающий веб-сайт с помощью JavaScript объявляет, что он отправляет cookie вместе с запросом:
И ответ на запрос таков:
Тогда браузер позволит запрашивающему веб-сайту прочитать ответ, потому что заголовок ответа Access-Control-Allow-Credentials установлен в значение true. В противном случае браузер не разрешит доступ к ответу.
Ослабление спецификаций CORS с подстановочными символами
Заголовок Access-Control-Allow-Origin поддерживает подстановочные символы. Например:
К счастью, с точки зрения безопасности использование подстановочного символа ограничено спецификацией, поскольку вы не можете комбинировать подстановочный символ с межисточниковой передачей учетных данных (аутентификация, cookie или клиентские сертификаты). Следовательно, ответ кросс-доменного сервера вида:
не допускается, так как это было бы крайне небезопасно и раскрывало бы любой аутентифицированный контент на целевом сайте всем.
С учетом этих ограничений некоторые веб-серверы динамически создают заголовки Access-Control-Allow-Origin на основе источника, указанного клиентом. Это обходное решение ограничений CORS, которое небезопасно. Позже мы покажем, как это можно проэксплуатировать.
Предварительная проверка (preflight)
Предварительная проверка была добавлена в спецификацию CORS для защиты легаси-ресурсов от расширенных возможностей запросов, разрешенных CORS. При определенных обстоятельствах, когда междоменный запрос включает нестандартный HTTP-метод или заголовки, межисточниковому запросу предшествует запрос с использованием метода OPTIONS, и протокол CORS требует первоначальной проверки того, какие методы и заголовки разрешены до допуска межисточникового запроса. Это называется предварительной проверкой (preflight). Сервер возвращает список разрешенных методов в дополнение к доверенному источнику, и браузер проверяет, разрешен ли метод запрашивающего веб-сайта.
Например, это предварительный запрос, который пытается использовать метод PUT вместе с пользовательским заголовком запроса под названием Special-Request-Header:
Сервер может вернуть такой ответ:
Этот ответ определяет разрешенные методы (PUT, POST и OPTIONS) и допустимые заголовки запроса (Special-Request-Header). В данном конкретном случае кросс-доменный сервер также позволяет отправку учетных данных, а заголовок Access-Control-Max-Age определяет максимальный срок кэширования ответа предварительной проверки для повторного использования. Если методы и заголовки запроса разрешены (как в этом примере), тогда браузер обрабатывает межисточниковый запрос обычным образом. Предварительные проверки добавляют дополнительный цикл HTTP-запроса к кросс-доменному запросу, поэтому они увеличивают накладные расходы при просмотре.
Защищает ли CORS от CSRF?
CORS не обеспечивает защиту от атак подделки межсайтовых запросов (CSRF), это распространенное заблуждение.
CORS — это контролируемое ослабление политики одного источника, поэтому плохо настроенный CORS фактически может повысить вероятность атак CSRF или усугубить их воздействие.
Существует множество способов выполнения атак CSRF без использования CORS, включая простые HTML-формы и кросс-доменные включения ресурсов.
Last updated