Когда безопасно включать CORS? - PullRequest
Новая
       38

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

65 голосов
/ 15 марта 2012

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

Access-Control-Allow-Origin: *

, который позволяет сторонним сайтам вызывать мой сервис через AJAX.Пока все в порядке.

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

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

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

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

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

Ответы [ 2 ]

41 голосов
/ 15 марта 2012

В ответ на ваш второй вопрос (если сервер с поддержкой CORS устанавливает сеанс_token с помощью файла cookie ...?), Файл cookie сохраняется в домене сервера CORS. JS-код главной веб-страницы не может получить доступ к cookie, даже через document.cookie. Файл 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 получить доступ к данным ответа.

20 голосов
/ 15 марта 2012

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

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

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

...