Cross-Origin Resource Sharing (CORS)
Cross-Origin Resource Sharing (CORS) — механизм, использующий дополнительные HTTP-заголовки, чтобы дать возможность агенту пользователя получать разрешения на доступ к выбранным ресурсам с сервера на источнике (домене), отличном от того, что сайт использует в данный момент. Говорят, что агент пользователя делает запрос с другого источника (cross-origin HTTP request), если источник текущего документа отличается от запрашиваемого ресурса доменом, протоколом или портом.
В целях безопасности браузеры ограничивают cross-origin запросы, инициируемые скриптами. Например, XMLHttpRequest и Fetch API следуют политике одного источника (same-origin policy). Это значит, что web-приложения, использующие такие API, могут запрашивать HTTP-ресурсы только с того домена, с которого были загружены, пока не будут использованы CORS-заголовки.
Механизм CORS поддерживает кросс-доменные запросы и передачу данных между браузером и web-серверами по защищённому соединению. Современные браузеры используют CORS в API-контейнерах, таких как XMLHttpRequest или Fetch, чтобы снизить риски, присущие запросам с других источников.
Кто должен читать данную статью?
Конкретнее, эта статья для web-администраторов, разработчиков серверной стороны и front-end разработчиков. Современные браузеры поддерживают клиентские компоненты cross-origin обмена, включая заголовки и соблюдение правил политики. Но этот новый стандарт означает, что сервера также должны поддерживать новые заголовки запросов и ответов. Другая статья для разработчиков серверной части, описывающая перспективы cross-origin обмена на стороне сервера (с примерами кода на PHP), к дополнительному прочтению.
Какие запросы используют CORS?
Этот стандарт cross-origin обмена используется для разрешения кросс-сайтовых HTTP запросов для:
Эта статья описывает общие понятия Cross-Origin Resource Sharing и включает обсуждение необходимых HTTP заголовков.
Обзор функциональности
Стандарт Cross-Origin Resource Sharing работает с помощью добавления новых HTTP-заголовков, которые позволяют серверам описывать набор источников, которым разрешено читать информацию, запрашиваемую web-браузером. В частности, для методов HTTP-запросов, которые могут привести к побочным эффектам над данными сервера (в частности, для HTTP методов, отличных от GET или для POST запросов, использующих определённые MIME-типы), спецификация требует, чтобы браузеры «предпроверяли» запрос, запрашивая поддерживающие методы с сервера с помощью метода HTTP-запроса OPTIONS и затем, поверх «подтверждения» с сервера, отсылали фактический запрос с фактическим методом HTTP-запроса. Сервера также могут оповещать клиентов должны ли «полномочия» (включая Cookies и HTTP Authentication данные) быть отправлены с запросом.
Следующая секция описывает сценарии, а также предоставляет анализ использования HTTP-заголовков.
Примеры сценариев управления доступом
Обсуждение Cross-Origin Resource Sharing с точки зрения сервера (включая фрагменты кода на PHP) может быть найдено в статье Server-Side Access Control (CORS).
Простые запросы
Некоторые запросы не заставляют срабатывать CORS preflight. Они называются “простыми запросами” в данной статье, хотя Fetch спецификация, определяющая CORS, не использует этот термин. Запрос, для которого не срабатывает CORS preflight— так называемый “простой запросы”—это запрос, удовлетворяющий следующим условиям:
Это приведёт к простому обмену запросами между клиентом и сервером, используя CORS заголовки для обработки привилегий:
Посмотрим, что браузер отправит в таком случае на сервер, а также проверим ответ сервера:
Отметьте, никакой домен, кроме http://foo.example (определён ORIGIN: заголовок в запросе, как в 10 строке выше), не может получить доступ к ресурсу кросс-сайтовым способом. Заголовок Access-Control-Allow-Origin должен содержать значение, которое было отправлено в заголовке Origin запроса.
Предварительные запросы
В отличии от “простых запросов” (обсуждено выше), «предварительные» запросы сначала отправляют HTTP-запрос методом OPTIONS к ресурсу на другом домене, чтобы определить, является ли фактический запрос безопасным для отправки. Кросс-сайтовые запросы предварительно просматриваются таким образом, так как они могут быть причастны к пользовательским данным.
В частности, запрос предварительно просматривается, если выполняется любое из следующих условий:
Ниже приведён пример запроса, который будет предварительно просмотрен.
Замечание: как описано ниже, фактический POST запрос не включает Access-Control-Request-* заголовки; они нужны только для OPTIONS запроса.
Как только предварительный запрос завершён, отправляется настоящий запрос:
Предварительные запросы и переадресации
Большинство браузеров в настоящее время не поддерживают следующие переадресации для предварительных запросов. Если переадресация происходит для предварительного запроса, большинство современных браузеров сообщат об ошибке, такой как следующее.
Запрос был перенаправлен на ‘https://example.com/foo’, который запрещён для запросов из разных источников, требующих предварительной проверки
Запрос требует предварительной проверки, которая запрещена для перенаправления между источниками
Протокол CORS изначально требовал такого поведения, но впоследствии был изменён, чтобы больше не требовать его. Однако большинство браузеров ещё не реализовали это изменение и все ещё демонстрируют поведение, которое требовалось изначально.
Поэтому, пока браузеры не догонят спецификацию, вы можете обойти это ограничение, выполнив одно или оба из следующих действий:
Но если невозможно внести эти изменения, то возможен другой способ:
Однако, если запрос инициирует предварительную проверку из-за наличия в запросе заголовка `Authorization`, вы не сможете обойти ограничение, используя описанные выше шаги. И вы вообще не сможете обойти это, если у вас нет контроля над сервером, на который делается запрос.
Запросы с учётными данными
В этом примере контент, изначально загруженный из http://foo.example, выполняет простой GET запрос к ресурсу http://bar.other, который устанавливает файлы cookie. Содержимое на foo.example может содержать такой JavaScript:
Вот пример обмена между клиентом и сервером:
Запросы с учётными данными и wildcards
В процессе ответа на запрос с учётными данными сервер обязан указать точный источник в поле заголовка Access-Control-Allow-Origin вместо спецсимвола » * «.
Отметьте, что заголовок ответа Set-Cookie в примере выше также устанавливает дополнительные куки. В случае неудачи, возникает исключение, в зависимости от используемого API.
Заголовки HTTP ответов
Эта секция содержит список заголовков HTTP ответов, которые сервер шлёт в ответ на запрос доступа, как описано в спецификации совместного использования ресурсов между разными источниками. В предыдущей секции это описано в действии.
Access-Control-Allow-Origin
Access-Control-Allow-Origin определяет либо один источник, что указывает браузеру разрешить этому источнику доступ к ресурсу; либо — для запросов без учётных данных — значение » * «, которое говорит браузеру разрешить запросы из любых источников.
Например, чтобы разрешить http://mozilla.org доступ к ресурсу, можно указать:
Если сервер возвращает название хоста, вместо «*», также может быть указан заголовок Vary со значением Origin, чтобы показать клиентам, что ответы с сервера будут отличаться в зависимости от значения заголовка запроса Origin.
Access-Control-Expose-Headers
The Access-Control-Expose-Headers (en-US) header lets a server whitelist headers that browsers are allowed to access. For example:
This allows the X-My-Custom-Header and X-Another-Custom-Header headers to be exposed to the browser.
Access-Control-Max-Age
The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.
The delta-seconds parameter indicates the number of seconds the results can be cached.
Access-Control-Allow-Credentials
The Access-Control-Allow-Credentials (en-US) header Indicates whether or not the response to the request can be exposed when the credentials flag is true. When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.
Access-Control-Allow-Methods
The Access-Control-Allow-Methods header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.
An example of a preflight request is given above, including an example which sends this header to the browser.
Access-Control-Allow-Headers
The Access-Control-Allow-Headers header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
The HTTP request headers
This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site XMLHttpRequest capability do not have to set any cross-origin sharing request headers programmatically.
Origin
The Origin header indicates the origin of the cross-site access request or preflight request.
The origin is a URI indicating the server from which the request initiated. It does not include any path information, but only the server name.
Note that in any access control request, the Origin header is always sent.
Access-Control-Request-Method
The Access-Control-Request-Method (en-US) is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.
Examples of this usage can be found above.
Access-Control-Request-Headers
The Access-Control-Request-Headers (en-US) header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.
Небезопасный cross-origin resource sharing
Что такое CORS?
CORS — это механизм безопасности, который позволяет веб-странице из одного домена обращаться к ресурсу с другим доменом (кросс-доменным запросом). Без таких функций, как CORS, веб-сайты ограничиваются доступом к ресурсам одного и того же происхождения через так называемую политику единого происхождения.
Первым шагом в понимании CORS является знание того, как работают некоторые функции безопасности веб-браузеров. По умолчанию веб-браузеры не разрешают AJAX-запросы на сайты, кроме сайта, который вы посещаете. Это называется политикой единого происхождения, и это важная часть модели веб-безопасности. Совместное использование ресурсов между разными источниками (cross-origin resource sharing) — это механизм HTML 5, который дополняет политику единого происхождения для упрощения совместного использования ресурсов домена между различными веб-приложениями.
Спецификация CORS определяет набор заголовков, которые позволяют серверу и браузеру определять, какие запросы для междоменных ресурсов (изображения, таблицы стилей, сценарии, данные и т. д.) разрешены, а какие нет. CORS является техникой для ослабления правила одного источника, позволяя JavaScript на web странице обрабатывать REST API запросы от другого источника.
По своей сути, CORS это защитная оболочка для браузера. Совместное использование ресурсов между разными источниками очень важно в современном мире сложных веб-приложений, и все браузеры поддерживают его. В частности, CORS обычно используется для междоменных AJAX запросов.
Обмен запросами
Взаимодействие ресурсов начинается с отправки GET, POST или HEAD запросу к тому или иному ресурсу на сервере. Тип содержимого POST запроса ограничен application/x-www-form-urlencoded, multipart/form-data или plaintext. Запрос включает заголовок Origin, который и указывает на происхождение клиентского кода.
Веб приложение проверяет происхождение запроса и на основании Origin либо принимает запрос, либо отвергает его. Если запрос принят, запрашиваемые сервер ответит заголовком Access-Control-Allow-Origin. Этот заголовок будет указывать клиенту с каким происхождением будет разрешен доступ. Принимая во внимание, что Access-Control-Allow-Origin соответствует Origin запроса, браузер разрешит запрос.
При запросе на site.ru/resource с site.com/some будут следующие заголовки:
Если запрос принят, запрашиваемый сервер добавляет к ответу заголовок Access-Control-Allow-Origin, содержащий домен запроса site.com.
Access-Control-Allow-Origin указывает, какие домены могут обращаться к ресурсам сайта. Например, если компания имеет домены site.ru и site.com, то ее разработчики могут использовать этот заголовок, чтобы предоставить site.com доступ к ресурсам site.ru.
Access-Control-Allow-Methods определяет, какие HTTP-запросы (GET, PUT, DELETE и т. д.) могут быть использованы для доступа к ресурсам. Этот заголовок позволяет повысить безопасность, указав какие методы действительны, когда site.com обращается к ресурсам site.ru.
Access-Control-Max-Age указывает время жизни предзапроса (также он называется «предполетным») доступности того или иного метода, после которого должен быть выполнен новый запрос на тот или иной метод.
Отказ от политики запроса из белого списка
Использование правильных заголовков, методов и доверенных доменов вроде бы не позволяет злоумышленнику вклиниться в эту цепочку обмена. На самом деле это не так. И подводит здесь коварная *.
Наиболее распространенная проблема безопасности при внедрении CORS — это отказ от проверки запроса белых списков. Зачастую разработчики устанавливают значение для Access-Control-Allow-Origin в ‘*’. Это позволяет любому домену в Интернете получать доступ к ресурсам этого сайта.
Основания проблема кроется в том, что многие компании размещают API в пределах домена, не ограничивания к нему доступ политикой «белого списка». Это порождает уязвимость.
Attack scenario
Большинство веб-приложений использует файлы cookie для отслеживания информации о сеансе. При генерации cookie ограничены определенным доменом. При каждом HTTP запросе к этому домену браузер подставлять значение cookie, созданные для этого домена. Это относится к каждому HTTP запросу — для получения изображений, страниц или AJAX-вызовов.
Что это означает на практике: при авторизации в goodsite.ru, cookie генерируются и хранятся для этого домена. Веб-приложение goodsite.ru основано на технологии SPA и содержит REST API на goodsite.ru/api для взаимодействия с помощью AJAX. Предположим, что вы просматриваете badsite.ru, будучи авторизованным на goodsite.ru. Без ограничения Access-Control-Allow-Origin по белому списку (с указанием сайта) badsite.ru может выполнить любой разрешенный аутентифицированный запрос к goodsite.ru, даже не имея прямого доступа к сессионной cookie!
Это связано с тем, что браузер автоматически привязывает файлы cookie к goodsite.ru для любых HTTP запросов в этом домене, включая AJAX запросы от badsite.ru в goodsite.ru. Таким образом атакующий может взаимодействовать даже с вашим внутренним ресурсом, недоступным в сети интернет и находящимся в корпоративной сети.
Наглядные примеры
В качестве примера приведу код OWASP Testing Guide. Уязвимое веб-приложение, с неверно настроенной политикой Access-Control-Allow-Origin.
Например, такой запрос будет показывать содержимое файла profile.php:
Т.к. отсутствует проверка URL-адреса, атакующий может добавить скрипт, который будет выполняться в контексте домена example.foo со следующим URL:
В качестве еще одного примера рекомендую ознакомиться с Stealing contact form data on www.hackerone.com using Marketo Forms XSS with postMessage frame-jumping and jQuery-JSONP — публичным раскрытием уязвимости, включая небольшую видео-демонстрацию.
Защитные меры
Используйте белые списки доменов. Если такой возможности нет — размещайте API вне домена — политики CORS для sub.site.ru, site.ru и даже разным портам будут различаться.
Указывайте конкретные методы обращения.
Не используйте wildcard — CORS учитывает или * или домен.
Обязательно указывайте протокол. «Access-Control-Allow-Origin: site.ru» не будет учтён, поскольку протокол отсутствует.
При использовании Access-Control-Allow-Credentials: true всегда используется Access-Control-Allow-Origin: домен — при использовании * браузер не получит ответ.
Я хотел бы включить некоторые подсказки ресурсов предварительного соединения на моем сайте, чтобы браузеры могли (например) подключиться к jQuery CDN, прежде чем они действительно увидят тег script, который вызывает CDN. Я не уверен, должен ли я включать атрибут «crossorigin» или каково его значение. Спецификации говорят, в частности,
Чтобы инициировать предварительное соединение, пользовательский агент должен выполнить эти шаги:
Я не знаю, как интерпретировать этот алгоритм. Если я предварительно подключусь к CDN, который позволит любому загружать его содержимое без каких-либо учетных данных, какое значение я должен использовать для атрибута «crossorigin»?
Я искал то же самое, и я нашел это
Здесь говорится, что если вы не используете атрибут кросс-происхождения, пользовательский агент просто выполняет поиск DNS, но не устанавливает соединение с конкретным доменом. Таким образом, атрибут crossorigin необходим, если вам нужно предварительно подключиться к кросс-домену, например так:
Также, если вы хотите отправить некоторые учетные данные в этот конкретный междоменный домен, вы можете установить значение для перекрестного поиска, так как в crossorigin = use-credentials противном случае я думаю, что значение по умолчанию является анонимным.
Во всяком случае, в моем понимании:
Может, кто-нибудь меня поправит.
PS : Текущая версия страницы Mozilla для темы означает:
Недопустимое ключевое слово и пустая строка будут обрабатываться как анонимное ключевое слово.
Это зависит от двух вещей:
Шрифты, с другой стороны, используют CORS.
Вот сообщение о переполнении стека, где я столкнулся с той же проблемой.
Я не углублялся, когда необходимы учетные данные CORS. Я не видел пример, где они нужны, так что, скорее всего, вы в безопасности crossorigin (например, `crossorigin =» anonymous «).
Все ответы до сих пор кажутся либо упрощенными, неполными или частично неправильными (тема сложная, вещи смущенно названы и плохо документированы!), Так что вот мое понимание:
Запрос того же происхождения ( example.com запрашивает субресурс из example.com )
Подлежит проверке : что если запрос того же источника имеет crossorigin атрибут: используется или игнорируется?
Запрос перекрестного происхождения ( example.com запрашивает субресурс из another.com )
Fetch: запросы на другие сайты
Если мы сделаем запрос fetch на другой веб-сайт, он, вероятно, завершится неудачей.
Например, давайте попробуем запросить http://example.com :
Вызов fetch не удался, как и ожидалось.
Ключевым понятием здесь является источник (origin) – комбинация домен/порт/протокол.
Запросы на другой источник – отправленные на другой домен (или даже поддомен), или протокол, или порт – требуют специальных заголовков от удалённой стороны.
Эта политика называется «CORS»: Cross-Origin Resource Sharing («совместное использование ресурсов между разными источниками»).
Зачем нужен CORS? Экскурс в историю
CORS существует для защиты интернета от злых хакеров.
Серьёзно. Давайте сделаем краткое историческое отступление.
Многие годы скрипт с одного сайта не мог получить доступ к содержимому другого сайта.
В то время в JavaScript не было методов для сетевых запросов. Это был «игрушечный» язык для украшения веб-страниц.
Но веб-разработчики жаждали большей власти. Чтобы обойти этот запрет и всё же получать данные с других сайтов, были придуманы разные хитрости.
Использование форм
Одним из способов общения с другим сервером была отправка туда формы
Таким способом было возможно сделать GET/POST запрос к другому сайту даже без сетевых методов, так как формы можно отправлять куда угодно. Но так как запрещено получать доступ к содержимому с другого сайта, прочитать ответ было невозможно.
Если быть точным, были трюки и для этого, требующие специального кода на странице и в ифрейме, так что общение с ифреймом было технически возможно. Сейчас мы не будем вдаваться в подробности, пусть эти динозавры покоятся в мире.
Использование скриптов
Комментарии
Русские Блоги
@CrossOrigin подробное объяснение
Каталог статей
Аннотация @CrossOrigin
По соображениям безопасности браузеры запрещают Ajax-вызовы ресурсов, находящихся за пределами текущего источника. Например, когда вы проверяете свой банковский счет на одной вкладке, у вас может быть веб-сайт EVILL на другой вкладке. Скрипт от EVILL не может делать Ajax-запросы к вашему банковскому API (снимать деньги с вашего счета!) С вашими учетными данными.
1. Междоменная поддержка (CORS):
Spring Framework 4.2 GA обеспечивает первоклассную поддержку CORS, что упрощает и упрощает его настройку по сравнению с обычными решениями на основе фильтров. Таким образом, версия springMVC должна быть 4.2 или выше для поддержки @CrossOrigin.
2. Как пользоваться:
1. Контроллер настраивает CORS
1.1 CORS конфигурация метода контроллера
Вы можете добавить аннотацию @CrossOrigin к методу обработчика аннотации @RequestMapping, чтобы включить CORS (по умолчанию @CrossOrigin разрешает все источники и HTTP-методы, указанные в аннотации @RequestMapping):
2 параметра в @CrossOrigin:
1.2, включите @CrossOrigin для всего контроллера
В этом примере междоменная поддержка включена для методов обработки retrieve () и remove (). Вы также можете увидеть, как настроить конфигурацию CORS с помощью атрибута @CrossOrigin.
1.3, используйте конфигурацию CORS на уровне контроллера и метода
Spring объединит два атрибута аннотации для создания объединенной конфигурации CORS.
1.4, если вы используете Spring Security
Обязательно включите CORS на уровне безопасности Spring и позвольте ему использовать преимущества конфигурации, определенной на уровне Spring MVC.
2. Глобальная конфигурация CORS
В дополнение к мелкозернистой конфигурации на основе аннотаций вам может также потребоваться определить некоторые глобальные конфигурации CORS. Это похоже на использование фильтров, но может быть объявлено как Spring MVC и в сочетании с мелкозернистой конфигурацией @CrossOrigin. По умолчанию разрешены все источники и методы GET, HEAD и POST.
3. Пространство имен XML
Вы также можете настроить пространство имен CORS и MVC XML.
а. Если доступны все методы всего проекта, вы можете настроить его так
Эта минимальная конфигурация XML заставляет CORS иметь те же атрибуты по умолчанию, что и JavaConfig в режиме пути / **:
Среди них * означает соответствие следующему слою; ** означает, что независимо от того, сколько слоев существует, он может быть сопоставлен.
Можно сопоставить следующие пути:
Поскольку * может соответствовать только пути следующего слоя, если вы хотите сопоставить, независимо от того, сколько слоев существует, конфигурация будет следующей:
Примечание. Фактически, один (*) становится двумя (**)
б. Вы также можете объявить несколько сопоставлений CORS с настраиваемыми атрибутами:
c. Если вы используете Spring Security, не забудьте включить CORS на уровне безопасности Spring:
4、How does it work?
a、 AbstractHandlerMapping#setCorsConfiguration() Позволяет указать отображение, которых существует несколько CorsConfiguration Сопоставьте шаблон пути, например / api / **.
б. Подклассы можно переписывать AbstractHandlerMapping категория getCorsConfiguration(Object, HttpServletRequest) Способ предоставить свой собственный CorsConfiguration 。
c. Программа обработки может быть реализована CorsConfigurationSource Интерфейс (например, ResourceHttpRequestHandler ) Предоставлять по одному на каждый запрос CorsConfiguration 。
5. Поддержка CORS на основе фильтров.
В качестве альтернативы другим методам, упомянутым выше, среда Spring также предоставляет CorsFilter. В этом случае вам не нужно использовать @CrossOrigin или WebMvcConfigurer # addCorsMappings (CorsRegistry). Например, вы можете объявить следующий фильтр в приложении Spring Boot:
В-третьих, причина, по которой весенняя аннотация @CrossOrigin не работает
Методы Get и Post не указаны в аннотации @RequestMapping. После определенного указанного проблема решается.
Аналогичный код выглядит следующим образом:
