Cookie Tossing
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Якщо зловмисник може контролювати піддомен або домен компанії або знаходить XSS у піддомені, він зможе виконати цю атаку.
Як було зазначено в розділі про Хакінг Куків, коли кука встановлюється на домен (вказуючи його), вона буде використовуватися в домені та піддоменах.
Отже, зловмисник зможе встановити для домену та піддоменів конкретну куку, зробивши щось на зразок document.cookie="session=1234; Path=/app/login; domain=.example.com"
Це може бути небезпечно, оскільки зловмисник може:
Фіксувати куку жертви на обліковий запис зловмисника, тому якщо користувач не помітить, він буде виконувати дії в обліковому записі зловмисника, і зловмисник може отримати деяку цікаву інформацію (перевірити історію пошуків користувача на платформі, жертва може вказати свою кредитну картку в обліковому записі...)
Якщо кука не змінюється після входу, зловмисник може просто фіксувати куку (session-fixation), почекати, поки жертва увійде, а потім використати цю куку, щоб увійти як жертва.
Іноді, навіть якщо куки сесії змінюються, зловмисник використовує попередню і також отримає нову.
Якщо кука встановлює деяке початкове значення (як у flask, де кука може встановити CSRF токен сесії, і це значення буде збережено після входу жертви), зловмисник може встановити це відоме значення, а потім зловживати ним (в цьому сценарії зловмисник може змусити користувача виконати CSRF запит, оскільки знає CSRF токен).
Так само, як встановлення значення, зловмисник також може отримати неавтентифіковану куку, згенеровану сервером, отримати з неї CSRF токен і використовувати його.
Коли браузер отримує дві куки з однаковим ім'ям, які частково впливають на один і той же обсяг (домен, піддомени та шлях), браузер надішле обидва значення куки, коли обидва є дійсними для запиту.
В залежності від того, хто має найбільш специфічний шлях або яка з них є найстарішою, браузер встановить значення куки спочатку і потім значення іншої, як у: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
Більшість вебсайтів використовуватимуть лише перше значення. Тому, якщо зловмисник хоче встановити куку, краще встановити її перед тим, як буде встановлена інша, або встановити її з більш специфічним шляхом.
Більше того, можливість встановити куку в більш специфічному шляху є дуже цікавою, оскільки ви зможете змусити жертву працювати зі своєю кукою, за винятком конкретного шляху, де буде надіслана шкідлива кука.
Можливий захист від цієї атаки полягав би в тому, що веб-сервер не прийматиме запити з двома куками з однаковим ім'ям, але з двома різними значеннями.
Щоб обійти сценарій, де зловмисник встановлює куку після того, як жертва вже отримала куку, зловмисник може викликати переповнення куки, а потім, як тільки легітимна кука буде видалена, встановити шкідливу.
Ще один корисний обхід може полягати в тому, щоб URL-кодувати ім'я куки, оскільки деякі захисти перевіряють наявність 2 куків з однаковим ім'ям у запиті, а потім сервер декодує імена куків.
Атака Cookie Tossing також може бути використана для виконання атаки Cookie Bomb:
__Host в імені кукиЯкщо ім'я куки має цей префікс, вона буде прийнята в директиві Set-Cookie лише якщо вона позначена як Secure, була надіслана з безпечного джерела, не містить атрибут Domain і має атрибут Path, встановлений на /
Це запобігає піддоменам від примушення куки до основного домену, оскільки ці куки можуть розглядатися як "заблоковані за доменом"
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
