Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

Cookies Hacking

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

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

Група з безпеки Try Hard

Атрибути куків

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

Закінчення та Max-Age

Термін дії куки визначається атрибутом Expires. Натомість, атрибут Max-age визначає час у секундах до видалення куки. Вибирайте Max-age, оскільки він відображає більш сучасні практики.

Домен

Хости, які отримують куки, вказуються атрибутом Domain. За замовчуванням це встановлено для хоста, який видав куки, не включаючи його піддомени. Однак, коли явно встановлюється атрибут Domain, він охоплює також піддомени. Це робить вказівку атрибута Domain менш обмеженою опцією, корисною для сценаріїв, де необхідно обмін куками між піддоменами. Наприклад, встановлення Domain=mozilla.org робить куки доступними на його піддоменах, таких як developer.mozilla.org.

Шлях

Конкретний URL-шлях, який повинен бути присутній у запитаному URL для відправлення заголовка Cookie, вказується атрибутом Path. Цей атрибут розглядає символ / як роздільник каталогів, що дозволяє збіги в підкаталогах також.

Правила порядку

Коли дві куки мають однакову назву, вибір для відправлення базується на:

  • Кука, яка відповідає найдовшому шляху в запитаному URL.

  • Остання встановлена кука, якщо шляхи ідентичні.

SameSite

  • Атрибут SameSite визначає, чи відправляються куки при запитах, що походять з доменів третіх сторін. Він пропонує три налаштування:

  • Strict: Обмежує відправлення куки при запитах з третіх сторін.

  • Lax: Дозволяє відправляти куки з запитами GET, ініційованими третіми сторонами.

  • None: Дозволяє відправляти куки з будь-якого домену третьої сторони.

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

Таблиця з Invicti і трохи змінена. Кука з атрибутом SameSite допоможе зменшити атаки CSRF, де потрібна увійшов сесія.

*Зверніть увагу, що починаючи з Chrome80 (лютий/2019) поведінка за замовчуванням куки без атрибута samesite буде lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Зверніть увагу, що тимчасово, після застосування цієї зміни, куки без політики SameSite в Chrome будуть оброблятися як None протягом перших 2 хвилин, а потім як Lax для запитів POST з крос-доменними верхніми рівнями.

Прапорці куків

HttpOnly

Це уникне клієнта доступу до куки (наприклад через Javascript: document.cookie)

