Що не дозволяє шкідливому коду підробляти заголовок "Походження" для використання CORS?

142

Як я це розумію, якщо сценарій на стороні клієнта, який працює на сторінці з foo.com, хоче запитувати дані з bar.com, у запиті він повинен вказати заголовок Origin: http://foo.com, а на панелі повинен відповісти Access-Control-Allow-Origin: http://foo.com.

Що там, щоб зупинити шкідливий код із сайту roh.com від простого підробки заголовка Origin: http://foo.comдля запиту сторінок з бару?

— Джей Ламонт
джерело

Я вважаю, що справа в тому, що оригінальний домен, з якого подається сторінка (тут, foo.com), повинен містити Access-Control-Allow-Originзаголовок, інакше браузер не дозволяє запит bar.com.

— Кріс Хейс

Читання цієї публікації справді допомогло мені зрозуміти процес перебору між браузером, початковим сервером та цільовим сервером. html5rocks.com/uk/tutorials/cors

— brendonparker

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

— Рей Ніколус

@brendonparker Так, це чудова стаття. Цей автор відповідає на багато питань CORS щодо SO, а також підтримує enable-cors.org .

— Рей Ніколус

@RayNicholus Цікаво, що я чітко відмовився. Дякуємо за посилання. Судячи з голосів за мій коментар, я не єдиний, хто страждає від цієї марення. Я сподіваюся, що ці двоє повернуться і навчаться (і знімають свої голоси!).

— Кріс Хейс

Відповіді:

149

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

Пам'ятайте: CORS - це не безпека. Не покладайтеся на CORS для захисту вашого сайту. Якщо ви подаєте захищені дані, використовуйте файли cookie або маркери OAuth або щось інше, ніж Originзаголовок, щоб захистити ці дані. Access-Control-Allow-OriginТема CORS тільки визначає , яке походження має бути дозволено робити запити поперечного походження. Не сподівайтеся на це більше.

— монсур
джерело

Це має багато сенсу. Якщо браузер не дозволяє JavaScript замінювати заголовок Origin, то проблем немає. Якщо ви виконуєте запити за межами браузера, файли cookie не збираються. Напевно, я був розгублений, тому що в усіх документах, які я читав, ніде чітко не сказано, що заголовок Origin не можна змінити. Дякую!

— Джей Ламонт

Якщо хтось хоче щось підробляти, то може це зробити. Використовуючи майже будь-яку мову сценаріїв, вони можуть створювати http-запити. У Perl та Python є бібліотеки http, що робить це досить просто. Бібліотеки зберігають та надсилають файли cookie, дозволяють додавати довільні заголовки та надавати багато інформації про налагодження. Тож заголовки CORS - це просто ускладнити зловмисний JavaScript на форумі, який ви читаєте, щоб зробити щось неприємне для вашого банківського рахунку в іншому домені, коли ви входите в обох браузерах.

— Mnebuerquo

А для уточнення, зловмисний користувач може просто породити екземпляр веб-переглядача, який був виправлений, щоб дозволити їм керувати ручним джерелом заголовка Origin, а потім ідеально представити себе звичайним користувачем, файлам cookie, AJAX та всім іншим.

— Джордан Рігер

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

— Аса

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

— Штійн де Вітт

TLDR: Ніщо не заважає шкідливому коду підробити походження. Коли це станеться, ваш сервер ніколи про це не дізнається і діятиме за запитами. Іноді ці запити дорогі. Тому не використовуйте CORS замість будь-якого типу захисту.

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

Перше, що я виявив - це те, що Originзаголовок - це заборонене ім'я заголовка HTTP, яке неможливо змінити програмно. Це означає, що ви можете змінити його приблизно за 8 секунд, використовуючи Змінити заголовки для Google Chrome .

Щоб перевірити це, я створив два домену клієнта та один домен сервера. Я включив список серверів CORS на Сервер, який дозволяв запити CORS від Клієнта 1, але не від Клієнта 2. Я перевірив обох клієнтів, і дійсно CORS запити клієнта 1 були успішними, поки клієнт 2 не вдався.

Потім я підробив Originзаголовок клієнта 2, щоб відповідати клієнту 1. Сервер отримав підроблений Originзаголовок і успішно пройшов перевірку білого списку (або не вдалося, якщо ти хлопець із напівпорожнього типу). Після цього Сервер працював добросовісно, споживаючи всі ресурси, які він був призначений для споживання (дзвінки в базу даних, відправлення дорогих електронних листів, надсилання ще більш дорогих SMS-повідомлень тощо). Коли це було зроблено, сервер із задоволенням відправив підроблений Access-Control-Allow-Originзаголовок назад до браузера.

