Translated ['src/generic-methodologies-and-resources/external-recon-meth

2025-10-10 18:36:50 +00:00 · 2025-03-29 22:58:33 +00:00 · 2025-03-29 22:58:33 +00:00 · f07db1dbaa
commit f07db1dbaa
parent 4089b9bfba
3 changed files with 67 additions and 35 deletions
--- a/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md
+++ b/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md
@ -3,17 +3,13 @@
 {{#include ../../banners/hacktricks-training.md}}


-
-Тепер, коли ми склали список активів нашого обсягу, час шукати деякі OSINT легкодоступні ресурси.
-
-### Платформи, які вже шукали витоки
-
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
-
-### Витоки API ключів у github
+### Інструменти для знаходження секретів у git репозиторіях та файловій системі

 - [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
 - [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
+- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
+- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
+- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
 - [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
 - [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
 - [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
--- a/src/pentesting-web/oauth-to-account-takeover.md
+++ b/src/pentesting-web/oauth-to-account-takeover.md
@ -6,12 +6,12 @@

 OAuth пропонує різні версії, з основними відомостями, доступними в [OAuth 2.0 documentation](https://oauth.net/2/). Це обговорення в основному зосереджене на широко використовуваному [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), що надає **рамки авторизації, які дозволяють додатку отримувати доступ або виконувати дії в обліковому записі користувача в іншому додатку** (сервер авторизації).

-Розгляньте гіпотетичний веб-сайт _**https://example.com**_, призначений для **демонстрації всіх ваших публікацій у соціальних мережах**, включаючи приватні. Для досягнення цього використовується OAuth 2.0. _https://example.com_ запитає вашу згоду на **доступ до ваших публікацій у соціальних мережах**. Відповідно, на _https://socialmedia.com_ з'явиться екран згоди, що описує **дозволи, які запитуються, та розробника, який робить запит**. Після вашої авторизації _https://example.com_ отримує можливість **доступу до ваших публікацій від вашого імені**.
+Розгляньте гіпотетичний веб-сайт _**https://example.com**_, призначений для **демонстрації всіх ваших публікацій у соціальних мережах**, включаючи приватні. Для цього використовується OAuth 2.0. _https://example.com_ запитає вашу згоду на **доступ до ваших публікацій у соціальних мережах**. Відповідно, на _https://socialmedia.com_ з'явиться екран згоди, що описує **дозволи, які запитуються, та розробника, який робить запит**. Після вашої авторизації _https://example.com_ отримує можливість **доступу до ваших публікацій від вашого імені**.

 Важливо зрозуміти наступні компоненти в рамках OAuth 2.0:

 - **власник ресурсу**: Ви, як **користувач/суб'єкт**, авторизуєте доступ до вашого ресурсу, наприклад, до публікацій у вашому обліковому записі соціальних мереж.
- **сервер ресурсу**: **сервер, що управляє аутентифікованими запитами** після того, як додаток отримав `access token` від імені `власника ресурсу`, наприклад, **https://socialmedia.com**.
+- **сервер ресурсу**: **сервер, що керує аутентифікованими запитами** після того, як додаток отримав `access token` від імені `власника ресурсу`, наприклад, **https://socialmedia.com**.
 - **клієнтський додаток**: **додаток, що запитує авторизацію** у `власника ресурсу`, наприклад, **https://example.com**.
 - **сервер авторизації**: **сервер, що видає `access tokens`** клієнтському додатку після успішної аутентифікації `власника ресурсу` та отримання авторизації, наприклад, **https://socialmedia.com**.
 - **client_id**: Публічний, унікальний ідентифікатор для додатку.
@ -30,7 +30,7 @@ OAuth пропонує різні версії, з основними відом
 **Фактичний потік OAuth** відбувається наступним чином:

 1. Ви переходите на [https://example.com](https://example.com) і вибираєте кнопку “Інтегрувати з соціальними мережами”.
-2. Сайт надсилає запит на [https://socialmedia.com](https://socialmedia.com), просячи вашу авторизацію для надання доступу до публікацій додатку https://example.com. Запит структурований як:
+2. Сайт надсилає запит на [https://socialmedia.com](https://socialmedia.com), просячи вашу авторизацію для надання доступу додатку https://example.com до ваших публікацій. Запит структурований як:
 ```
 https://socialmedia.com/auth
 ?response_type=code
@ -56,9 +56,9 @@ Host: socialmedia.com

 ### Відкритий redirect_uri <a href="#cc36" id="cc36"></a>

-`redirect_uri` є критично важливим для безпеки в реалізаціях OAuth та OpenID, оскільки він вказує, куди надсилаються чутливі дані, такі як коди авторизації, після авторизації. Якщо він неправильно налаштований, це може дозволити зловмисникам перенаправляти ці запити на шкідливі сервери, що дозволяє захоплення облікових записів.
+`redirect_uri` є критично важливим для безпеки в реалізаціях OAuth та OpenID, оскільки він вказує, куди надсилаються чутливі дані, такі як коди авторизації, після авторизації. Якщо він неправильно налаштований, це може дозволити зловмисникам перенаправляти ці запити на шкідливі сервери, що дозволяє захоплення облікового запису.

-Методи експлуатації варіюються в залежності від логіки валідації авторизаційного сервера. Вони можуть коливатися від суворого співпадіння шляхів до прийняття будь-якого URL в межах вказаного домену або підкаталогу. Загальні методи експлуатації включають відкриті редиректи, обходи шляхів, використання слабких регулярних виразів та HTML-ін'єкції для крадіжки токенів.
+Методи експлуатації варіюються в залежності від логіки валідації авторизаційного сервера. Вони можуть коливатися від суворого співпадіння шляхів до прийняття будь-якого URL в межах вказаного домену або підкаталогу. Загальні методи експлуатації включають відкриті редиректи, обходи шляхів, експлуатацію слабких регулярних виразів та HTML-ін'єкцію для крадіжки токенів.

 Окрім `redirect_uri`, інші параметри OAuth та OpenID, такі як `client_uri`, `policy_uri`, `tos_uri` та `initiate_login_uri`, також підлягають атакам редиректу. Ці параметри є необов'язковими, і їх підтримка варіюється між серверами.

@ -66,28 +66,28 @@ Host: socialmedia.com

 ### XSS в реалізації редиректу <a href="#bda5" id="bda5"></a>

-Як згадано в цьому звіті про баги [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), можливо, що **URL редиректу відображається у відповіді** сервера після аутентифікації користувача, що робить його **вразливим до XSS**. Можливий корисний вантаж для тестування:
+Як згадано в цьому звіті про баги [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), можливо, що **URL редиректу відображається у відповіді** сервера після аутентифікації користувача, будучи **вразливим до XSS**. Можливий корисний вантаж для тестування:
 ```
 https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
 ```
 ### CSRF - Неправильна обробка параметра state <a href="#bda5" id="bda5"></a>

-У реалізаціях OAuth неправильне використання або пропуск параметра **`state`** може значно підвищити ризик атак **Cross-Site Request Forgery (CSRF)**. Ця вразливість виникає, коли параметр `state` або **не використовується, використовується як статичне значення, або не перевіряється належним чином**, що дозволяє зловмисникам обходити захист CSRF.
+У реалізаціях OAuth неправильне використання або пропуск параметра **`state`** може значно підвищити ризик атак **Cross-Site Request Forgery (CSRF)**. Ця вразливість виникає, коли параметр `state` або **не використовується, використовується як статичне значення, або не перевіряється належним чином чи не асоціюється з сесією користувача** під час входу, що дозволяє зловмисникам обходити захист CSRF.

-Зловмисники можуть скористатися цим, перехоплюючи процес авторизації, щоб зв'язати свій обліковий запис з обліковим записом жертви, що може призвести до потенційних **взломів облікових записів**. Це особливо критично в додатках, де OAuth використовується для **автентифікаційних цілей**.
+Зловмисники можуть скористатися цим, перехоплюючи процес авторизації, щоб зв'язати свій обліковий запис з обліковим записом жертви, що призводить до потенційних **взломів облікових записів**, змушуючи користувача увійти в майже завершений oauth потік, що належить зловмиснику. Це особливо критично в додатках, де OAuth використовується для **автентифікаційних цілей**.

 Приклади цієї вразливості в реальному світі були задокументовані в різних **CTF викликах** та **хакерських платформах**, підкреслюючи її практичні наслідки. Проблема також поширюється на інтеграції з сторонніми сервісами, такими як **Slack**, **Stripe** та **PayPal**, де зловмисники можуть перенаправляти сповіщення або платежі на свої облікові записи.

-Належна обробка та перевірка параметра **`state`** є критично важливими для захисту від CSRF та забезпечення безпеки потоку OAuth.
+Належна обробка та перевірка параметра **`state`** є критично важливими для захисту від CSRF та забезпечення безпеки OAuth потоку.

 ### Перед взломом облікового запису <a href="#ebe4" id="ebe4"></a>

-1. **Без перевірки електронної пошти при створенні облікового запису**: Зловмисники можуть заздалегідь створити обліковий запис, використовуючи електронну пошту жертви. Якщо жертва пізніше використовує сторонній сервіс для входу, додаток може ненавмисно зв'язати цей сторонній обліковий запис з попередньо створеним обліковим записом зловмисника, що призведе до несанкціонованого доступу.
-2. **Використання слабкої перевірки електронної пошти в OAuth**: Зловмисники можуть скористатися сервісами OAuth, які не перевіряють електронні адреси, зареєструвавшись у їхньому сервісі, а потім змінивши електронну пошту облікового запису на електронну пошту жертви. Цей метод також несе ризик несанкціонованого доступу до облікового запису, подібно до першого сценарію, але через інший вектор атаки.
+1. **Без перевірки електронної пошти при створенні облікового запису**: Зловмисники можуть заздалегідь створити обліковий запис, використовуючи електронну пошту жертви. Якщо жертва пізніше використовує сторонній сервіс для входу, додаток може ненавмисно зв'язати цей сторонній обліковий запис з попередньо створеним обліковим записом зловмисника, що призводить до несанкціонованого доступу.
+2. **Використання слабкої перевірки електронної пошти в OAuth**: Зловмисники можуть скористатися сервісами OAuth, які не перевіряють електронні адреси, зареєструвавшись у їхньому сервісі, а потім змінивши електронну адресу облікового запису на електронну адресу жертви. Цей метод також несе ризик несанкціонованого доступу до облікового запису, подібно до першого сценарію, але через інший вектор атаки.

 ### Розкриття секретів <a href="#e177" id="e177"></a>

-Визначення та захист секретних параметрів OAuth є критично важливими. Хоча **`client_id`** можна безпечно розкривати, розкриття **`client_secret`** несе значні ризики. Якщо `client_secret` буде скомпрометовано, зловмисники можуть скористатися ідентичністю та довірою додатка, щоб **вкрасти `access_tokens`** користувачів та приватну інформацію.
+Визначення та захист секретних параметрів OAuth є критично важливими. Хоча **`client_id`** можна безпечно розкривати, розкриття **`client_secret`** несе значні ризики. Якщо `client_secret` буде скомпрометовано, зловмисники можуть скористатися ідентичністю та довірою додатка, щоб **вкрасти `access_tokens`** та приватну інформацію.

 Загальна вразливість виникає, коли додатки помилково обробляють обмін авторизаційного `code` на `access_token` на стороні клієнта, а не на стороні сервера. Ця помилка призводить до розкриття `client_secret`, що дозволяє зловмисникам генерувати `access_tokens` під виглядом додатка. Більше того, через соціальну інженерію зловмисники можуть підвищити привілеї, додаючи додаткові області до авторизації OAuth, ще більше експлуатуючи довірений статус додатка.

@ -126,7 +126,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au

 ### AWS Cognito <a href="#bda5" id="bda5"></a>

-У цьому звіті про баг-баунті: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) ви можете побачити, що **токен**, який **AWS Cognito** повертає користувачу, може мати **достатньо прав для переписування даних користувача**. Тому, якщо ви можете **змінити електронну пошту користувача на іншу електронну пошту**, ви можете **захопити** інші облікові записи.
+У цьому звіті про баг-баунті: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) ви можете побачити, що **токен**, який **AWS Cognito** повертає користувачу, може мати **достатньо прав для перезапису даних користувача**. Тому, якщо ви можете **змінити електронну пошту користувача на іншу електронну пошту**, ви можете **захопити** інші облікові записи.
 ```bash
 # Read info of the user
 aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
@ -162,18 +162,18 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 Згідно з [**цим звітом**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), було можливим змусити жертву відкрити сторінку з **returnUrl**, що вказує на хост зловмисника. Ця інформація буде **збережена в cookie (RU)**, а на **пізнішому етапі** **підказка** запитає **користувача**, чи хоче він надати доступ до цього хосту зловмисника.

-Щоб обійти цю підказку, було можливим відкрити вкладку для ініціювання **Oauth потоку**, яка встановить це RU cookie, використовуючи **returnUrl**, закрити вкладку до того, як з'явиться підказка, і відкрити нову вкладку без цього значення. Тоді **підказка не повідомить про хост зловмисника**, але cookie буде встановлено на нього, тому **токен буде надіслано на хост зловмисника** під час редиректу.
+Щоб обійти цю підказку, було можливим відкрити вкладку для ініціювання **Oauth потоку**, яка встановить це RU cookie, закрити вкладку до того, як з'явиться підказка, і відкрити нову вкладку без цього значення. Тоді **підказка не повідомить про хост зловмисника**, але cookie буде встановлено на нього, тому **токен буде надіслано на хост зловмисника** під час редиректу.

 ### Обхід взаємодії з підказкою <a href="#bda5" id="bda5"></a>

-Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), деякі реалізації OAuth дозволяють вказати GET параметр **`prompt`** як None (**`&prompt=none`**), щоб **запобігти запитам до користувачів на підтвердження** наданого доступу в підказці в вебі, якщо вони вже увійшли на платформу.
+Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), деякі реалізації OAuth дозволяють вказати параметр **`prompt`** GET як None (**`&prompt=none`**), щоб **запобігти запитам до користувачів на підтвердження** наданого доступу в підказці на веб-сайті, якщо вони вже увійшли на платформу.

 ### response_mode

 Як [**пояснено в цьому відео**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), можливо вказати параметр **`response_mode`**, щоб вказати, де ви хочете, щоб код був наданий у фінальному URL:

 - `response_mode=query` -> Код надається всередині GET параметра: `?code=2397rf3gu93f`
- `response_mode=fragment` -> Код надається всередині фрагменту URL параметра `#code=2397rf3gu93f`
+- `response_mode=fragment` -> Код надається всередині фрагмента URL параметра `#code=2397rf3gu93f`
 - `response_mode=form_post` -> Код надається всередині POST форми з полем введення, названим `code`, і значенням
 - `response_mode=web_message` -> Код надсилається в пост-повідомленні: `window.opener.postMessage({"code": "asdasdasd...`

@ -183,7 +183,7 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 ### ATO на веб-сторінці, що перенаправляє на основі відкритого редиректу на реферер <a href="#bda5" id="bda5"></a>

-Цей [**блог**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) коментує, як було можливим зловживати **відкритим редиректом** на значення з **реферера**, щоб зловживати OAuth для ATO. Атака була:
+Цей [**блог**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) коментує, як було можливим зловживати **відкритим редиректом** на значення з **реферера**, щоб зловживати OAuth для ATO. Атака полягала в наступному:

 1. Жертва заходить на веб-сторінку зловмисника
 2. Жертва відкриває шкідливе посилання, і відкривач запускає Google OAuth потік з `response_type=id_token,code&prompt=none` як додаткові параметри, використовуючи **реферер веб-сайту зловмисника**.
@ -201,7 +201,7 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
 - **Динамічна реєстрація клієнтів** часто відображається на `/register` і приймає деталі, такі як `client_name`, `client_secret`, `redirect_uris` та URL для логотипів або JSON Web Key Sets (JWKs) через POST запити.
 - Ця функція відповідає специфікаціям, викладеним у **RFC7591** та **OpenID Connect Registration 1.0**, які включають параметри, потенційно вразливі до SSRF.
 - Процес реєстрації може ненавмисно піддавати сервери SSRF кількома способами:
- **`logo_uri`**: URL для логотипу клієнтського додатку, який може бути отриманий сервером, викликаючи SSRF або призводячи до XSS, якщо URL обробляється неправильно.
+- **`logo_uri`**: URL для логотипу клієнтського додатку, який може бути отриманий сервером, викликаючи SSRF або призводячи до XSS, якщо URL обробляється неналежно.
 - **`jwks_uri`**: URL до документа JWK клієнта, який, якщо його зловмисно створити, може змусити сервер здійснити вихідні запити до сервера, контрольованого зловмисником.
 - **`sector_identifier_uri`**: Посилається на JSON масив `redirect_uris`, які сервер може отримати, створюючи можливість SSRF.
 - **`request_uris`**: Перераховує дозволені запитувані URI для клієнта, які можуть бути використані, якщо сервер отримує ці URI на початку процесу авторизації.
@ -209,15 +209,37 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
 **Стратегія експлуатації:**

 - SSRF може бути ініційовано реєстрацією нового клієнта з зловмисними URL в параметрах, таких як `logo_uri`, `jwks_uri` або `sector_identifier_uri`.
- Хоча пряма експлуатація через `request_uris` може бути пом'якшена контролем білого списку, надання попередньо зареєстрованого, контрольованого зловмисником `request_uri` може полегшити SSRF під час фази авторизації.
+- Хоча пряма експлуатація через `request_uris` може бути пом'якшена контролем білого списку, надання попередньо зареєстрованого, контрольованого зловмисником `request_uri` може полегшити SSRF під час етапу авторизації.

 ## Умови гонки постачальників OAuth

 Якщо платформа, яку ви тестуєте, є постачальником OAuth [**прочитайте це, щоб перевірити можливі умови гонки**](race-condition.md).

+## Атака на змінні претензії
+
+У OAuth поле sub унікально ідентифікує користувача, але його формат варіюється в залежності від сервера авторизації. Щоб стандартизувати ідентифікацію користувачів, деякі клієнти використовують електронні адреси або імена користувачів. Однак це ризиковано, оскільки:
+
+- Деякі сервери авторизації не гарантують, що ці властивості (як електронна адреса) залишаються незмінними.
+- У певних реалізаціях — таких як **"Увійти через Microsoft"** — клієнт покладається на поле електронної адреси, яке **контролюється користувачем у Entra ID** і не перевіряється.
+- Зловмисник може скористатися цим, створивши свою власну організацію Azure AD (наприклад, doyensectestorg) і використовуючи її для виконання входу через Microsoft.
+- Навіть якщо Object ID (збережений у sub) є незмінним і безпечним, покладання на змінне поле електронної адреси може дозволити захоплення облікового запису (наприклад, захоплення облікового запису на кшталт victim@gmail.com).
+
+## Атака на плутанину клієнтів
+
+У **Атаці на плутанину клієнтів** додаток, що використовує OAuth Implicit Flow, не перевіряє, що фінальний токен доступу спеціально згенерований для його власного Client ID. Зловмисник створює публічний веб-сайт, який використовує OAuth Implicit Flow Google, обманюючи тисячі користувачів на вході та таким чином збираючи токени доступу, призначені для сайту зловмисника. Якщо ці користувачі також мають облікові записи на іншому вразливому веб-сайті, який не перевіряє Client ID токена, зловмисник може повторно використовувати зібрані токени, щоб видавати себе за жертв і захоплювати їхні облікові записи.
+
+## Атака на підвищення обсягу
+
+Тип **Authorization Code Grant** передбачає безпечну комунікацію між серверами для передачі даних користувача. Однак, якщо **Authorization Server** імпліцитно довіряє параметру обсягу в запиті на токен доступу (параметр, не визначений у RFC), зловмисний додаток може підвищити привілеї авторизаційного коду, запитуючи вищий обсяг. Після того, як **токен доступу** згенеровано, **ресурсний сервер** повинен його перевірити: для токенів JWT це передбачає перевірку підпису JWT та витягування даних, таких як client_id та scope, тоді як для токенів випадкових рядків сервер повинен запитати у сервера авторизації, щоб отримати деталі токена.
+
+## Викрадення схеми редиректу
+
+У мобільних реалізаціях OAuth додатки використовують **кастомні URI-схеми** для отримання редиректів з авторизаційними кодами. Однак, оскільки кілька додатків можуть зареєструвати одну й ту ж схему на пристрої, припущення, що лише легітимний клієнт контролює URI редиректу, порушується. Наприклад, на Android URI наміру, як `com.example.app://`, oauth перехоплюється на основі схеми та необов'язкових фільтрів, визначених у намірі додатку. Оскільки розв'язання намірів Android може бути широким — особливо якщо вказана лише схема — зловмисник може зареєструвати шкідливий додаток з ретельно розробленим фільтром наміру, щоб викрасти код авторизації. Це може **дозволити захоплення облікового запису** або через взаємодію користувача (коли кілька додатків можуть обробляти намір) або через техніки обходу, які експлуатують надто специфічні фільтри, як детально описано в діаграмі оцінки Ostorlab.
+
 ## Посилання

 - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
 - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
+- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)

 {{#include ../banners/hacktricks-training.md}}
--- a/src/pentesting-web/unicode-injection/README.md
+++ b/src/pentesting-web/unicode-injection/README.md
@ -4,14 +4,14 @@

 ## Introduction

-В залежності від того, як бекенд/фронтенд реагує, коли він **отримує дивні юнікодні символи**, зловмисник може **обійти захист і ввести довільні символи**, які можуть бути використані для **зловживання вразливостями ін'єкцій**, такими як XSS або SQLi.
+В залежності від того, як бекенд/фронтенд реагує, коли він **отримує дивні юнікодні символи**, зловмисник може бути в змозі **обійти захист і впровадити довільні символи**, які можуть бути використані для **зловживання вразливостями ін'єкцій**, такими як XSS або SQLi.

 ## Unicode Normalization

-Нормалізація юнікоду відбувається, коли **символи юнікоду нормалізуються до символів ASCII**.
+Нормалізація юнікоду відбувається, коли **юнікодні символи нормалізуються до ASCII символів**.

-Один з поширених сценаріїв цієї вразливості виникає, коли система **модифікує** якимось чином **вхідні дані** користувача **після їх перевірки**. Наприклад, в деяких мовах простий виклик для перетворення **входу на великі або малі літери** може нормалізувати дані, і **юнікод буде перетворено на ASCII**, генеруючи нові символи.\
-Для отримання додаткової інформації дивіться:
+Один з поширених сценаріїв цієї вразливості виникає, коли система **модифікує** якимось чином **вхідні дані** користувача **після їх перевірки**. Наприклад, в деяких мовах простий виклик для перетворення **входу на великий або малий регістр** може нормалізувати дані, і **юнікод буде перетворено на ASCII**, генеруючи нові символи.\
+Для отримання додаткової інформації перегляньте:

 {{#ref}}
 unicode-normalization.md
@ -19,15 +19,15 @@ unicode-normalization.md

 ## `\u` to `%`

-Символи юнікоду зазвичай представлені з **префіксом `\u`**. Наприклад, символ `㱋` є `\u3c4b`([перевірте тут](https://unicode-explorer.com/c/3c4B)). Якщо бекенд **перетворює** префікс **`\u` на `%`**, отриманий рядок буде `%3c4b`, що при декодуванні URL є: **`<4b`**. І, як ви можете бачити, **символ `<` ін'єковано**.\
-Ви можете використовувати цю техніку для **введення будь-якого символу**, якщо бекенд вразливий.\
+Юнікодні символи зазвичай представлені з **префіксом `\u`**. Наприклад, символ `㱋` є `\u3c4b`([перевірте тут](https://unicode-explorer.com/c/3c4B)). Якщо бекенд **перетворює** префікс **`\u` на `%`**, отриманий рядок буде `%3c4b`, що при декодуванні URL є: **`<4b`**. І, як ви можете бачити, **символ `<` ін'єковано**.\
+Ви можете використовувати цю техніку для **впровадження будь-якого символу**, якщо бекенд вразливий.\
 Перевірте [https://unicode-explorer.com/](https://unicode-explorer.com/), щоб знайти потрібні символи.

-Ця вразливість насправді виникає з вразливості, яку виявив дослідник, для більш детального пояснення дивіться [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
+Ця вразливість насправді виникає з вразливості, яку виявив дослідник, для більш детального пояснення перегляньте [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)

 ## Emoji Injection

-Бекенди поводяться дивно, коли вони **отримують емодзі**. Це сталося в [**цьому звіті**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209), де дослідник зміг досягти XSS з корисним навантаженням, таким як: `💋img src=x onerror=alert(document.domain)//💛`
+Бекенди поводяться дивно, коли вони **отримують емодзі**. Саме це сталося в [**цьому звіті**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209), де дослідник зміг досягти XSS з корисним навантаженням, таким як: `💋img src=x onerror=alert(document.domain)//💛`

 У цьому випадку помилка полягала в тому, що сервер після видалення шкідливих символів **перетворив UTF-8 рядок з Windows-1252 на UTF-8** (в основному кодування вхідних даних і перетворення кодування не збігалися). Тоді це не дає правильного <, а лише дивний юнікодний: `‹`\
 ``Отже, вони взяли цей вихід і **знову перетворили з UTF-8 на ASCII**. Це **нормалізувало** `‹` до `<`, так працював експлойт на цій системі.\
@ -47,4 +47,18 @@ echo "String: " . $str;
 - [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
 - [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)

+## Windows Best-Fit/Worst-fit
+
+Як пояснюється в **[цьому чудовому пості](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, Windows має функцію під назвою **Best-Fit**, яка **замінює юнікодні символи**, які не можуть бути відображені в ASCII-режимі, на подібні. Це може призвести до **неочікуваної поведінки**, коли бекенд **очікує конкретний символ**, але отримує інший.
+
+Можна знайти символи best-fit у **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
+
+Оскільки Windows зазвичай конвертує юнікодні рядки в ASCII-рядки на одному з останніх етапів виконання (зазвичай переходячи з API з суфіксом "W" на API з суфіксом "A", такі як `GetEnvironmentVariableA` і `GetEnvironmentVariableW`), це дозволяє зловмисникам обходити захист, надсилаючи юнікодні символи, які в кінці будуть перетворені в ASCII-символи, що виконуватимуть неочікувані дії.
+
+У блозі пропонуються методи обходу вразливостей, виправлених за допомогою **чорного списку символів**, експлуатація **перетворень шляхів** за допомогою [символів, відображених на “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) та [символів, відображених на “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) або навіть обходу захисту оболонки, такого як `escapeshellarg` у PHP або `subprocess.run` у Python, використовуючи список. Це було зроблено, наприклад, використовуючи **повноширокі подвійні лапки (U+FF02)** замість подвійних лапок, так що в кінці те, що виглядало як 1 аргумент, було перетворено на 2 аргументи.
+
+**Зверніть увагу, що для того, щоб додаток був вразливим, він повинен використовувати "W" Windows API, але в кінці викликати "A" Windows API, щоб було створено "Best-fit" юнікодного рядка.**
+
+**Кілька виявлених вразливостей не будуть виправлені, оскільки люди не погоджуються, хто має виправити цю проблему.**
+
 {{#include ../../banners/hacktricks-training.md}}