Коли безпечно вмикати CORS?

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

Access-Control-Allow-Origin: *

Що дозволяє стороннім сайтам телефонувати до моєї служби через AJAX. Поки що все добре.

Однак підрозділ мого веб-API не є загальнодоступним і вимагає автентифікації (досить стандартні матеріали з OAuth та файлом cookie access_token). Чи безпечно вмикати CORS і на цій частині мого сайту?

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

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

Тож мої запитання:

• Чи безпечно вмикати CORS на непублічному вмісті?
• Якщо сервер із підтримкою CORS встановлює session_token через файл cookie, чи буде цей файл cookie збережений у домені сервера CORS або основного сервера веб-сторінок?

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

Призначення CORS полягає в тому, щоб дозволити перехресні запити на запити XHR, надаючи серверу повноваження визначати, яке джерело має доступ до якого ресурсу. Зокрема, CORS представив поле заголовка Origin, яке дозволяє серверу розрізняти регулярні та можливі запити XHR. Це поле заголовка не може встановити або змінити користувач, але встановлюється браузером для запитів XHR.

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

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