Чи є CORS безпечним способом виконання міждоменних запитів AJAX?

83

Прочитавши про CORS (Cross-Origin Resource Sharing), я не розумію, як це покращує безпеку. Міждоменне спілкування AJAX дозволяється, якщо надіслано правильний заголовок ORIGIN. Як приклад, якщо я відправлю

ПОХОДЖЕННЯ: http://example.com

Сервер перевіряє, чи є цей домен у білому списку, і, якщо він є, заголовок:

Access-Control-Allow-Origin: [отримана URL-адреса тут]

відправляється назад разом із відповіддю (Це простий випадок, є також попередньо встановлені запити, але питання те саме).

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

javascript  ajax  cross-domain  cors 
— Гібаріан 2001
джерело
Прочитайте цю відповідь: комусь незрозуміло, що таке політика того самого походження та CORS і чому вони існують: stackoverflow.com/a/27294846/3340994
— nishantbhardwaj2002,

Відповіді:

54

Ви не можете підробити заголовок Origin за допомогою JavaScript у веб-браузері. CORS призначений для запобігання цьому.

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

Він розроблений таким чином, що враховуючи:

  • Аліса, людина, яка надає API, призначений для доступу через Ajax
  • Боб, людина з веб-браузером
  • Чарлі, третя сторона, яка веде власний веб-сайт

Якщо Боб відвідує веб-сайт Чарлі, то Чарлі не може надсилати JS до браузера Боба, щоб він отримував дані з веб-сайту Аліси та надсилав їх Чарлі.

Вищевказана ситуація стає більш важливою, якщо Боб має обліковий запис користувача на веб-сайті Аліси, який дозволяє йому робити такі речі, як розміщення коментарів, видалення даних або перегляд даних, які не є є для широкої публіки - так як без захисту, JS Чарлі міг сказати , браузер Боба зробити це за спиною Боба (а потім надіслати результати Чарлі).

Якщо ви хочете перешкодити стороннім людям бачити дані, вам потрібно захистити їх за допомогою паролів, сертифікатів клієнта SSL або інших засобів автентифікації / авторизації на основі ідентифікації.

— Квентін
джерело
1
В основному CORS або спільне використання ресурсів та авторизація - це дві окремі речі. Як випливає з абревіатури, це насправді ДОЗВОЛИТИ спільне використання походження. Чи КЛІЄНТУ НАСАЛЬ дозволено це робити, визначає ваша логіка авторизації.
— reaper_unique
150

Мета - запобігти цьому -

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

Ідея полягає в тому, що веб-сайту вашого банку потрібен якийсь спосіб повідомити своєму браузеру, чи слід довіряти сценаріям веб-сайту X доступ до сторінок у вашому банку.

— jcoder
джерело
9
Ваша відповідь теж була дуже чіткою, дякую. Я не підтримав, бо для цього потрібна 15 репутація.
— Gibarian2001,
Отже, CORS не захищає цілісність програми на веб-сайті X, а захищає цілісність БАНКУ, який стверджує, що веб X слід довіряти для здійснення дзвінків через API до БАНКУ?
— luigi7up
7
@ luigi7up: Ні, CORS нічого не захищає, насправді він "послаблює" безпеку, визначаючи винятки із SOP. У Access-Control-Allow-Originзаголовок вказує , який походження (вказано в Originзаголовку) можуть отримати доступ до ресурсу. Зазвичай це дозволяється лише запитам з однаковим походженням. Найважливіша частина тут полягає в тому, що дозвіл / заборона здійснюється БРАУЗЕРОМ, а не сервером. Це означає, що Access-Control-Allow-Originзахищає ваш браузер, а не ресурс на сервері або сам сервер.
— Даніель ф.
Що заважає автору веб-сайту X увійти до банку через серверну систему своїх веб-сайтів, яка потім буде використана як проксі? Це просто додатковий шар, який йому довелося б створити, але він би повністю обійшов проблему CORS, яку він мав би у браузері, я думаю .. Отже, це здається захистом лише для браузера, що здається мені досить безглуздим, якщо ви можете обійти його дуже простим способом ..
— tkit
1
@pootzko: у вашому сценарії зловмисний веб-сайт X не матиме дійсного сеансу для банківського веб-сайту. Навіть якщо жертва увійшла до свого банку (наприклад, на іншій вкладці), шкідливий сайт X не матиме доступу до цього сеансу через політику файлів cookie, що застосовується браузером: браузер ніколи не надсилає файли cookie сеансу банк на веб-сайт X.
— Даніель Ф.
68

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

