Захист CSRF з заголовком CORS Origin проти маркера CSRF

103

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

Йдеться саме про те, чи захист через заголовок Origin (CORS) такий же хороший, як захист через маркер CSRF?

Приклад:

Аліса входить у систему (за допомогою файлу cookie) за допомогою свого браузера на " https://example.com ". Я припускаю, що вона використовує сучасний браузер.
Аліса відвідує " https://evil.com ", а клієнтський код зла.com виконує певний запит на " https://example.com " (класичний сценарій CSRF).

Так:

Якщо ми не перевіримо заголовок Origin (на стороні сервера) і не має маркера CSRF, у нас є отвір у безпеці CSRF.
Якщо ми перевіримо маркер CSRF, ми в безпеці (але це трохи нудно).
Якщо ми перевіримо заголовок Origin, запит від клієнтського коду зла.com повинен бути заблокований так само добре, як і при використанні маркера CSRF - за винятком випадків, коли для коду зла.com якось можливо встановити заголовок Origin.

Я знаю, що це не повинно бути можливим з XHR (див., Наприклад, Безпека для спільного використання ресурсів між походженнями ), принаймні, ні, якщо ми довіряємо, що специфікація W3C правильно впроваджена у всіх сучасних браузерах (чи можемо ми?)

А як щодо інших видів запитів - наприклад, подання форми? Завантаження тегу script / img / ...? Або будь-яким іншим способом, яким сторінка може скористатися, щоб (юридично) створити запит? А може, якийсь відомий хакер JS?

Примітка: я не говорю про це

рідні програми,
маніпульовані веб-переглядачі,
помилки сценаріїв веб-сайтів на сторінці example.com,
...

— Кріс Лерчер
джерело

Я вважаю, що багато проксі передають заголовок джерела.

— thefourtheye

А для тегів для надсилання форми та img / script слід покладатися на CSP, але не впевнені в старих браузерах.

— thefourtheye

@thefourtheye: Оскільки з'єднання ініціюється через TLS, у користувача виникає набагато гостріша проблема, ніж у CSRF, якщо проксі може перетинати його / її.

— Персеїди

@thefourtheye, чому б вони знімали Origin? Це заперечує захист CORS.

— Пол Дрейпер

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

— Червоний горох

Відповіді:

знайте, що це не повинно бути можливим з XHR (див., наприклад, Безпека для спільного використання ресурсів між походженнями), принаймні, ні, якщо ми довіряємо специфікації W3C, що вона буде правильно впроваджена у всіх сучасних браузерах (чи можемо ми?)

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

Хоча раніше були вразливості браузера, такі, як у IE 5.5 / 6.0, де зловмисникам було можливо обійти політику того самого оригіналу та виконувати атаки, зазвичай можна очікувати, що вони будуть виправлені, як тільки виявлено, і більшість браузерів автоматично оновлюються. , цей ризик в основному буде пом'якшений.

А як щодо інших видів запитів - наприклад, подання форми? Завантаження тегу script / img / ...? Або будь-яким іншим способом, яким сторінка може скористатися, щоб (юридично) створити запит? А може, якийсь відомий хакер JS?

OriginТема , як правило , відправляється тільки для запитів крос-доменних XHR. Запити на зображення не містять заголовка.

Примітка: я не говорю про це

рідні програми,

маніпульовані веб-переглядачі,

помилки сценаріїв веб-сайтів на сторінці example.com,

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

— SilverlightFox
джерело

Приклад Flash - хороший варіант - і, можливо, інші плагіни можуть мати подібну вразливість. Я можу (на жаль) захистити Алісу від CSRF, якщо вона використовує сучасний браузер тощо, це зрозуміло. Але це нерозумно, що навіть будучи користувачем, який знає безпеку, вона могла б встановити сторонні плагіни, особливо якщо вони є великими (надійними) компаніями. Хоча вони можуть писати безпечні плагіни, я не переконаний на 100%, якщо вони також думають про CSRF! Тому, якщо браузерні пісочниці не обмежують плагіни порушувати SOP (можливо вони?), Я б рекомендував дотримуватися маркера CSRF.

— Кріс Лерчер

@ChrisLercher: Так, плагіни сучасного часу виглядають дещо надійнішими. Однак у будь-який момент може вийти нова версія, яка дозволяє зловмиснику використовувати її таким чином, щоб обійти захист браузера. Найкращий спосіб поводження з ним (наприклад, маркер / заголовок) буде залежати від чутливості ваших даних та прийнятності такого ризику. Flash підкоряється SOP, але походження Flash-плагіна - це веб-сайт, з якого він завантажений (а не викликовий сайт, як JavaScript). Є crossdomain.xmlте, що може ввімкнути міждоменний зв’язок.

— SilverlightFox

Веб-вміст не може змінювати заголовок Origin. Крім того, згідно з тією ж політикою щодо оригіналу, одне джерело навіть не може надсилати власні заголовки до іншого джерела. [1]

Таким чином, перевірка заголовка Origin так само хороша для блокування атак, як і використання маркера CSRF.

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

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

— гість
джерело

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

— Енді

Для довідки, питання про те, що Firefox не надсилає заголовок "Походження", відслідковується на Bugzilla: bugzilla.mozilla.org/show_bug.cgi?id=446344 У цьому випадку ви можете відмовитися від перевірки заголовка "Referer", але, на мій досвід, деякі Користувачі Firefox блокують заголовок "Referer" через проблеми конфіденційності (хоча IMHO було б достатньо, щоб зняти шлях та запит).

— Стеффен