Обхідні шляхи

  • Якщо сторінка відправляє куки як відповідь на запити (наприклад на сторінці PHPinfo), можна зловживати XSS, щоб відправити запит на цю сторінку та вкрасти куки з відповіді (перегляньте приклад на https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.

  • Це можна обійти за допомогою HTTP-запитів TRACE, оскільки відповідь від сервера (якщо цей метод HTTP доступний) відображатиме відправлені куки. Ця техніка називається Cross-Site Tracking.

  • Цю техніку уникнуто сучасними браузерами, не дозволяючи відправляти TRACE запити з JS. Однак було знайдено деякі обхідні шляхи для цього в конкретному програмному забезпеченні, наприклад, відправлення \r\nTRACE замість TRACE до IE6.0 SP2.

  • Інший спосіб - експлуатація нульових/денних вразливостей браузерів.

  • Можливо перезаписати HttpOnly куки виконавши атаку переповнення Cookie Jar:

  • Можливо використати атаку Cookie Smuggling для витягування цих куків

Secure

Запит буде лише відправляти куки в запиті HTTP лише якщо запит передається по безпечному каналу (зазвичай HTTPS).

Префікси куків

Куки з префіксом __Secure- повинні бути встановлені разом з прапорцем secure на сторінках, які захищені за допомогою HTTPS.

Для куків з префіксом __Host- повинні бути виконані кілька умов:

  • Вони повинні бути встановлені з прапорцем secure.

  • Вони повинні походити зі сторінки, захищеної HTTPS.

  • Заборонено вказувати домен, що запобігає їх передачі піддоменам.

  • Шлях для цих куків повинен бути встановлений на /.

Важливо зауважити, що куки з префіксом __Host- не можуть бути відправлені на супердомени або піддомени. Це обмеження допомагає ізолювати куки додатків. Таким чином, використання префіксу __Host- для всіх куків додатків може бути вважатися хорошою практикою для підвищення безпеки та ізоляції.

Перезапис куків

Отже, одним з захистів куків з префіксом __Host- є їхнє запобігання перезаписуванню з піддоменів. Наприклад, запобігання атакам Cookie Tossing. У виступі Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (стаття) було показано, що можна було встановлювати куки з префіксом __HOST- з піддомену, обманюючи парсер, наприклад, додаванням "=" на початку або на початку та в кінці...:

Або в PHP було можливо додавати інші символи на початку назви куки, які будуть замінені символами підкреслення, що дозволяло перезаписувати куки __HOST-:

Атаки на куки

Якщо користувацький куки містить чутливі дані, перевірте його (особливо, якщо ви граєте в CTF), оскільки він може бути вразливим.

Декодування та Маніпулювання Кукі

Чутливі дані, вбудовані в куки, завжди повинні бути ретельно перевірені. Куки, закодовані у Base64 або подібних форматах, часто можуть бути розкодовані. Ця вразливість дозволяє зловмисникам змінювати вміст куки та уособлювати інших користувачів, кодуючи їх змінені дані назад у куки.

Перехоплення Сесії

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

Фіксація Сесії

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

Якщо ви знайшли XSS на піддомені або ви керуєте піддоменом, прочитайте:

Пожертвування Сесією

Тут зловмисник переконує жертву використовувати сесійну куку зловмисника. Жертва, вважаючи, що вона увійшла у свій власний обліковий запис, ненавмисно виконує дії в контексті облікового запису зловмисника.

Якщо ви знайшли XSS на піддомені або ви керуєте піддоменом, прочитайте:

JWT Куки

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

JSON Web Tokens (JWT), використані в куках, також можуть мати уразливості. Для докладної інформації про потенційні уразливості та способи їх використання рекомендується отримати доступ до зазначеного документа про взлом JWT.

Міжсайтова Підробка Запитів (CSRF)

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

Порожні Куки

(Дивіться докладнішу інформацію в оригінальному дослідженні) Браузери дозволяють створювати куки без назви, що можна продемонструвати за допомогою JavaScript наступним чином:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Результат у відправленому заголовку cookie - a=v1; test value; b=v2;. Це дозволяє маніпулювати cookie, якщо встановлено порожнє ім'я cookie, потенційно керуючи іншими cookie, встановлюючи порожній cookie на певне значення:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

Це призводить до того, що браузер відправляє заголовок cookie, який кожен веб-сервер інтерпретує як cookie з назвою a і значенням b.

Помилка Chrome: Проблема з кодовою точкою заміщення Юнікоду

У Chrome, якщо кодова точка заміщення Юнікоду є частиною встановленого cookie, document.cookie стає пошкодженим, подальше повертаючи порожній рядок:

document.cookie = "\ud800=meep";

Це призводить до того, що document.cookie виводить порожній рядок, що свідчить про постійне пошкодження.

Крадіжка кукі через проблеми з розбором

(Дивіться докладнішу інформацію в оригінальному дослідженні) Кілька веб-серверів, включаючи ті, що на Java (Jetty, TomCat, Undertow) та Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), неправильно обробляють рядки кукі через застартування підтримки RFC2965. Вони читають подвійно-увідкрите значення куки як одне значення, навіть якщо воно містить крапки з комами, які зазвичай розділяють пари ключ-значення:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Вразливості Впровадження Кукі

(Дивіться докладнішу інформацію в оригінальному дослідженні) Неправильний розбір кукі серверами, зокрема Undertow, Zope та тими, які використовують http.cookie.SimpleCookie та http.cookie.BaseCookie у Python, створює можливості для атак впровадження кукі. Ці сервери не вміють належним чином відокремлювати початок нових кукі, що дозволяє зловмисникам підробляти куки:

  • Undertow очікує нову куку безпосередньо після закритого значення без крапки з комою.

  • Zope шукає кому для початку розбору наступної куки.

  • Класи кукі Python починають розбір з пробільного символу.

