Я недавно був набір Access-Control-Allow-Originдля *того , щоб бути в змозі зробити крос-субдомен Ajax дзвінки.
Тепер я не можу не відчувати, що я піддаю своє оточення ризикам безпеки.
Будь ласка, допоможіть мені, якщо я роблю це неправильно.

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

Тож будь-який сайт може надіслати запит на ваш сайт від імені своїх відвідувачів і обробити його відповідь. Якщо у вас є щось реалізоване на зразок схеми автентифікації або авторизації, заснованої на тому, що автоматично надається браузером (файли cookie, сеанси на основі файлів cookie тощо), запити, ініційовані сторонніми сайтами, також будуть використовувати їх.

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

Access-Control-Allow-Origin: *цілком безпечно додавати до будь-якого ресурсу, якщо тільки цей ресурс не містить приватних даних, захищених чимось іншим, ніж стандартні облікові дані (файли cookie, базовий auth, клієнтські сертифікати TLS).

Напр .: Дані, захищені файлами cookie, є безпечними

Уявіть https://example.com/users-private-data, що може відкривати приватні дані залежно від стану входу користувача. Цей стан використовує сесійне cookie. Це безпечно , щоб додати Access-Control-Allow-Origin: *до цього ресурсу, так як цей заголовок дозволяє отримати доступ до відповіді , тільки якщо запит зроблено без печива і печиво потрібно , щоб отримати особисті дані. В результаті приватні дані не просочуються.

Напр .: Дані, захищені локацією / ip / внутрішньою мережею, не є безпечними (на жаль, часто зустрічаються з інтрамережами та побутовою технікою):

Уявіть https://intranet.example.com/company-private-data, що відкриває дані приватної компанії, але це можна отримати, лише якщо ви перебуваєте в мережі Wi-Fi компанії. Це небезпечно , щоб додати Access-Control-Allow-Origin: *до цього ресурсу, так як він захищений використовувати що - то інше , ніж стандартні облікові дані. В іншому випадку поганий сценарій може використовувати вас як тунель до інтрамережі.

Практичне правило

Уявіть, що побачить користувач, якби він отримав доступ до ресурсу у вікні анонімного перегляду. Якщо ви задоволені тим, що всі бачать цей вміст (включаючи вихідний код, який отримав веб-переглядач), це сміливо додавати Access-Control-Allow-Origin: *.

AFAIK, Access-Control-Allow-Origin - це лише заголовок http, що надсилається з сервера до браузера. Обмеження його певною адресою (або відключення її) не робить ваш сайт більш безпечним для, наприклад, роботів. Якщо роботи хочуть, вони можуть просто проігнорувати заголовок. Звичайні веб-переглядачі там (Explorer, Chrome тощо) за замовчуванням шанують заголовок. Але така програма, як Postman, просто ігнорує її.

Кінцевий сервер насправді не перевіряє, що таке "походження" запиту, коли він повертає відповідь. Він просто додає заголовок http. Саме браузер (клієнтський кінець) надіслав запит, який вирішує прочитати заголовок контролю доступу та діяти на нього. Зауважте, що у випадку XHR він може скористатися спеціальним запитом "OPTIONS", щоб спочатку запитати заголовки.

Отже, кожен, хто має здібності до творчих сценаріїв, може легко проігнорувати весь заголовок, що б там не було встановлено.

Див. Також Можливі проблеми безпеки щодо налаштування Access-Control-Allow-Origin .

Тепер фактично відповісти на питання

Я не можу не відчути, що я піддаю своє оточення ризикам безпеки.

Якщо хтось хоче напасти на вас, він може легко обійти Access-Control-Allow-Origin. Але ввімкнувши "*", ви надаєте зловмиснику ще кілька "векторів атак", наприклад, використовуючи звичайні веб-браузери, які шанують цей HTTP-заголовок.

Ось два приклади, розміщені як коментарі, коли підключення підкреслює справді проблематично:

Припустимо, я заходжу на веб-сайт свого банку. Якщо я перейду на іншу сторінку, а потім повернусь до свого банку, я все ще ввійду в систему через cookie. Інші користувачі в Інтернеті можуть звертатися до тих же URL-адрес, що і в моєму банку, але вони не зможуть отримати доступ до мого рахунку без файлу cookie. Якщо дозволено запити між походженнями, шкідливий веб-сайт може ефективно себе представити.

- Бред

Припустимо, у вас є звичайний домашній маршрутизатор, наприклад, Linksys WRT54g або щось подібне. Припустимо, що маршрутизатор дозволяє запити перехресного походження. Сценарій на моїй веб-сторінці може робити запити HTTP до загальних IP-адрес маршрутизатора (наприклад, 192.168.1.1) та перенастроювати маршрутизатор, щоб дозволити атакам. Він навіть може використовувати ваш маршрутизатор безпосередньо як вузол DDoS. (Більшість маршрутизаторів мають тестові сторінки, які дозволяють проводити пінг-файли чи прості перевірки HTTP-сервера. Це можна масово зловживати.)

- Бред

Я вважаю, що ці коментарі повинні були відповісти, оскільки вони пояснюють проблему на прикладі реального життя.

У сценарії, коли сервер намагається повністю відключити CORS, встановивши нижче заголовків.

• Access-Control-Allow-Origin: * (повідомляє браузеру, що сервер приймає запити між веб-сайтами від будь-якого ORIGIN)

• Access-Control-Allow-Credentials: true (повідомляє браузеру, що запити на веб-сайті можуть надсилати файли cookie)

У веб-переглядачах існує безпечна помилка, що призведе до помилки нижче

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

Тож у більшості сценаріїв налаштування "Access-Control-Allow-Origin" *не буде проблемою. Однак для захисту від атак сервер може підтримувати список дозволених джерел і кожного разу, коли сервер отримує запит на перехресне походження, він може перевірити заголовок ORIGIN щодо списку дозволених джерел, а потім повторити те саме в Access-Control-Allow-Origin заголовок.

Оскільки заголовок ORIGIN неможливо змінити, запустивши JavaScript у браузері, шкідливий сайт не зможе його підробити.