Чи потрібні форми для входу в систему для атак CSRF?

161

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

Наприклад, якщо на веб-сайті була форма, яка вводила елементи у вашу кошик для покупок, а зловмисник може спамувати вашу кошик з предметами, які ви не хочете.

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

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

Однак додають жетони будь-яку безпеку до форми для входу користувача, яка вимагає імені користувача та пароля?

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

Чи правильно я розумію атаки та лексеми CSRF? І чи є вони марними для форм входу користувачів, як я підозрюю?

php token csrf

— php_learner
джерело

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

— AbiusX

Так, тому інші веб-сайти не можуть імітувати вашу форму входу. Чого вони можуть досягти, роблячи це? По-перше, ти не хочеш цього дозволити. По-друге: дуже легкі випадки відмов, як блокування користувача через неправильний пароль n ні. разів, можна уникнути.

— mayankcpdixit

126

Так. Взагалі вам потрібно захистити форми для входу від атак CSRF так само, як і будь-які інші.

В іншому випадку ваш сайт вразливий до нападу "довіреного фішингу домену". Коротше кажучи, сторінка для входу, вразлива до CSRF, дозволяє зловмиснику ділитися обліковим записом користувача з жертвою.

Уразливість виглядає так:

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

В якості доречного прикладу розглянемо YouTube . YouTube дозволив користувачам бачити запис про "власну" історію перегляду, а їх форма для входу була вразливою для CSRF! Таким чином , в результаті, зловмисник може створити обліковий запис з паролем , вони знали, дерев'яний жертву в YouTube , використовуючи цей рахунок - настирливий які відео жертви дивитися.

У цій темі коментарів є деяка дискусія, яка передбачає, що вона може бути використана лише для порушень конфіденційності. Можливо, але, щоб процитувати розділ у статті Відомості про CSRF у Вікіпедії :

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

Акцент на «романних атаках». Уявіть собі вплив фішинг-атаки на ваших користувачів, а потім уявіть, що фішинг-атака працює через власну довірну закладку користувача на ваш сайт! У роботі, зв'язаній у вищезгаданій темі коментарів, наведено кілька прикладів, які виходять за рамки простих атак на конфіденційність.

— natevw
джерело

6

Як допомагає захист CSRF? Чи є щось, що заважає зловмиснику запитати власний маркер CSRF і просто подавати його? Оскільки аутентифікованого сеансу не існує, веб-серверу немає жодної причини віддавати перевагу одному маркеру над іншим.

— А. Вілсон

2

"Чи щось перешкоджає зловмиснику запитувати власний маркер CSRF і просто подавати його?" - Так! Це все припущення, що лежить у логіці запобігання ССРР. Браузери дозволяли / не дозволяли надсилати форму націлювання на інше походження, але вони ніколи [навмисно] не дозволяли JS читати дані на сайтах, за винятком випадків, коли вибираєте CORS. Якщо ви неправильно встановили CORS, зловмисник може запустити подання форми (яка може включати наявний маркер CSRF у файлах cookie ), але не має можливості знати маркер для надсилання необхідної другої копії (наприклад, у тілі / заголовках). Отже код CSRF буде відхилено.

— natevw

7

Я думаю, що ваш останній коментар невірний (ви неправильно зрозуміли, що говорив А. Вілсон). Ми говоримо, що зловмисник може завантажити http://good.com/login.htmlодного клієнта, проаналізувати вкладений маркер CSRF, а потім опублікувати, http://bad.com/login.htmlщо містить модифіковану форму, яка подає його ім'я користувача, пароль та маркер незалежно від того, які типи жертви містять . CORS не застосовується, оскільки ви ' У мене було два окремих клієнта: нападник і жертва. Отже, щоб ще раз повторити питання: чи дійсно захист CSRF працює для форм входу?

— Гілі

8

Так, CSRF захистить форму для входу від підробки запиту на веб-сайті . Правильний маркер CSRF є криптографічно унікальним кожного разу, коли він генерується. Зрозуміло, зловмисник може отримати маркер самостійно, але він все одно НЕ ПІДПРИЄМИ [потенційно відключений] файл cookie у жертви у своєму браузері, і зловмисник не може встановити вказане cookie, не порушуючи сторінку на хорошому домені. (Ваш приклад здається трохи заплутаним між CSRF та якоюсь дивною фішинг-атакою, тому я не впевнений, чи відповідаю на ваше фактичне запитання…)

— natevw

3

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

— you786

14

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

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

— Джон
джерело

2

Вау Супер швидка відповідь! Дуже дякую! Тепер я можу продовжувати впевнено будувати свій веб-сайт.

— php_learner

21

CSRF для входу все ще можна використовувати для атак на конфіденційність користувача seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@squiddle: Це дуже цікавий документ, дякую за посилання. Але він залежить від входу користувача з обліковим записом під контролем зловмисника і передбачає, що користувач не зрозуміє щось не так, і передбачає, що користувач збирається виробляти конфіденційну інформацію, яка потім буде зберігатися на сервері. Таким чином, ІМХО є досить менш серйозним, ніж "класичний" РСР.

— Джон

6

@Jon Так, це може бути менш серйозно, але врешті-решт це може бути більше, ніж просто незручне, а саме вторгнення в конфіденційність. Кожна служба повинна сама визначити свою модель загрози та обробляти її відповідно. Для цього вам потрібно, принаймні, бути в курсі можливих загроз. Ось чому я додав свої 2 копійки.

— шквал

1

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

— samthebest

0

Так , тому інші веб-сайти не можуть імітувати вашу форму входу! Так просто.

Чого вони можуть досягти, роблячи це?

По-перше: ти не хочеш цього дозволити.
Друге: Навіть дуже прості випадки відмови, як-от:
- блокування користувача через неправильний пароль n. разів, можна уникнути.
- Сповіщення про взлом квартири можна запобігти. тощо.

— mayankcpdixit
джерело

Більшість із цих пунктів є невірними. Зловмисник може створити форму для входу, отримати облікові дані користувача, завантажувати форму для входу (з маркером csrf) та розміщувати три частини інформації до цілі. ЦСФР цьому не заважає.

— Снейп

@Snapey Браузери, як правило, не дозволяють JS читати дані CSRF. Використовуючи JS, ви не можете імітувати справжній запит на подання форми.

— mayankcpdixit

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

— Снейп

Теоретично, так, це не може запобігти. Але неможливо автоматизувати заповнення облікових даних після CSRF, якщо ви припините завантажувати форми CSRF у iframes і перестанете дозволяти перехресне походження req.

— mayankcpdixit

-1

Попередня реєстрація CSRF для перевірки не має особливого сенсу IMHO.

Завдяки @squiddle за посиланням: seclab.stanford.edu/websec/csrf/csrf.pdf , ми можемо прочитати на першій сторінці:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Якщо ви спробуєте перевірити CSRF заздалегідь увійти, то ви даєте потенційному зловмиснику можливість скребити дійсний код вашого веб-сайту! Тоді він / вона зможе повторно розмістити маркер, перемігши мету.

Можливо, зловмисник може спробувати відгадати ім’я користувача вашого сайту. Що я зробив, якщо IP-адреса намагається здогадатися сказати 10 імен користувачів без успіху, я просто в чорному списку.

— Патріс Ганьон
джерело