Cookie Tossing
Опис
Якщо зловмисник може контролювати піддомен або домен компанії або знаходить 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 Bomb
Атака Cookie Tossing також може бути використана для виконання атаки Cookie Bomb:
Cookie BombЗахисти
Використовуйте префікс __Host в імені куки
__Host в імені кукиЯкщо ім'я куки має цей префікс, вона буде прийнята в директиві Set-Cookie лише якщо вона позначена як Secure, була надіслана з безпечного джерела, не містить атрибуту Domain і має атрибут Path, встановлений на /
Це запобігає піддоменам від примушення куки до основного домену, оскільки ці куки можуть розглядатися як "заблоковані за доменом"
Посилання
Last updated