У документації, яку я прочитав, зазначено, що Access-Control-Allow-Originотримане значення має Originточно відповідати значенню, яке надсилається в запиті. Вони збігалися, тому я здивувався, побачивши таке повідомлення в Chrome:

Неможливо завантажити XMLHttpRequest http://server.dev/test. Заголовок 'Access-Control-Allow-Origin' має значення, http://client1.dev яке не дорівнює постачаному джерелу. http://client2.dev Тому походження заборонено для доступу.

Прочитана нами документація не здається точною. Мережева вкладка Chrome чітко показує як заголовки запиту, так і відповіді як http://client1.dev, але ви бачите помилку, що Chrome якось знає справжнє походження http://client2.devта правильно відкидає відповідь. Що не має значення в даний момент, оскільки сервер вже прийняв підроблений запит і витратив мої гроші.

— Nocturno
джерело

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

— Лука Житник

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

— Stijn de Witt

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

— Штійн де Вітт

@Nocturno Так, я, можливо, був занадто грубим, вибачте з цього приводу. Ваша оригінальна точка стоїть. Політика "Однорідний походження" - це функція захисту браузера, а CORS - це механізм послабити цю безпеку шляхом додання списку деяких доменів. ОП повинен розуміти, що підробка заголовка Origin насправді не є життєздатною як «атака», оскільки це не приносить вам нічого, чого не можна мати, наприклад, завиток.

— Штійн де Вітт

@Nocturno Я думаю, що ваше вступне слово трохи вводить в оману. There's nothing stopping malicious code from spoofing the origin-> Так, javascript не може встановити Origin. Так, користувач може змінювати свій браузер / використовувати fiddler, щоб змінити походження, але це не те, проти чого захищається CORS; Веб-сайти, що контролюються зловмисниками, не можуть змінити Origin, що є важливим.

— RJFalconer

Просто скромне завершення:

Питання: Чи застосовується однакова політика щодо оригіналу (SOP) лише браузерами?
Відповідь: Так. Для всіх дзвінків, які ви здійснюєте всередині браузера, SOP безумовно застосовується браузером. Сервер може або не може перевірити походження запиту.

Питання: Якщо запит не відповідає SOP, чи блокує його браузер?
Відповідь: Ні, це поза повноваженнями браузерів. Браузери просто надсилають запити поперечного походження та чекають відповіді, щоб побачити, чи сигналізується виклик легітимним сервером через Access-Control- * заголовки. Якщо сервер не надсилає Access-Control-Allow-Originзаголовок, не повторює походження абонента або не надсилає назад *у заголовку, тоді все, що зробить браузер, - це утримуватися від надання відповіді абоненту.

Питання: Це означає, що я не можу підробляти Origin?
Відповідь: У веб-переглядачі та використанні сценаріїв ви не можете переосмислити, Originоскільки це контролюється браузером. Однак якщо ви хочете зламати себе, ви можете підробляти дзвінки, що надходять із ВАШого браузера, використовуючи розширення браузера або інші інструменти, встановлені на вашій машині. Ви також можете оформити HTTPдзвінки , використовуючи curl, Python, C#і т.д. , і змінити Originзаголовок трюк серверів.

З: Отже, якщо я можу обманути сервер, змінивши Origin, чи означає CORSце , що він не захищений?
Відповідь: CORS сама по собі мовчить про безпеку - тобто аутентифікацію та авторизацію запитів. Серверам належить перевіряти запити та автентифікувати / авторизувати їх за допомогою будь-якого механізму, з яким вони працюють, наприклад, cookie та заголовки. Сказавши це, він може трохи більше захистити нас у разі нападів на зразок XSS:

Приклад. Скажімо, ви зареєструвались на своєму веб-сайті і зловмисний сценарій намагається надіслати запит на веб-сайт вашого банку, щоб дізнатися про ваш баланс: відбита атака XSS . Веб-сайт вашого банку довіряє облікові дані, що надходять з вашого веб-сайту (тут від імені), щоб запит отримав автентифікацію і надійшла HTTPвідповідь, спрямована на зловмисний код. Якщо веб-сайт вашого банку не хвилює обмін його кінцевими точками з іншим джерелом, він не включаєAccess-Control-Allow-Originзаголовок у відповіді. Тепер, після прибуття запиту, браузер розуміє, що запит був запитом Cross Origins, але у відповіді не видно, що сервер із задоволенням поділився ресурсом (тут кінцева точка запиту балансу) з вашим веб-сайтом. Таким чином він порушує потік, отже, повернутий результат ніколи не дійде до шкідливого коду.

— Аліреза
джерело

Приємно, краще / чіткіше, ніж прийнята відповідь ІМО

— 3dGrabber