diff --git a/src/pentesting-web/hacking-with-cookies/README.md b/src/pentesting-web/hacking-with-cookies/README.md index a93f77e33..9a6f667b3 100644 --- a/src/pentesting-web/hacking-with-cookies/README.md +++ b/src/pentesting-web/hacking-with-cookies/README.md @@ -54,7 +54,7 @@ Cookie з атрибутом _**SameSite**_ **зменшить атаки CSRF** ### HttpOnly -Це запобігає **клієнту** доступати до cookie (через **Javascript**, наприклад: `document.cookie`) +Це запобігає **клієнту** доступ до cookie (через **Javascript**, наприклад: `document.cookie`) #### **Bypasses** @@ -85,15 +85,15 @@ Cookie, що починаються з `__Secure-`, повинні бути вс - Їм заборонено вказувати домен, що запобігає їх передачі на піддомени. - Шлях для цих cookie повинен бути встановлений на `/`. -Важливо зазначити, що cookie, що починаються з `__Host-`, не можуть бути надіслані на супердомен або піддомен. Це обмеження допомагає ізолювати cookie додатків. Таким чином, використання префікса `__Host-` для всіх cookie додатків можна вважати хорошою практикою для підвищення безпеки та ізоляції. +Важливо зазначити, що cookie, що починаються з `__Host-`, не можуть бути надіслані на супермодеми або піддомени. Це обмеження допомагає ізолювати cookie додатків. Таким чином, використання префікса `__Host-` для всіх cookie додатків можна вважати хорошою практикою для підвищення безпеки та ізоляції. ### Overwriting cookies -Отже, одне з захистів cookie з префіксом `__Host-` - запобігти їх перезапису з піддоменів. Запобігаючи, наприклад, [**Cookie Tossing attacks**](cookie-tossing.md). У доповіді [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) представлено, що було можливо встановити cookie з префіксом \_\_HOST- з піддомену, обманюючи парсер, наприклад, додаючи "=" на початку або на початку та в кінці...: +Отже, одне з захистів cookie з префіксом `__Host-` - запобігти їх перезапису з піддоменів. Запобігаючи, наприклад, [**Cookie Tossing attacks**](cookie-tossing.md). У доповіді [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) представлено, що було можливо встановити cookie з префіксом \_\_HOST- з піддомену, обманюючи парсер, наприклад, додаючи "=" на початку або на початку і в кінці...:
-Або в PHP було можливо додати **інші символи на початку** назви cookie, які будуть **замінені на символи підкреслення**, що дозволяє перезаписати cookie з префіксом `__HOST-`: +Або в PHP було можливо додати **інші символи на початку** назви cookie, які будуть **замінені на символи підкреслення**, що дозволяє перезаписати cookie `__HOST-`:
@@ -107,7 +107,7 @@ Cookie, що починаються з `__Secure-`, повинні бути вс ### Session Hijacking -Ця атака передбачає крадіжку cookie користувача для отримання несанкціонованого доступу до їх облікового запису в додатку. Використовуючи вкрадений cookie, зловмисник може видавати себе за законного користувача. +Ця атака полягає у викраденні cookie користувача для отримання несанкціонованого доступу до їх облікового запису в додатку. Використовуючи вкрадений cookie, зловмисник може видавати себе за законного користувача. ### Session Fixation @@ -137,7 +137,7 @@ JSON Web Tokens (JWT), що використовуються в cookie, тако ### Cross-Site Request Forgery (CSRF) -Ця атака змушує увійшовшого користувача виконувати небажані дії на веб-додатку, в якому вони наразі аутентифіковані. Зловмисники можуть використовувати cookie, які автоматично надсилаються з кожним запитом до вразливого сайту. +Ця атака змушує увійшовшого користувача виконувати небажані дії на веб-додатку, в якому він наразі аутентифікований. Зловмисники можуть використовувати cookie, які автоматично надсилаються з кожним запитом до вразливого сайту. ### Empty Cookies @@ -155,11 +155,11 @@ document.cookie = `${name}=${value}` setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value ``` -Це призводить до того, що браузер надсилає заголовок cookie, який кожен веб-сервер інтерпретує як cookie з назвою `a` та значенням `b`. +Це призводить до того, що браузер надсилає заголовок cookie, який кожен веб-сервер інтерпретує як cookie з ім'ям `a` та значенням `b`. -#### Chrome Bug: Проблема з кодовими точками сурогатного Юнікоду +#### Chrome Bug: Проблема з кодовими точками сурогатів Unicode -У Chrome, якщо кодова точка сурогату Юнікоду є частиною встановленого cookie, `document.cookie` стає пошкодженим, повертаючи порожній рядок наступним чином: +У Chrome, якщо кодова точка сурогата Unicode є частиною встановленого cookie, `document.cookie` стає пошкодженим, повертаючи порожній рядок наступного разу: ```js document.cookie = "\ud800=meep" ``` @@ -171,7 +171,7 @@ document.cookie = "\ud800=meep" ``` RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; ``` -#### Вразливості ін'єкції кукі +#### Уразливості ін'єкції кукі (Дивіться деталі в [оригінальному дослідженні](https://blog.ankursundara.com/cookie-bugs/)) Неправильний парсинг кукі серверами, зокрема Undertow, Zope та тими, що використовують Python's `http.cookie.SimpleCookie` і `http.cookie.BaseCookie`, створює можливості для атак ін'єкції кукі. Ці сервери не можуть правильно обмежити початок нових кукі, що дозволяє зловмисникам підробляти кукі: @@ -179,7 +179,7 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; - Zope шукає кому, щоб почати парсинг наступної кукі. - Класи кукі Python починають парсинг з символу пробілу. -Ця вразливість особливо небезпечна в веб-додатках, які покладаються на захист CSRF на основі кукі, оскільки це дозволяє зловмисникам ін'єктувати підроблені кукі CSRF-токенів, потенційно обходячи заходи безпеки. Проблема ускладнюється обробкою Python дублікатів імен кукі, де останнє виникнення перекриває попередні. Це також викликає занепокоєння щодо кукі `__Secure-` і `__Host-` в небезпечних контекстах і може призвести до обходу авторизації, коли кукі передаються на сервери, що піддаються підробці. +Ця уразливість особливо небезпечна в веб-додатках, які покладаються на захист CSRF на основі кукі, оскільки це дозволяє зловмисникам ін'єктувати підроблені кукі CSRF-токенів, потенційно обходячи заходи безпеки. Проблема ускладнюється обробкою Python дублікатів імен кукі, де останнє виникнення перекриває попередні. Це також викликає занепокоєння щодо кукі `__Secure-` і `__Host-` в небезпечних контекстах і може призвести до обходу авторизації, коли кукі передаються на сервери, що піддаються підробці. ### Кукі $version @@ -189,12 +189,12 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; #### Атака "Кукі-сендвіч" -Згідно з [**цією статтею**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), можливо використовувати техніку "кукі-сендвіч" для викрадення HttpOnly кукі. Ось вимоги та кроки: +Згідно з [**цією статтею**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), можливо використовувати техніку кукі-сендвічу для викрадення HttpOnly кукі. Ось вимоги та кроки: - Знайти місце, де очевидно безкорисна **кукі відображається у відповіді** - **Створити кукі з назвою `$Version`** зі значенням `1` (ви можете зробити це в атаці XSS з JS) з більш специфічним шляхом, щоб вона отримала початкову позицію (деякі фреймворки, такі як Python, не потребують цього кроку) - **Створити кукі, яка відображається** зі значенням, що залишає **відкриті подвійні лапки** і з конкретним шляхом, щоб вона була розташована в базі кукі після попередньої (`$Version`) -- Потім легітимна кукі буде йти наступною в порядку +- Потім легітимна кукі піде наступною в порядку - **Створити фальшиву кукі, яка закриває подвійні лапки** всередині свого значення Таким чином, кукі жертви потрапляє в пастку всередині нової кукі версії 1 і буде відображатися щоразу, коли вона відображається. @@ -241,21 +241,21 @@ Resulting cookie: name=eval('test//, comment') => allowed #### **Основні перевірки** -- **Кук** завжди **однаковий** щоразу, коли ви **увійдете**. -- Вийдіть з системи і спробуйте використати той самий кук. -- Спробуйте увійти з 2 пристроїв (або браузерів) до одного й того ж облікового запису, використовуючи той самий кук. -- Перевірте, чи містить кук будь-яку інформацію, і спробуйте змінити його. +- **cookie** є **однаковим** щоразу, коли ви **входите** в систему. +- Вийдіть з системи та спробуйте використати той самий cookie. +- Спробуйте увійти з 2 пристроїв (або браузерів) до одного й того ж облікового запису, використовуючи той самий cookie. +- Перевірте, чи містить cookie будь-яку інформацію, і спробуйте змінити її. - Спробуйте створити кілька облікових записів з майже однаковими іменами користувачів і перевірте, чи можете ви побачити подібності. -- Перевірте опцію "**запам'ятати мене**", якщо вона існує, щоб дізнатися, як вона працює. Якщо вона існує і може бути вразливою, завжди використовуйте кук з **запам'ятати мене** без жодного іншого кука. -- Перевірте, чи працює попередній кук навіть після зміни пароля. +- Перевірте опцію "**запам'ятати мене**", якщо вона існує, щоб дізнатися, як вона працює. Якщо вона існує і може бути вразливою, завжди використовуйте cookie з **запам'ятати мене** без жодного іншого cookie. +- Перевірте, чи працює попередній cookie, навіть після зміни пароля. #### **Складні атаки на куки** -Якщо кук залишається таким же (або майже таким) при вході, це, ймовірно, означає, що кук пов'язаний з якимось полем вашого облікового запису (ймовірно, з ім'ям користувача). Тоді ви можете: +Якщо cookie залишається таким же (або майже таким) під час входу, це, ймовірно, означає, що cookie пов'язаний з якимось полем вашого облікового запису (ймовірно, з ім'ям користувача). Тоді ви можете: - Спробуйте створити багато **облікових записів** з дуже **схожими** іменами користувачів і спробуйте **вгадати**, як працює алгоритм. -- Спробуйте **брутфорсити ім'я користувача**. Якщо кук зберігається лише як метод аутентифікації для вашого імені користувача, тоді ви можете створити обліковий запис з ім'ям користувача "**Bmin**" і **брутфорсити** кожен окремий **біт** вашого кука, тому що один з куків, які ви спробуєте, буде належати "**admin**". -- Спробуйте **Padding** **Oracle** (ви можете розшифрувати вміст кука). Використовуйте **padbuster**. +- Спробуйте **брутфорсити ім'я користувача**. Якщо cookie зберігається лише як метод аутентифікації для вашого імені користувача, тоді ви можете створити обліковий запис з ім'ям користувача "**Bmin**" і **брутфорсити** кожен окремий **біт** вашого cookie, оскільки один з cookie, які ви спробуєте, буде належати "**admin**". +- Спробуйте **Padding** **Oracle** (ви можете розшифрувати вміст cookie). Використовуйте **padbuster**. **Padding Oracle - Приклади Padbuster** ```bash @@ -294,11 +294,11 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB **Як виявити та атакувати:** -Створіть 2 користувачів з майже однаковими даними (ім'я користувача, пароль, електронна пошта тощо) і спробуйте виявити певний шаблон у наданому cookie. +Створіть 2 користувачів з майже однаковими даними (ім'я користувача, пароль, електронна пошта тощо) і спробуйте виявити певний шаблон у даному cookie. Створіть користувача, наприклад, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" і перевірте, чи є якийсь шаблон у cookie (оскільки ECB шифрує з одним і тим же ключем кожен блок, ті ж зашифровані байти можуть з'явитися, якщо ім'я користувача зашифровано). -Має бути шаблон (з розміром використаного блоку). Отже, знаючи, як зашифровано купу "a", ви можете створити ім'я користувача: "a"\*(розмір блоку)+"admin". Тоді ви зможете видалити зашифрований шаблон блоку "a" з cookie. І ви отримаєте cookie для імені користувача "admin". +Має бути шаблон (з розміром використаного блоку). Отже, знаючи, як зашифровано купу "a", ви можете створити ім'я користувача: "a"\*(розмір блоку)+"admin". Тоді ви могли б видалити зашифрований шаблон блоку "a" з cookie. І ви отримаєте cookie для імені користувача "admin". ## Посилання