CORS - Якою мотивацією є подання запитів на попередній політ?

Перехресне походження ресурсів - це механізм, який дозволяє веб-сторінці робити XMLHttpRequests до іншого домену (з wikipedia ).

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

Отже, моє запитання не в тому, як працюють CORS / передпольотні, а в тому , що полягає в тому, щоб розробити передпланові перегляди як новий тип запиту . Я не бачу жодної причини, чому сервер A повинен надіслати передполіт (PR) на сервер B просто для того, щоб дізнатись, чи буде прийнятий реальний запит (RR) чи ні - це, безумовно, було б можливо B прийняти / відхилити RR без будь-який попередній піар.

Після небагато пошуку я знайшов цю інформацію на www.w3.org (7.1.5):

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

Я вважаю, що це найскладніше для розуміння речення. Моя інтерпретація (краще називати це "найкраща здогадка") полягає в тому, що мова йде про захист сервера B від запитів сервера C, які не знають про специфікацію.

Чи може хто-небудь пояснити сценарій / показати проблему, що PR + RR вирішує краще, ніж RR поодинці?

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

Ключове розуміння полягає в тому, що запити перед польотом не є предметом безпеки . Швидше, вони не є зміною правил .

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

Тут є три сценарії:

1. Старі сервери, які вже не розробляються, і розроблені до CORS. Ці сервери можуть робити припущення, що вони ніколи не отримуватимуть, наприклад, міждоменний запит DELETE. Цей сценарій є головним бенефіціаром механізму передпольотного польоту. Так, ці послуги вже можуть зловживати зловмисним або невідповідним агентом користувача (і CORS нічого не робить, щоб це змінити), але у світі з CORS механізм передпольоту забезпечує додаткову перевірку надійності, щоб клієнти та сервери не перерва, оскільки основні правила Інтернету змінилися.

2. Сервери, які ще знаходяться на стадії розробки, але містять багато старого коду і для яких неможливо / бажано перевірити весь старий код, щоб переконатися, що він працює належним чином у світі між доменами. Цей сценарій дозволяє серверам поступово відмовлятися від CORS, наприклад, кажучи "Тепер я дозволю саме цей заголовок", "Тепер я дозволю саме це HTTP-дієслово", "Тепер я дозволять використовувати файли cookie / auth надіслано "і т. д. Цей сценарій виграє від механізму передпольоту.

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

Якою була мотивація введення запитів на попередній політ?

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

У цьому і полягає сенс цієї частини специфікації : "Для захисту ресурсів від перехресних запитів, які не могли походити від певних агентів користувача до існування цієї специфікації, робиться запит перед польотом для того, щоб ресурс усвідомлював цю специфікацію."

Чи можете ви надати мені приклад?

Давайте уявимо, що користувач веб-переглядача входить на свій банківський сайт за адресою A.com. Коли вони переходять до шкідливих B.com, ця сторінка містить деякий Javascript, на який намагається надіслати DELETEзапит A.com/account. Оскільки користувач увійшов у систему A.com, цей запит, якщо він буде надісланий, включає куки, які ідентифікують користувача.

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

Браузер може просто надіслати DELETEта дозволити серверу вирішити, як з ним поводитися. Але що робити, якщо A.comне знають про протокол CORS? Це може йти вперед і стратити небезпеку DELETE. Можливо, було припущено, що завдяки політиці веб-переглядача щодо того самого оригіналу браузера він ніколи не може отримати такий запит, і, отже, він ніколи не був загартований проти такої атаки.

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

Чому вся ця суєта щодо браузера не може зловмиснику просто надіслати DELETEзапит із власного комп’ютера?

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

Це звучить , як Cross-Site Request Підробка , де форма на сайті B.comбанку , POSTщоб A.comз печивом користувача і нанести шкоду.

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

Але дивлячись на вимоги до "простих" запитів, які не потребують попереднього перегляду, я бачу, що POSTце все ж дозволено. Це може змінити стан і видалити дані так само, як DELETE!

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

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

