Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

Cookie Tossing

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Опис

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

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

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

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

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

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

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

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

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

Порядок куків

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

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

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

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

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

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

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

pageCookie Jar Overflow

Іншим корисним обхідом може бути кодування URL назви куки, оскільки деякі захисти перевіряють наявність 2 куки з однаковою назвою в запиті, і тоді сервер розкодує назви куки.

Куки-бомба

Атака кидання куків також може бути використана для виконання атаки Куки-бомба:

pageCookie Bomb

Захист

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

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

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

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousCookies HackingNextCookie Jar Overflow

Last updated