Что такое CORS?

В прошлом, когда интернет-технологии были еще новинкой, возникали проблемы с подделкой межсайтовых запросов (CSRF). Из-за этого поддельные клиентские запросы из браузера жертвы отправлялись в другое приложение.

Предположим, жертва вошла в приложение своего банка. Затем ее обманом заставили загрузить внешний веб-сайт в новой вкладке браузера. После этого внешний веб-сайт использовал учетные данные жертвы в виде файлов cookie и передал данные в банковское приложение, выдавая себя за жертву. В результате неавторизованные пользователи получили несанкционированный доступ к банковскому приложению.

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

Политика одинакового источника

Сегодня браузеры требуют, чтобы клиенты могли отправлять запросы только тому к ресурсу, источник которого совпадает с URL-адресом клиента. Протокол, порт и имя хоста URL-адреса клиента должны соответствовать серверу, которому отправляется запрос.

Например, рассмотрим сравнение источников приведенных ниже URL-адресов с URL-адресом клиента http://store.aws.com/dir/page.html.

URL-адрес	Результат	Причина
http://store.aws.com/dir2/new.html	Тот же источник	Отличается только путь
http://store.aws.com/dir/inner/other.html	Тот же источник	Отличается только путь
https://store.aws.com/page.html	Другой источник	Другой протокол
http://store.aws.com:81/dir/page.html	Другой источник	Другой порт (для http:// по умолчанию используется порт 80)
http://news.aws.com/dir/page.html	Другой источник	Другой хост

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

Совместное использование ресурсов между разными источниками (CORS) является расширением политики одинакового источника. Он необходим для авторизованного обмена ресурсами с внешними третьими сторонами. Например, вам потребуется CORS, если необходимо получить данные из внешних API, которые являются общедоступными или авторизованными. Также CORS необходим, если вы хотите предоставить авторизованный сторонний доступ к вашим собственным серверным ресурсам.

В HTTP методы запроса являются операциями над данными, которые клиент отправляет серверу для выполнения. К распространенным методам HTTP относятся GET, POST, PUT и DELETE.

При обычном обмене ресурсами между источниками (CORS) браузер отправляет запрос вместе с заголовками управления доступом. Обычно это запросы данных GET, которые считаются низкорисковыми.

Однако некоторые HTTP-запросы считаются сложными и требуют подтверждения со стороны сервера перед отправкой фактического запроса. Процесс предварительного утверждения называется предварительным запросом.

Сложные запросы из разных источников

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

• Методы, отличные от GET, POST и HEAD
• Заголовки, отличные от Accept-Language, Accept или Content-Language
• Заголовки Content-Type, отличные от multipart/form-data, application/x-www-form-urlencoded и text/plain

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

Как работают предварительные запросы

Браузеры создают предварительные запросы по необходимости. Это запрос OPTIONS, подобный следующему.

OPTIONS /data HTTP/1.1 Источник: https://example.com Access-Control-Request-Method: DELETE

Браузер отправляет предварительный запрос перед сообщением с фактическим запросом. Сервер должен ответить на предварительный запрос информацией о запросах из разных источников, которые сервер готов принять с URL-адреса клиента. Заголовки ответа сервера должны содержать следующее.

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

Ниже приведен пример ответа сервера.

HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

В предварительный ответ иногда включается дополнительный заголовок Access-Control-Max-Age. Этот показатель определяет время (в секундах), в течение которого браузер кэширует результаты предварительной проверки в браузере. Кэширование позволяет браузеру отправлять несколько сложных запросов между предварительными запросами. Ему не приходится отправлять еще один предварительный запрос до истечения времени, указанного в параметре max-age.

 

При настройке совместного использования ресурсов между источниками (CORS) на сервере следует учитывать следующее.

Определите соответствующие списки доступа

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

Предположим, что вы пишете регулярное выражение, предоставляющее доступ ко всем сайтам с суффиксом permitted-website.com. Одним выражением вы предоставляете доступ к сайтам api.permitted-website.com и news.permitted-website.com. Но вы также непреднамеренно предоставляете доступ к неавторизованным сайтам, которые могут использовать такие домены, как maliciouspermitted-website.com.

Избегайте использования нулевого источника в списке

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

Однако не следует включать в список доступа нулевое значение. Из-за него возникают угрозы безопасности, поскольку доступ открывается и для несанкционированных запросов, содержащих нулевые заголовки.