Ви впевнені в цьому? Не рідкість для декількох серверів обробляти запити для одного домену. Наприклад, може статися так, що запити A.com/url1обробляються одним видом сервера, а запити A.com/url2обробляються різним сервером. Як правило, сервер, що обробляє один ресурс, може гарантувати безпеку щодо всіх ресурсів у цьому домені.

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

Гарна ідея! Насправді ж заголовок Access-Control-Policy-Pathбув запропонований саме для цієї мети. Зрештою, це було вимкнено із специфікації, мабуть через те, що деякі сервери неправильно реалізували специфікацію URI таким чином, що запити до шляхів, які видаються безпечними для браузера, насправді не були б безпечними на зламаних серверах.

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

Думки різняться.

Ну, як мінімум, браузери будуть кешувати попередній перехід для однієї URL-адреси?

Так. Хоча, мабуть, не дуже довго. У браузерах WebKit максимальний час кешування перед польотом наразі становить 10 хвилин .

Зітхнути. Що ж, якщо я знаю, що мої сервери обізнані з CORS, і тому мені не потрібен захист, який пропонують запити перед польотом, чи є мені спосіб уникнути їх?

Ваш єдиний реальний варіант - переконатися, що ви відповідаєте вимогам до "простих" запитів. Це може означати відмову від користувацьких заголовків, які ви б інакше включали (як X-Requested-With), брехні про Content-Typeабо більше.

Що б ви не робили, ви повинні переконатися, що у вас є належний захист CSRF, оскільки специфікація CORS не стосується відхилення "простих" запитів, включаючи небезпечні POST. Як зазначено в специфікації : "ресурси, для яких прості запити мають значення, окрім пошуку, повинні захищати себе від підробки міжміських запитів".

Розглянемо світ запитів між доменами перед CORS. Ви можете виконати стандартну форму POST або використовувати scriptабо imageтег, щоб подати GET-запит. Ви не можете зробити будь-який інший тип запиту, окрім GET / POST, і ви не можете видавати спеціальні заголовки для цих запитів.

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

Таким чином, GET / POST запити без будь-яких спеціальних заголовків не потребують попереднього перельоту, оскільки ці запити вже були можливі перед CORS. Але будь-який запит з допомогою призначених для користувача заголовків або PUT / DELETE запитів, дійсно потрібен передпольотний, так як вони є новими для CORS специфікації. Якщо сервер нічого не знає про CORS, він відповість без будь-яких заголовків CORS, і фактичний запит не буде зроблений.

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

CORS дозволяє вказувати більше типів заголовків і методів, ніж раніше було можливо з крос-походженням <img src>або <form action>.

Деякі сервери могли бути (погано) захищені з припущенням, що браузер не може робити, наприклад, DELETEзапит перехресного походження або запит перехресного походження з X-Requested-Withзаголовком, тому такі запити "довіряють".

Щоб переконатися, що сервер дійсно реально підтримує CORS, а не просто реагує на випадкові запити, попередній політ виконується.

Ось ще один спосіб поглянути на це за допомогою коду:

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

Попередньо CORS, спроба експлуатувати вище буде невдалою, оскільки вона порушує політику того самого походження. API, розроблений таким чином, не потребував захисту XSRF, оскільки він був захищений вбудованою моделлю безпеки браузера. Неможливо для браузера pre-CORS створити перехресне походження JSON POST.

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

Щоб пояснити, чому в деяких запитах дозволено пропустити попередній рейс, на це відповідає специфікація:

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

Щоб розв'язати це, GET не попередньо розглядається, оскільки це "простий метод", як визначено в 7.1.5. (Заголовки також повинні бути "простими", щоб уникнути попереднього польоту). Виправданням цього є те, що, наприклад, "простий" запит GET з поперечним походженням вже може бути виконаний, наприклад <script src="">(так працює JSONP). Оскільки будь-який елемент з srcатрибутом може викликати перехресне походження GET, без попереднього польоту, не буде жодної переваги для безпеки, що вимагає попереднього бою на "простих" XHR.

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

Сценарії:

