Cookies Hacking
Cookie Attributes
Cookies мають кілька атрибутів, які контролюють їх поведінку в браузері користувача. Ось огляд цих атрибутів у більш пасивному стилі:
Expires and Max-Age
Дата закінчення терміну дії cookie визначається атрибутом Expires
. У свою чергу, атрибут Max-age
визначає час у секундах до видалення cookie. Вибирайте Max-age
, оскільки це відображає більш сучасні практики.
Domain
Хости, які отримують cookie, вказуються атрибутом Domain
. За замовчуванням це встановлено на хост, який видав cookie, не включаючи його піддомени. Однак, коли атрибут Domain
явно встановлений, він охоплює також піддомени. Це робить специфікацію атрибута Domain
менш обмежувальним варіантом, корисним для сценаріїв, де необхідно ділитися cookie між піддоменами. Наприклад, встановлення Domain=mozilla.org
робить cookie доступними на його піддоменах, таких як developer.mozilla.org
.
Path
Конкретний URL-адрес, який повинен бути присутнім у запитуваному URL, щоб заголовок Cookie
був надісланий, вказується атрибутом Path
. Цей атрибут розглядає символ /
як роздільник директорій, що дозволяє відповідати також у підкаталогах.
Ordering Rules
Коли два cookie мають однакову назву, вибір того, який буде надіслано, базується на:
Cookie, що відповідає найдовшому шляху в запитуваному URL.
Найновішому встановленому cookie, якщо шляхи ідентичні.
SameSite
Атрибут
SameSite
визначає, чи надсилаються cookie на запити, що походять з доменів третіх сторін. Він пропонує три налаштування:Strict: Обмежує надсилання cookie на запити з третіх сторін.
Lax: Дозволяє надсилати cookie з GET-запитами, ініційованими веб-сайтами третіх сторін.
None: Дозволяє надсилати cookie з будь-якого домену третьої сторони.
Пам'ятайте, що під час налаштування cookie розуміння цих атрибутів може допомогти забезпечити їх очікувану поведінку в різних сценаріях.
Request Type | Example Code | Cookies Sent When |
Link | <a href="..."></a> | NotSet*, Lax, None |
Prerender | <link rel="prerender" href=".."/> | NotSet*, Lax, None |
Form GET | <form method="GET" action="..."> | NotSet*, Lax, None |
Form POST | <form method="POST" action="..."> | NotSet*, None |
iframe | <iframe src="..."></iframe> | NotSet*, None |
AJAX | $.get("...") | NotSet*, None |
Image | <img src="..."> | NetSet*, None |
Table from Invicti and slightly modified. Cookie з атрибутом SameSite зменшить атаки CSRF, де потрібна активна сесія.
*Зверніть увагу, що з Chrome80 (лютий/2019) стандартна поведінка cookie без атрибута cookie samesite буде lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Зверніть увагу, що тимчасово, після застосування цієї зміни, cookie без політики SameSite в Chrome будуть оброблятися як None протягом перших 2 хвилин, а потім як Lax для запиту POST на верхньому рівні між сайтами.
Cookies Flags
HttpOnly
Це запобігає клієнту отримувати доступ до cookie (наприклад, через Javascript: document.cookie
)
Bypasses
Якщо сторінка надсилає cookie у відповідь на запити (наприклад, на сторінці PHPinfo), можна зловживати XSS, щоб надіслати запит на цю сторінку та вкрасти cookie з відповіді (перевірте приклад на https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).
Це можна обійти за допомогою TRACE HTTP запитів, оскільки відповідь сервера (якщо цей HTTP-метод доступний) відобразить надіслані cookie. Цю техніку називають Cross-Site Tracking.
Цю техніку уникають сучасні браузери, не дозволяючи надсилати запит TRACE з JS. Однак деякі обхідні шляхи були знайдені в специфічному програмному забезпеченні, наприклад, надсилаючи
\r\nTRACE
замістьTRACE
до IE6.0 SP2.Інший спосіб - це експлуатація вразливостей нульового дня браузерів.
Можливо перезаписати cookie HttpOnly, виконуючи атаку переповнення Cookie Jar:
Можливо використовувати Cookie Smuggling атаку для ексфільтрації цих cookie
Secure
Запит надсилатиме cookie лише в HTTP-запиті, якщо запит передається через захищений канал (зазвичай HTTPS).
Cookies Prefixes
Cookie, що починаються з __Secure-
, повинні бути встановлені разом з прапором secure
з сторінок, які захищені HTTPS.
Для cookie, що починаються з __Host-
, повинні бути виконані кілька умов:
Вони повинні бути встановлені з прапором
secure
.Вони повинні походити з сторінки, захищеної HTTPS.
Їм заборонено вказувати домен, що запобігає їх передачі на піддомени.
Шлях для цих cookie повинен бути встановлений на
/
.
Важливо зазначити, що cookie, що починаються з __Host-
, не можуть бути надіслані на супердомен або піддомен. Це обмеження допомагає ізолювати cookie додатків. Таким чином, використання префікса __Host-
для всіх cookie додатків можна вважати хорошою практикою для підвищення безпеки та ізоляції.
Overwriting cookies
Отже, одне з захистів cookie з префіксом __Host-
- це запобігання їх перезапису з піддоменів. Запобігання, наприклад, Cookie Tossing attacks. У доповіді Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) представлено, що було можливо встановити cookie з префіксом __HOST- з піддомену, обманюючи парсер, наприклад, додаючи "=" на початку або на початку і в кінці...:
Або в PHP було можливо додати інші символи на початку назви cookie, які будуть замінені на символи підкреслення, що дозволяє перезаписати cookie __HOST-
:
Cookies Attacks
Якщо кастомний cookie містить чутливі дані, перевірте його (особливо якщо ви берете участь у CTF), оскільки він може бути вразливим.
Decoding and Manipulating Cookies
Чутливі дані, вбудовані в cookie, завжди повинні бути перевірені. Cookie, закодовані в Base64 або подібних форматах, часто можуть бути декодовані. Ця вразливість дозволяє зловмисникам змінювати вміст cookie та видавати себе за інших користувачів, закодовуючи їх змінені дані назад у cookie.
Session Hijacking
Ця атака полягає у викраденні cookie користувача для отримання несанкціонованого доступу до їх облікового запису в додатку. Використовуючи вкрадений cookie, зловмисник може видавати себе за законного користувача.
Session Fixation
У цьому сценарії зловмисник обманює жертву, щоб вона використовувала конкретний cookie для входу. Якщо додаток не призначає новий cookie під час входу, зловмисник, маючи оригінальний cookie, може видавати себе за жертву. Ця техніка залежить від того, що жертва входить з cookie, наданим зловмисником.
Якщо ви знайшли XSS у піддомені або контролюєте піддомен, прочитайте:
Cookie TossingSession Donation
Тут зловмисник переконує жертву використовувати cookie сесії зловмисника. Жертва, вважаючи, що вона увійшла до свого облікового запису, ненавмисно виконує дії в контексті облікового запису зловмисника.
Якщо ви знайшли XSS у піддомені або контролюєте піддомен, прочитайте:
Cookie TossingНатисніть на попереднє посилання, щоб отримати доступ до сторінки, що пояснює можливі вразливості в JWT.
JSON Web Tokens (JWT), що використовуються в cookie, також можуть мати вразливості. Для отримання детальної інформації про потенційні вразливості та способи їх експлуатації рекомендується звернутися до пов'язаного документа про злом JWT.
Cross-Site Request Forgery (CSRF)
Ця атака змушує увійшовшого користувача виконувати небажані дії на веб-додатку, в якому він наразі аутентифікований. Зловмисники можуть використовувати cookie, які автоматично надсилаються з кожним запитом до вразливого сайту.
Empty Cookies
(Перевірте додаткові деталі в оригінальному дослідженні) Браузери дозволяють створювати cookie без імені, що можна продемонструвати через JavaScript наступним чином:
Результат у заголовку cookie, що надіслано, є a=v1; test value; b=v2;
. Цікаво, що це дозволяє маніпулювати cookie, якщо встановлено cookie з порожнім ім'ям, потенційно контролюючи інші cookie, встановлюючи порожній cookie на конкретне значення:
Це призводить до того, що браузер надсилає заголовок cookie, який кожен веб-сервер інтерпретує як cookie з назвою a
та значенням b
.
Chrome Bug: Проблема з кодовими точками сурогатного Юнікоду
У Chrome, якщо кодова точка сурогату Юнікоду є частиною встановленого cookie, document.cookie
стає пошкодженим, повертаючи порожній рядок надалі:
Це призводить до того, що document.cookie
виводить порожній рядок, що вказує на постійну корупцію.
Викрадення Cookie через проблеми з парсингом
(Дивіться деталі в оригінальному дослідженні) Декілька веб-серверів, включаючи ті, що з Java (Jetty, TomCat, Undertow) та Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), неправильно обробляють рядки cookie через застарілу підтримку RFC2965. Вони читають значення cookie в подвійних лапках як одне значення, навіть якщо воно містить крапки з комою, які зазвичай повинні розділяти пари ключ-значення:
Вразливості ін'єкції куків
(Дивіться деталі в оригінальному дослідженні) Неправильний парсинг куків серверами, зокрема Undertow, Zope та тими, що використовують Python's http.cookie.SimpleCookie
і http.cookie.BaseCookie
, створює можливості для атак ін'єкції куків. Ці сервери не можуть правильно обмежити початок нових куків, що дозволяє зловмисникам підробляти куки:
Undertow очікує новий куки відразу після цитованого значення без крапки з комою.
Zope шукає кому, щоб почати парсинг наступного куки.
Класи куків Python починають парсинг з символу пробілу.
Ця вразливість особливо небезпечна в веб-додатках, що покладаються на захист CSRF на основі куків, оскільки це дозволяє зловмисникам ін'єктувати підроблені куки CSRF-токенів, потенційно обходячи заходи безпеки. Проблема ускладнюється обробкою Python дублікатів імен куків, де останнє входження перекриває попередні. Це також викликає занепокоєння щодо куків __Secure-
і __Host-
в небезпечних контекстах і може призвести до обходу авторизації, коли куки передаються на сервери, що піддаються підробці.
Додаткові перевірки вразливих куків
Основні перевірки
Кук є однаковим щоразу, коли ви входите в систему.
Вийдіть з системи та спробуйте використати той самий кук.
Спробуйте увійти з 2 пристроїв (або браузерів) до одного й того ж облікового запису, використовуючи той самий кук.
Перевірте, чи містить кук якусь інформацію, і спробуйте змінити його.
Спробуйте створити кілька облікових записів з майже однаковими іменами користувачів і перевірте, чи можете ви побачити подібності.
Перевірте опцію "запам'ятати мене", якщо вона існує, щоб дізнатися, як вона працює. Якщо вона існує і може бути вразливою, завжди використовуйте кук запам'ятати мене без жодного іншого кука.
Перевірте, чи працює попередній кук навіть після зміни пароля.
Атаки на куки високого рівня
Якщо кук залишається тим самим (або майже тим самим) під час входу, це, ймовірно, означає, що кук пов'язаний з якимось полем вашого облікового запису (ймовірно, з іменем користувача). Тоді ви можете:
Спробуйте створити багато облікових записів з дуже схожими іменами користувачів і спробуйте вгадати, як працює алгоритм.
Спробуйте брутфорсити ім'я користувача. Якщо кук зберігається лише як метод аутентифікації для вашого імені користувача, тоді ви можете створити обліковий запис з ім'ям користувача "Bmin" і брутфорсити кожен окремий біт вашого кука, оскільки один з куків, які ви спробуєте, буде належати "admin".
Спробуйте Padding Oracle (ви можете розшифрувати вміст кука). Використовуйте padbuster.
Padding Oracle - приклади Padbuster
Padbuster зробить кілька спроб і запитає вас, яка умова є умовою помилки (та, що не є дійсною).
Потім він почне розшифровувати cookie (це може зайняти кілька хвилин)
Якщо атака була успішно виконана, ви можете спробувати зашифрувати рядок на ваш вибір. Наприклад, якщо ви хочете зашифрувати user=administrator
Це виконання надасть вам cookie, правильно зашифрований і закодований зі строкою user=administrator всередині.
CBC-MAC
Можливо, cookie може мати певне значення і може бути підписаний за допомогою CBC. Тоді цілісність значення є підписом, створеним за допомогою CBC з тим же значенням. Оскільки рекомендується використовувати як IV нульовий вектор, цей тип перевірки цілісності може бути вразливим.
Атака
Отримати підпис імені користувача administ = t
Отримати підпис імені користувача rator\x00\x00\x00 XOR t = t'
Встановити в 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".
Посилання
Last updated