Translated ['src/pentesting-web/hacking-with-cookies/README.md'] to uk

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- з піддомену, обманюючи парсер, наприклад, додаючи "=" на початку або на початку і в кінці...:
 
 <figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
-Або в PHP було можливо додати **інші символи на початку** назви cookie, які будуть **замінені на символи підкреслення**, що дозволяє перезаписати cookie з префіксом `__HOST-`:
+Або в PHP було можливо додати **інші символи на початку** назви cookie, які будуть **замінені на символи підкреслення**, що дозволяє перезаписати cookie `__HOST-`:
 
 <figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>
 
@@ -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
 
 #### **Основні перевірки**
 
-- **Кук** завжди **однаковий** щоразу, коли ви **увійдете**.
+- **cookie** є **однаковим** щоразу, коли ви **входите** в систему.
-- Вийдіть з системи і спробуйте використати той самий кук.
+- Вийдіть з системи та спробуйте використати той самий cookie.
-- Спробуйте увійти з 2 пристроїв (або браузерів) до одного й того ж облікового запису, використовуючи той самий кук.
+- Спробуйте увійти з 2 пристроїв (або браузерів) до одного й того ж облікового запису, використовуючи той самий cookie.
-- Перевірте, чи містить кук будь-яку інформацію, і спробуйте змінити його.
+- Перевірте, чи містить cookie будь-яку інформацію, і спробуйте змінити її.
 - Спробуйте створити кілька облікових записів з майже однаковими іменами користувачів і перевірте, чи можете ви побачити подібності.
-- Перевірте опцію "**запам'ятати мене**", якщо вона існує, щоб дізнатися, як вона працює. Якщо вона існує і може бути вразливою, завжди використовуйте кук з **запам'ятати мене** без жодного іншого кука.
+- Перевірте опцію "**запам'ятати мене**", якщо вона існує, щоб дізнатися, як вона працює. Якщо вона існує і може бути вразливою, завжди використовуйте cookie з **запам'ятати мене** без жодного іншого cookie.
-- Перевірте, чи працює попередній кук навіть після зміни пароля.
+- Перевірте, чи працює попередній cookie, навіть після зміни пароля.
 
 #### **Складні атаки на куки**
 
-Якщо кук залишається таким же (або майже таким) при вході, це, ймовірно, означає, що кук пов'язаний з якимось полем вашого облікового запису (ймовірно, з ім'ям користувача). Тоді ви можете:
+Якщо cookie залишається таким же (або майже таким) під час входу, це, ймовірно, означає, що cookie пов'язаний з якимось полем вашого облікового запису (ймовірно, з ім'ям користувача). Тоді ви можете:
 
 - Спробуйте створити багато **облікових записів** з дуже **схожими** іменами користувачів і спробуйте **вгадати**, як працює алгоритм.
-- Спробуйте **брутфорсити ім'я користувача**. Якщо кук зберігається лише як метод аутентифікації для вашого імені користувача, тоді ви можете створити обліковий запис з ім'ям користувача "**Bmin**" і **брутфорсити** кожен окремий **біт** вашого кука, тому що один з куків, які ви спробуєте, буде належати "**admin**".
+- Спробуйте **брутфорсити ім'я користувача**. Якщо cookie зберігається лише як метод аутентифікації для вашого імені користувача, тоді ви можете створити обліковий запис з ім'ям користувача "**Bmin**" і **брутфорсити** кожен окремий **біт** вашого cookie, оскільки один з cookie, які ви спробуєте, буде належати "**admin**".
-- Спробуйте **Padding** **Oracle** (ви можете розшифрувати вміст кука). Використовуйте **padbuster**.
+- Спробуйте **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".
 
 ## Посилання