From 3074a3a626204605771eaf89633800ffbfe54099 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 4 Feb 2025 18:53:01 +0000 Subject: [PATCH] Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent --- .../domain-subdomain-takeover.md | 66 ++++++++++------ .../hacking-with-cookies/README.md | 76 +++++++++++++------ 2 files changed, 93 insertions(+), 49 deletions(-) diff --git a/src/pentesting-web/domain-subdomain-takeover.md b/src/pentesting-web/domain-subdomain-takeover.md index 0066d8fff..15bfb12d7 100644 --- a/src/pentesting-web/domain-subdomain-takeover.md +++ b/src/pentesting-web/domain-subdomain-takeover.md @@ -1,14 +1,15 @@ -# Володіння доменом/піддоменом +# Domain/Subdomain takeover {{#include ../banners/hacktricks-training.md}} -## Володіння доменом + +## Domain takeover Якщо ви виявите якийсь домен (domain.tld), який **використовується якоюсь службою в межах** але **компанія** **втратила** **власність** на нього, ви можете спробувати **зареєструвати** його (якщо це достатньо дешево) і повідомити компанію. Якщо цей домен отримує якусь **чутливу інформацію**, таку як сесійний cookie через **GET** параметр або в заголовку **Referer**, це безумовно є **вразливістю**. -### Володіння піддоменом +### Subdomain takeover -Піддомен компанії вказує на **сервіс третьої сторони з незареєстрованим ім'ям**. Якщо ви можете **створити** **обліковий запис** у цьому **сервісі третьої сторони** і **зареєструвати** **ім'я**, яке використовується, ви можете виконати захоплення піддомену. +Субдомен компанії вказує на **сервіс третьої сторони з незареєстрованим ім'ям**. Якщо ви можете **створити** **обліковий запис** у цьому **сервісі третьої сторони** і **зареєструвати** **ім'я**, яке використовується, ви можете виконати захоплення субдомену. Існує кілька інструментів з словниками для перевірки можливих захоплень: @@ -26,55 +27,72 @@ - [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator) - [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit) -### Генерація захоплення піддомену через DNS Wildcard +### Subdomain Takeover Generation via DNS Wildcard -Коли в домені використовується DNS wildcard, будь-який запитуваний піддомен цього домену, який не має іншої адреси, буде **вирішено на ту ж інформацію**. Це може бути A IP адреса, CNAME... +Коли в домені використовується DNS wildcard, будь-який запитуваний субдомен цього домену, який не має іншої адреси, буде **вирішено на ту ж інформацію**. Це може бути A IP адреса, CNAME... -Наприклад, якщо `*.testing.com` wildcard на `1.1.1.1`. Тоді `not-existent.testing.com` буде вказувати на `1.1.1.1`. +Наприклад, якщо `*.testing.com` wildcarded на `1.1.1.1`. Тоді `not-existent.testing.com` буде вказувати на `1.1.1.1`. -Однак, якщо замість вказування на IP адресу, системний адміністратор вказує його на **сервіс третьої сторони через CNAME**, наприклад, піддомен G**ithub** (`sohomdatta1.github.io`). Зловмисник може **створити свою власну сторінку третьої сторони** (в Gihub в цьому випадку) і сказати, що `something.testing.com` вказує туди. Оскільки **CNAME wildcard** дозволяє зловмиснику **генерувати довільні піддомени для домену жертви, вказуючи на його сторінки**. +Однак, якщо замість вказування на IP адресу, системний адміністратор вказує його на **сервіс третьої сторони через CNAME**, наприклад, **субдомен GitHub** (`sohomdatta1.github.io`). Зловмисник може **створити свою власну сторінку третьої сторони** (в GitHub в цьому випадку) і сказати, що `something.testing.com` вказує туди. Оскільки **CNAME wildcard** дозволяє зловмиснику **генерувати довільні субдомени для домену жертви, вказуючи на його сторінки**. -Ви можете знайти приклад цієї вразливості в звіті CTF: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api) +Ви можете знайти приклад цієї вразливості в CTF звіті: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api) -## Використання захоплення піддомену +## Exploiting a subdomain takeover -Захоплення піддомену по суті є DNS спуфінгом для конкретного домену в Інтернеті, що дозволяє зловмисникам встановлювати A записи для домену, змушуючи браузери відображати контент з сервера зловмисника. Ця **прозорість** у браузерах робить домени вразливими до фішингу. Зловмисники можуть використовувати [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) або [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) для цієї мети. Особливо вразливими є домени, де URL у фішинговому електронному листі виглядає легітимно, обманюючи користувачів і ухиляючись від спам-фільтрів через вроджену довіру до домену. +Захоплення субдомену по суті є DNS спуфінгом для конкретного домену в Інтернеті, що дозволяє зловмисникам встановлювати A записи для домену, змушуючи браузери відображати контент з сервера зловмисника. Ця **прозорість** у браузерах робить домени вразливими до фішингу. Зловмисники можуть використовувати [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) або [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) для цієї мети. Особливо вразливими є домени, де URL у фішинговому електронному листі виглядає легітимно, обманюючи користувачів і ухиляючись від спам-фільтрів через вроджену довіру до домену. -Перевірте цей [пост для додаткових деталей](https://0xpatrik.com/subdomain-takeover/) +Перевірте цей [пост для подальших деталей](https://0xpatrik.com/subdomain-takeover/) -### **SSL Сертифікати** +### **SSL Certificates** SSL сертифікати, якщо їх генерують зловмисники через сервіси, такі як [_Let's Encrypt_](https://letsencrypt.org/), додають легітимності цим фальшивим доменам, роблячи фішингові атаки більш переконливими. -### **Безпека Cookie та Прозорість Браузера** +### **Cookie Security and Browser Transparency** -Прозорість браузера також поширюється на безпеку cookie, якою керують політики, такі як [Політика однакового походження](https://en.wikipedia.org/wiki/Same-origin_policy). Cookie, які часто використовуються для управління сесіями та зберігання токенів входу, можуть бути використані через захоплення піддомену. Зловмисники можуть **збирати сесійні cookie**, просто перенаправляючи користувачів на скомпрометований піддомен, ставлячи під загрозу дані та конфіденційність користувачів. +Прозорість браузера також поширюється на безпеку cookie, що регулюється політиками, такими як [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Cookie, які часто використовуються для управління сесіями та зберігання токенів входу, можуть бути використані через захоплення субдомену. Зловмисники можуть **збирати сесійні cookie**, просто перенаправляючи користувачів на скомпрометований субдомен, ставлячи під загрозу дані та конфіденційність користувачів. -### **Електронні листи та захоплення піддомену** +### CORS Bypass -Ще один аспект захоплення піддомену стосується електронних послуг. Зловмисники можуть маніпулювати **MX записями**, щоб отримувати або надсилати електронні листи з легітимного піддомену, підвищуючи ефективність фішингових атак. +Можливо, що кожен субдомен має доступ до CORS ресурсів з основного домену або інших субдоменів. Це може бути використано зловмисником для **доступу до чутливої інформації**, зловживаючи CORS запитами. -### **Вищі ризики** +### CSRF - Same-Site Cookies bypass + +Можливо, що субдомену дозволено надсилати cookie на домен або інші субдомени, що було заборонено атрибутом `Same-Site` cookie. Однак, зверніть увагу, що токени анти-CSRF все ще запобігатимуть цій атаці, якщо вони правильно реалізовані. + +### OAuth tokens redirect + +Можливо, що скомпрометований субдомен дозволено використовувати в URL `redirect_uri` OAuth потоку. Це може бути використано зловмисником для **викрадення токена OAuth**. + +### CSP Bypass + +Можливо, що скомпрометований субдомен (або навіть кожен субдомен) дозволено використовувати, наприклад, `script-src` CSP. Це може бути використано зловмисником для **впровадження шкідливих скриптів** і зловживання потенційними XSS вразливостями. + +### **Emails and Subdomain Takeover** + +Ще один аспект захоплення субдомену стосується електронних послуг. Зловмисники можуть маніпулювати **MX записями**, щоб отримувати або надсилати електронні листи з легітимного субдомену, підвищуючи ефективність фішингових атак. + +### **Higher Order Risks** Подальші ризики включають **захоплення NS записів**. Якщо зловмисник отримує контроль над одним NS записом домену, він може потенційно направити частину трафіку на сервер під своїм контролем. Цей ризик посилюється, якщо зловмисник встановлює високий **TTL (Time to Live)** для DNS записів, подовжуючи тривалість атаки. -### Вразливість CNAME запису +### CNAME Record Vulnerability -Зловмисники можуть експлуатувати незайняті CNAME записи, які вказують на зовнішні сервіси, які більше не використовуються або були виведені з експлуатації. Це дозволяє їм створити сторінку під довіреним доменом, ще більше полегшуючи фішинг або розповсюдження шкідливого програмного забезпечення. +Зловмисники можуть використовувати незайняті CNAME записи, які вказують на зовнішні сервіси, які більше не використовуються або були виведені з експлуатації. Це дозволяє їм створити сторінку під довіреним доменом, що ще більше полегшує фішинг або розповсюдження шкідливого ПЗ. -### **Стратегії пом'якшення** +### **Mitigation Strategies** Стратегії пом'якшення включають: -1. **Видалення вразливих DNS записів** - Це ефективно, якщо піддомен більше не потрібен. +1. **Видалення вразливих DNS записів** - Це ефективно, якщо субдомен більше не потрібен. 2. **Придбання доменного імені** - Реєстрація ресурсу у відповідного постачальника хмарних послуг або повторна покупка простроченого домену. 3. **Регулярний моніторинг на вразливості** - Інструменти, такі як [aquatone](https://github.com/michenriksen/aquatone), можуть допомогти виявити вразливі домени. Організації також повинні переглянути свої процеси управління інфраструктурою, забезпечуючи, щоб створення DNS записів було останнім кроком у створенні ресурсу та першим кроком у знищенні ресурсу. -Для постачальників хмарних послуг перевірка власності домену є критично важливою для запобігання захопленню піддоменів. Деякі, такі як [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), визнали цю проблему та впровадили механізми перевірки доменів. +Для постачальників хмарних послуг перевірка власності домену є критично важливою для запобігання захопленням субдоменів. Деякі, такі як [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), визнали цю проблему та впровадили механізми перевірки доменів. -## Посилання +## References - [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/) - [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide) +- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/hacking-with-cookies/README.md b/src/pentesting-web/hacking-with-cookies/README.md index b0e31c2a7..19bf91877 100644 --- a/src/pentesting-web/hacking-with-cookies/README.md +++ b/src/pentesting-web/hacking-with-cookies/README.md @@ -48,19 +48,19 @@ Table from [Invicti](https://www.netsparker.com/blog/web-security/same-site-cook Cookie з атрибутом _**SameSite**_ **зменшить атаки CSRF**, де потрібна активна сесія. **\*Зверніть увагу, що з Chrome80 (лютий 2019) стандартна поведінка cookie без атрибута cookie samesite** **буде lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\ -Зверніть увагу, що тимчасово, після застосування цієї зміни, **cookie без політики SameSite** **в Chrome будуть** **оброблятися як None** протягом **перших 2 хвилин, а потім як Lax для запиту POST на верхньому рівні з крос-доменом.** +Зверніть увагу, що тимчасово, після застосування цієї зміни, **cookie без політики SameSite** **в Chrome будуть** **оброблятися як None** протягом **перших 2 хвилин, а потім як Lax для запиту POST на верхньому рівні між сайтами.** ## Cookies Flags ### HttpOnly -Це запобігає **клієнту** отримати доступ до cookie (через **Javascript**, наприклад: `document.cookie`) +Це запобігає **клієнту** доступати до cookie (через **Javascript**, наприклад: `document.cookie`) #### **Bypasses** - Якщо сторінка **надсилає cookie у відповідь** на запити (наприклад, на сторінці **PHPinfo**), можливо зловживати XSS, щоб надіслати запит на цю сторінку та **вкрасти cookie** з відповіді (перевірте приклад на [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](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. +- Цю техніку уникають **сучасні браузери, не дозволяючи надсилати запит TRACE** з JS. Однак деякі обходи були знайдені в специфічному програмному забезпеченні, наприклад, надсилаючи `\r\nTRACE` замість `TRACE` до IE6.0 SP2. - Інший спосіб - це експлуатація вразливостей нульового дня браузерів. - Можливо **перезаписати HttpOnly cookie**, виконуючи атаку переповнення Cookie Jar: @@ -68,7 +68,7 @@ Cookie з атрибутом _**SameSite**_ **зменшить атаки CSRF** cookie-jar-overflow.md {{#endref}} -- Можливо використовувати атаку [**Cookie Smuggling**](#cookie-smuggling) для ексфільтрації цих cookie. +- Можливо використовувати атаку [**Cookie Smuggling**](#cookie-smuggling) для ексфільтрації цих cookie ### Secure @@ -89,11 +89,11 @@ Cookie, що починаються з `__Secure-`, повинні бути вс ### 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,11 +107,11 @@ Cookie, що починаються з `__Secure-`, повинні бути вс ### Session Hijacking -Ця атака передбачає крадіжку cookie користувача для отримання несанкціонованого доступу до їх облікового запису в додатку. Використовуючи вкрадений cookie, зловмисник може видавати себе за законного користувача. +Ця атака передбачає крадіжку cookie користувача для отримання несанкціонованого доступу до їх облікового запису в додатку. Використовуючи вкрадену cookie, зловмисник може видавати себе за законного користувача. ### Session Fixation -У цьому сценарії зловмисник обманює жертву, щоб вона використовувала конкретний cookie для входу. Якщо додаток не призначає новий cookie під час входу, зловмисник, маючи оригінальний cookie, може видавати себе за жертву. Ця техніка залежить від того, що жертва входить з cookie, наданим зловмисником. +У цьому сценарії зловмисник обманює жертву, щоб вона використовувала конкретну cookie для входу. Якщо додаток не призначає нову cookie під час входу, зловмисник, маючи оригінальну cookie, може видавати себе за жертву. Ця техніка залежить від того, що жертва входить з cookie, наданою зловмисником. Якщо ви знайшли **XSS у піддомені** або **контролюєте піддомен**, прочитайте: @@ -131,9 +131,9 @@ cookie-tossing.md ### [JWT Cookies](../hacking-jwt-json-web-tokens.md) -Натисніть на попереднє посилання, щоб отримати доступ до сторінки, що пояснює можливі вразливості в JWT. +Натисніть на попереднє посилання, щоб отримати доступ до сторінки, що пояснює можливі недоліки в JWT. -JSON Web Tokens (JWT), що використовуються в cookie, також можуть мати вразливості. Для отримання детальної інформації про потенційні вразливості та способи їх експлуатації рекомендується звернутися до пов'язаного документа про хакінг JWT. +JSON Web Tokens (JWT), що використовуються в cookie, також можуть мати вразливості. Для отримання детальної інформації про потенційні недоліки та способи їх експлуатації рекомендується звернутися до пов'язаного документа про злом JWT. ### Cross-Site Request Forgery (CSRF) @@ -141,7 +141,7 @@ JSON Web Tokens (JWT), що використовуються в cookie, тако ### Empty Cookies -(Перевірте додаткові деталі в [оригінальному дослідженні](https://blog.ankursundara.com/cookie-bugs/)) Браузери дозволяють створення cookie без імені, що можна продемонструвати через JavaScript наступним чином: +(Перевірте додаткові деталі в [оригінальному дослідженні](https://blog.ankursundara.com/cookie-bugs/)) Браузери дозволяють створювати cookie без імені, що можна продемонструвати через JavaScript наступним чином: ```js document.cookie = "a=v1" document.cookie = "=test value;" // Setting an empty named cookie @@ -159,11 +159,11 @@ setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value #### Chrome Bug: Проблема з кодовими точками сурогатів Unicode -У Chrome, якщо кодова точка сурогата Unicode є частиною встановленого cookie, `document.cookie` стає пошкодженим, повертаючи порожній рядок наступним чином: +У Chrome, якщо кодова точка сурогата Unicode є частиною встановленого cookie, `document.cookie` стає пошкодженим, повертаючи порожній рядок надалі: ```js document.cookie = "\ud800=meep" ``` -Це призводить до того, що `document.cookie` виводить порожній рядок, що вказує на постійне пошкодження. +Це призводить до того, що `document.cookie` виводить порожній рядок, що вказує на постійну корупцію. #### Контрабанда кукі через проблеми з парсингом @@ -181,24 +181,50 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; Ця вразливість особливо небезпечна в веб-додатках, які покладаються на захист CSRF на основі кукі, оскільки це дозволяє зловмисникам ін'єктувати підроблені кукі CSRF-токенів, потенційно обходячи заходи безпеки. Проблема ускладнюється обробкою Python дублікатів імен кукі, де останнє входження перекриває попередні. Це також викликає занепокоєння щодо кукі `__Secure-` і `__Host-` в небезпечних контекстах і може призвести до обходу авторизації, коли кукі передаються на сервери, що піддаються підробці. -### Кукі $version та обходи WAF +### Кукі $version + +#### Обхід WAF Згідно з [**цією статтею**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), можливо, що можна використовувати атрибут кукі **`$Version=1`**, щоб змусити бекенд використовувати стару логіку для парсингу кукі через **RFC2109**. Більше того, інші значення, такі як **`$Domain`** і **`$Path`**, можуть бути використані для зміни поведінки бекенду з кукі. -#### Аналіз обходу значення з кодуванням цитованого рядка +#### Атака "Кукі-сендвіч" -Цей парсинг вказує на те, щоб розкодувати ескейповані значення всередині кукі, тому "\a" стає "a". Це може бути корисно для обходу WAF, оскільки: +Згідно з [**цією статтею**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), можливо використовувати техніку кукі-сендвіча для викрадення HttpOnly кукі. Ось вимоги та кроки: + +- Знайти місце, де очевидно безкорисна **кукі відображається у відповіді** +- **Створити кукі з назвою `$Version`** зі значенням `1` (ви можете зробити це в атаці XSS з JS) з більш специфічним шляхом, щоб вона отримала початкову позицію (деякі фреймворки, такі як Python, не потребують цього кроку) +- **Створити кукі, яка відображається** зі значенням, що залишає **відкриті подвійні лапки** і з конкретним шляхом, щоб вона була розташована в базі кукі після попередньої (`$Version`) +- Тоді легітимна кукі піде наступною в порядку +- **Створити фальшиву кукі, яка закриває подвійні лапки** всередині свого значення + +Таким чином, кукі жертви потрапляє в пастку всередині нової кукі версії 1 і буде відображатися щоразу, коли вона відображається. +e.g. з посту: +```javascript +document.cookie = `$Version=1;`; +document.cookie = `param1="start`; +// any cookies inside the sandwich will be placed into param1 value server-side +document.cookie = `param2=end";`; +``` +### WAF обходи + +#### Cookies $version + +Перевірте попередній розділ. + +#### Обхід аналізу значень з кодуванням quoted-string + +Цей парсинг вказує на те, щоб розкодувати екрановані значення всередині cookie, тому "\a" стає "a". Це може бути корисно для обходу WAF, оскільки: - `eval('test') => заборонено` - `"\e\v\a\l\(\'\t\e\s\t\'\)" => дозволено` -#### Обхід блокувань імен кукі +#### Обхід блокувань імен cookie -У RFC2109 вказано, що **кома може використовуватися як роздільник між значеннями кукі**. Також можливо додавати **пробіли та табуляції перед і після знака рівності**. Тому кукі, як-от `$Version=1; foo=bar, abc = qux`, не генерує кукі `"foo":"bar, admin = qux"`, а генерує кукі `foo":"bar"` і `"admin":"qux"`. Зверніть увагу, як генеруються 2 кукі і як з адміністратора видалено пробіл перед і після знака рівності. +У RFC2109 вказано, що **кома може використовуватися як роздільник між значеннями cookie**. Також можливо додавати **пробіли та табуляції перед і після знака рівності**. Тому cookie, як-от `$Version=1; foo=bar, abc = qux`, не генерує cookie `"foo":"bar, admin = qux"`, а генерує cookie `foo":"bar"` та `"admin":"qux"`. Зверніть увагу, як генеруються 2 cookie і як з admin видалено пробіл перед і після знака рівності. -#### Обхід аналізу значення з розділенням кукі +#### Обхід аналізу значень з розділенням cookie -Нарешті, різні бекдори можуть об'єднувати в рядок різні кукі, передані в різних заголовках кукі, як у: +Нарешті, різні бекдори можуть об'єднувати в рядок різні cookie, передані в різних заголовках cookie, як у: ``` GET / HTTP/1.1 Host: example.com @@ -258,9 +284,9 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB **Атака** -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** +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** @@ -273,9 +299,9 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB Створіть користувача, наприклад, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" і перевірте, чи є якийсь шаблон у cookie (оскільки ECB шифрує з одним і тим же ключем кожен блок, ті ж зашифровані байти можуть з'явитися, якщо ім'я користувача зашифровано). -Повинен бути шаблон (з розміром використаного блоку). Отже, знаючи, як зашифровано купу "a", ви можете створити ім'я користувача: "a"\*(розмір блоку)+"admin". Тоді ви зможете видалити зашифрований шаблон блоку "a" з cookie. І ви отримаєте cookie для імені користувача "admin". +Повинен бути шаблон (з розміром використаного блоку). Отже, знаючи, як зашифровано купу "a", ви можете створити ім'я користувача: "a"\*(розмір блоку)+"admin". Тоді ви зможете видалити зашифрований шаблон блоку "a" з cookie. І у вас буде cookie для імені користувача "admin". -## Посилання +## References - [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/) - [https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd)