Когда можно безопасно включить CORS?

Я разрабатываю веб-API JSON/REST, для которого я специально хочу, чтобы сторонние веб-сайты могли позвонить мне через AJAX. Следовательно, моя служба отправляет знаменитый заголовок CORS:

Access-Control-Allow-Origin: *

Что позволяет сайтам сторонних организаций вызывать мою услугу через AJAX. Пока все хорошо.

Однако подразделение моего веб-api не является общедоступным и требует аутентификации (довольно стандартный материал с OAuth и cookie access_token). Безопасно ли включить CORS на эту часть моего сайта?

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

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

Итак, мои вопросы:

Насколько безопасно использовать CORS для непубличного контента?
Если сервер с поддержкой CORS устанавливает session_token через файл cookie, будет ли этот файл cookie сохранен в домене сервера CORS или основного веб-сервера?

Ответ 1

В ответ на ваш второй вопрос (если сервер с поддержкой CORS устанавливает session_token через файл cookie...?), файл cookie сохраняется в домене сервера CORS. На главном веб-странице JS-код невозможно получить доступ к файлу cookie, даже через document.cookie. Куки файлы отправляются только на сервер, когда установлен параметр .withCredentials, и даже тогда он принимается только тогда, когда сервер устанавливает заголовок Access-Control-Allow-Credentials.

Ваш первый вопрос немного более открытый. Это довольно безопасно, но есть способы обойти вещи. Например, злоумышленник может использовать метод отравления DNS, чтобы вызвать запрос предполетной атаки на фактический сервер, но отправить фактический запрос CORS на сервер-изгоев. Вот еще несколько ресурсов по безопасности CORS:

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

Access-Control-Allow-Origin: http://www.example.com

Этот заголовок позволит только http://www.example.com получить доступ к данным ответа.

Ответ 2

Цель CORS состоит в том, чтобы разрешать запросы с кросс-началом для запросов XHR, предоставляя серверу полномочия определять, к какому источнику имеет доступ к какому ресурсу. В частности, CORS представила поле заголовка Origin, которое позволяет серверу рассказать о регулярных и возможных запросах XHR. Это поле заголовка не может быть установлено или изменено пользователем, но установлено браузером для запросов XHR.

Итак, если у вас есть API, который предназначен для использования только XHR, вы можете (и должны) потребовать, чтобы запрос соответствовал CORS. Особенно, если запросы могут также изменять состояние на вашем сервере, так как иначе вы были бы уязвимы для CSRF.

Обратите внимание, что атаки CSRF возможны независимо от CORS, используя другие методы для создания запросов GET и POST. CORS разрешает доступ к ответам серверов XHR-запросов с помощью JavaScript, если сервер разрешает это.