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

Question

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

Access-Control-Allow-Origin: * 

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

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

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

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

Так мои вопросы:

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

Answer 1

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

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

• http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
• owasp.org CORS CheatSheet

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

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

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

Answer 2

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

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

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