Суть Originзаголовка - захистити користувача. Сценарій такий:

  • зловмисник створює шкідливий веб-сайт M

  • користувач Аліса обманюється підключитися до M, який містить сценарій, який намагається виконати деякі дії через CORS на сервері B, який насправді підтримує CORS

  • B, ймовірно, не матиме M у своєму Access-Control-Allow-Originзаголовку, бо чому?

  • Ключовим моментом є те, що у M немає засобів підробити або перезаписати Originзаголовок, оскільки запити ініціюються браузером Аліси. Отже, її браузер встановить для (правильного) Originзначення M, яке не входить в Access-Control-Allow-OriginB, тому запит не вдасться.

Аліса могла б змінити Originзаголовок сама, але чому б це зробити, оскільки це означало б, що вона завдає собі шкоди?

TL; DR: OriginЗаголовок захищає невинного користувача. Це не захищає ресурси на сервері. Він піддається зловмиснику на власній машині, але не може бути підроблений на машині, що не знаходиться під його контролем.

Сервери все одно повинні захищати свої ресурси, оскільки відповідний Originзаголовок не означає авторизованого доступу. Однак Originзаголовок, який НЕ збігається, означає несанкціонований доступ.

— Даніель ф.
джерело
11
Дуже приємна відповідь. Найкращий з них загалом IMHO.
— petersaints
Чому це не обрана відповідь? Це явно найкраще. Четвертий момент, згаданий у цій відповіді - це те, про що насправді просить плакат.
— alaboudi
найкраща відповідь Данило. У цьому полягає вся суть CORS: "Основний момент полягає в тому, що M не має засобів підробляти або перезаписувати заголовок Origin, оскільки запити ініціюються браузером ALICE. Отже, її браузер встановить (правильний) Origin на M, який немає в Access-Control-Allow-Origin of B, тому запит буде невдалим. "
— Лукас Лукач
14

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

— Енді Е
джерело
2
"Суть полягає в тому, щоб припинити клієнтським сценаріям доступ до вмісту в іншому домені", це було вирішено за допомогою тієї ж політики походження. Ні? Я маю на увазі, що мій веб-сайт надсилає вам деякі JS, і ваш браузер не дозволить виклики ajax до якогось іншого домену. це та сама політика походження. CORS робить саме те опозицію - дозволяє моєму ajax отримати доступ до іншого домену. Мені тут не вистачає чогось величезного :)
— luigi7up
to @ luigi7up: Так, CORS робить це. Це дозволяє власнику веб-сайту надати доступ до своїх послуг з більш ніж одного довіреного домену.
— SergeyT
6

Прочитавши про CORS, я не розумію, як це покращує безпеку.

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

Але однакова політика походження та CORS мають обмежений обсяг. Зокрема, специфікація CORS не має механізму відхилення запитів. Він може використовувати заголовки, щоб сказати браузеру не дозволяти сторінці з іноземного домену прочитати відповідь. А у випадку попередніх запитів, він може попросити браузер не надсилати йому певні запити з іноземного домену. Але CORS не вказує жодних засобів для сервера відхилити (тобто не виконати) фактичний запит.

Візьмемо приклад. Користувач входить на сайт Aза допомогою файлів cookie. Користувач завантажує шкідливий сайт M, який намагається надіслати форму, яка робить POSTдо A. Що станеться? Ну, з або без CORS, а також із Mдозволеним доменом чи без нього, браузер надішле запит наA файлу cookie авторизації користувача, а сервер буде виконувати шкідливий, POSTяк ніби користувач ініціював його.

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

Тепер використання Originзаголовка може бути важливою частиною вашого захисту CSRF. Дійсно, перевірка цього є частиною поточної рекомендації щодо багатостороннього захисту КСВФ . Але використання Originзаголовка виходить за межі специфікації CORS.

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

— Кевін Крістофер Генрі
джерело
1

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

@daniel f також дає хорошу відповідь на запитання

— алабуді
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.