Ця вразливість особливо небезпечна в веб-додатках, які покладаються на захист від CSRF на основі кукі, оскільки вона дозволяє зловмисникам впроваджувати підроблені куки CSRF-токенів, що потенційно обхід заходів безпеки. Проблема поглиблюється обробкою Python дубльованих назв кукі, де останнє входження перевизначає попередні. Вона також викликає побоювання щодо кукі __Secure- та __Host- в ненадійних контекстах і може призвести до обхіду авторизації, коли куки передаються на сервери ззаду, які піддаються підробленню.

Додаткові Перевірки Вразливостей Кукі

Основні перевірки

  • Кука завжди однакова при кожному вході.

  • Вийдіть з системи та спробуйте використати ту саму куку.

  • Спробуйте увійти за допомогою 2 пристроїв (або браузерів) в один обліковий запис, використовуючи ту саму куку.

  • Перевірте, чи містить кука яку-небудь інформацію та спробуйте її змінити.

  • Спробуйте створити кілька облікових записів з майже однаковим ім'ям користувача та перевірте, чи бачите вони схожості.

  • Перевірте наявність опції "запам'ятати мене", якщо вона є, щоб побачити, як вона працює. Якщо вона існує та може бути вразливою, завжди використовуйте куку "запам'ятати мене" без будь-якої іншої куки.

  • Перевірте, чи попередня кука працює навіть після зміни пароля.

Розширені атаки на куки

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

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

  • Спробуйте брутфорсити ім'я користувача. Якщо кука зберігається лише як метод аутентифікації для вашого імені користувача, то ви можете створити обліковий запис з ім'ям користувача "Bmin" та брутфорсити кожен окремий біт вашої куки, оскільки одна з кук, яку ви спробуєте, буде належати "admin".

  • Спробуйте Padding Oracle (ви можете розшифрувати вміст куки). Використовуйте padbuster.

Padding Oracle - Приклади Padbuster

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

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

Потім він почне розшифровувати куки (це може зайняти кілька хвилин).

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

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Ця команда надасть вам правильно зашифроване та закодоване значення cookie з рядком user=administrator всередині.

CBC-MAC

Можливо, cookie може мати яке-небудь значення та бути підписаним за допомогою CBC. Тоді цілісність значення - це підпис, створений за допомогою CBC з тим самим значенням. Оскільки рекомендується використовувати нульовий вектор як IV, цей тип перевірки цілісності може бути вразливим.

Атака

  1. Отримати підпис імені користувача administ = t

  2. Отримати підпис імені користувача rator\x00\x00\x00 XOR t = t'

  3. Встановити в cookie значення administrator+t' (t' буде дійсним підписом (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Якщо cookie зашифровано за допомогою ECB, воно може бути вразливим. При вході в систему отримане вами cookie має бути завжди однаковим.

Як виявити та атакувати:

Створіть 2 користувачів з майже однаковими даними (ім'я користувача, пароль, електронна пошта тощо) та спробуйте виявити якийсь шаблон всередині наданого cookie

Створіть користувача з іменем, наприклад, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" та перевірте, чи є якийсь шаблон в cookie (оскільки ECB шифрує з одним і тим же ключем кожний блок, однакові зашифровані байти можуть з'явитися, якщо ім'я користувача зашифровано).

Має бути шаблон (з розміром використаного блоку). Таким чином, знаючи, як зашифровано кілька "a", ви можете створити ім'я користувача: "a"*(розмір блоку)+"admin". Потім ви можете видалити зашифрований шаблон блоку "a" з cookie. І ви матимете cookie із ім'ям користувача "admin".

Посилання

Try Hard Security Group

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

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

PreviousCSP bypass: self + 'unsafe-inline' with IframesNextCookie Tossing

Last updated