Cookie Tossing

Support HackTricks

Опис

Якщо зловмисник може контролювати піддомен або домен компанії або знаходить XSS у піддомені, він зможе виконати цю атаку.

Як було зазначено в розділі про Хакінг Куків, коли кука встановлюється на домен (вказуючи його), вона буде використовуватися в домені та піддоменах.

Отже, зловмисник зможе встановити для домену та піддоменів конкретну куку, зробивши щось на кшталт document.cookie="session=1234; Path=/app/login; domain=.example.com"

Це може бути небезпечно, оскільки зловмисник може:

  • Закріпити куку жертви за обліковим записом зловмисника, тому якщо користувач не помітить, він буде виконувати дії в обліковому записі зловмисника, і зловмисник може отримати деяку цікаву інформацію (перевірити історію пошуків користувача на платформі, жертва може вказати свою кредитну картку в обліковому записі...)

  • Якщо кука не змінюється після входу, зловмисник може просто закріпити куку (session-fixation), почекати, поки жертва увійде, а потім використати цю куку, щоб увійти як жертва.

  • Іноді, навіть якщо куки сесії змінюються, зловмисник використовує попередню і також отримає нову.

  • Якщо кука встановлює деяке початкове значення (як у flask, де кука може встановити CSRF токен сесії, і це значення буде зберігатися після входу жертви), зловмисник може встановити це відоме значення і потім зловживати ним (в цьому сценарії зловмисник може змусити користувача виконати CSRF запит, оскільки знає CSRF токен).

  • Так само, як встановлення значення, зловмисник також може отримати неавтентифіковану куку, згенеровану сервером, отримати з неї CSRF токен і використовувати його.

Порядок Кук

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

В залежності від того, хто має найбільш специфічний шлях або яка з них є найстарішою, браузер встановить значення куки спочатку і потім значення іншої, як у: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;

Більшість вебсайтів використовуватимуть лише перше значення. Тому, якщо зловмисник хоче встановити куку, краще встановити її перед тим, як буде встановлена інша, або встановити її з більш специфічним шляхом.

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

Обхід Захисту

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

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

Cookie Jar Overflow

Ще один корисний обхід може полягати в тому, щоб URL-кодувати ім'я куки, оскільки деякі захисти перевіряють наявність 2 куків з однаковим ім'ям у запиті, а потім сервер декодує імена куків.

Атака Cookie Tossing також може бути використана для виконання атаки Cookie Bomb:

Cookie Bomb

Захисти

Використовуйте префікс __Host в імені куки

  • Якщо ім'я куки має цей префікс, вона буде прийнята в директиві Set-Cookie лише якщо вона позначена як Secure, була надіслана з безпечного джерела, не містить атрибуту Domain і має атрибут Path, встановлений на /

  • Це запобігає піддоменам від примушення куки до основного домену, оскільки ці куки можуть розглядатися як "заблоковані за доменом"

Посилання

Support HackTricks

Last updated