1) З передпольотом . Зловмисник підробляє запит із сайту dummy-forums.com, поки користувач має автентифікацію на safe-bank.com
Якщо Сервер не перевіряє походження та має якийсь недолік, браузер видасть запит перед польотом, ОПЦІЯ метод. Сервер не знає жодного із тих CORS, які браузер очікує як відповідь, тому браузер не буде продовжувати (не завдаючи шкоди)

2) Без попереднього польоту . Зловмисник підробляє запит за тим же сценарієм, що і вище, браузер одразу видасть запит POST або PUT, сервер приймає його та може обробити його, це може призвести до певної шкоди.

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

Механізм перед польотом додає безпеку та послідовність між клієнтами та серверами. Я не знаю, чи варто цього додаткового рукостискання для кожного запиту, оскільки кешування там важко використовувати, але це так працює.

Крім того, для методів запиту HTTP, які можуть викликати побічні ефекти щодо даних користувачів (зокрема, для методів HTTP, відмінних від GET, або для використання POST з певними типами MIME), специфікація вимагає, щоб веб-переглядачі переглядали запит.

Джерело

Запити перед польотом необхідні для запитів, які можуть змінити стан на сервері. Є 2 типи запитів -

1) Виклики, які не можуть змінити стан на сервері (наприклад, GET) - Користувач може отримати відповідь на запит (якщо сервер не перевіряє походження), але якщо запитуючий домен не додано до заголовка відповіді Access-Control- Дозволити-Походження, браузер не показує дані користувачеві, тобто запит надсилається через браузер, але користувач не може переглядати / використовувати відповідь.

2) Виклики, які можуть змінити стан на сервері (наприклад, POST, DELETE) - Оскільки в 1) ми бачимо, що браузер не блокує запит, але відповідь, дзвінки, що змінюють стан, не повинні дозволяти здійснюватися без попередніх перевірок . Такі дзвінки можуть внести зміни до довіреного сервера, який не перевіряє походження викликів (так званих підробка між веб-сайтами), навіть якщо відповідь на браузер може бути невдалою. З цієї причини у нас є концепція передпольотних запитів, які здійснюють виклик OPTIONS, перш ніж будь-які дзвінки, що змінюються станом, можуть бути відправлені на сервер.

Хіба не заздалегідь просвічені запити про продуктивність ? За допомогою попередньо відлічених запитів клієнт може швидко дізнатися, чи дозволена операція, перш ніж надсилати велику кількість даних, наприклад, в JSON методом PUT. Або перед переміщенням чутливих даних у заголовках аутентифікації по дроту.

Факт PUT, DELETE та інших методів, окрім користувацьких заголовків, заборонено за замовчуванням (їм потрібен явний дозвіл із "Методами доступу-контролю-запиту" та "Заголовок доступу-контроль-запит"), це звучить подібно до подвійної перевірки, оскільки ці операції можуть мати більше наслідків для даних користувачів, а не GET-запитів. Отже, це звучить так:

"Я бачив, що ви дозволяєте запити між веб-сайтами з http: //foo.example. Але ви впевнені, що дозволите DELETE-запити? Чи враховували ви вплив, який ці запити можуть спричинити на дані користувачів?"

Я не зрозумів цитовану кореляцію між попередньо просвіченими запитами та перевагами старих серверів. Веб-сервіс, який був реалізований до CORS або без поінформованості про CORS, ніколи не отримає БУДЬ-якого міжміського запиту, оскільки спочатку їх відповідь не матиме заголовка "Контроль доступу-дозволити-походження".

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

Тим НЕ менше, при написанні запитів (наприклад , POST) шкоди завдано , коли надходить запит на веб - сервер. * Веб - сервер може перевірити Originзаголовок , щоб визначити , якщо запит законний, але ця перевірка часто не виконуються , тому що або веб - сервер не потребує для CORS або веб-сервера старше CORS і тому припускають, що міждоменні POST повністю заборонені політикою того ж походження.

Ось чому веб-серверам надається можливість приймати запити на запит міждоменних записів .

_{* По суті AJAX версія CSRF.}