maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent

Browse Source
This commit is contained in:
Translator 2025-02-04 18:49:51 +00:00
parent 1cdffb6d01
commit 8c33d6f706
2 changed files with 98 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
src/pentesting-web/domain-subdomain-takeover.md
View File

@ -5,7 +5,7 @@
## Przejęcie domeny
Jeśli odkryjesz jakąś domenę (domain.tld), która **jest używana przez jakąś usługę w zakresie**, ale **firma** **straciła** **własność** nad nią, możesz spróbować ją **zarejestrować** (jeśli jest wystarczająco tania) i poinformować firmę. Jeśli ta domena otrzymuje jakieś **wrażliwe informacje**, takie jak ciasteczko sesyjne przez **GET** parametr lub w nagłówku **Referer**, to na pewno jest to **vulnerability**.
Jeśli odkryjesz jakąś domenę (domain.tld), która **jest używana przez jakąś usługę w zakresie**, ale **firma** **straciła** **własność** tej domeny, możesz spróbować ją **zarejestrować** (jeśli jest wystarczająco tania) i poinformować firmę. Jeśli ta domena otrzymuje jakieś **wrażliwe informacje**, takie jak ciasteczko sesyjne przez **GET** parametr lub w nagłówku **Referer**, to na pewno jest to **vulnerabilność**.
### Przejęcie subdomeny
@ -27,49 +27,65 @@ Istnieje kilka narzędzi z słownikami do sprawdzania możliwych przejęć:
- [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator)
- [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit)
### Generacja przejęcia subdomeny przez wildcard DNS
### Generowanie przejęcia subdomeny za pomocą wildcard DNS
Gdy w domenie używany jest wildcard DNS, każda żądana subdomena tej domeny, która nie ma innego adresu wyraźnie określonego, będzie **rozwiązywana do tych samych informacji**. Może to być adres IP A, CNAME...
Gdy w domenie używany jest wildcard DNS, każda żądana subdomena tej domeny, która nie ma innego adresu, zostanie **rozwiązana do tych samych informacji**. Może to być adres IP A, CNAME...
Na przykład, jeśli `*.testing.com` jest wildcardowane do `1.1.1.1`. Wtedy `not-existent.testing.com` będzie wskazywać na `1.1.1.1`.
Jednak jeśli zamiast wskazywać na adres IP, administrator systemu wskaże to na **usługę zewnętrzną przez CNAME**, jak na przykład subdomena G**ithuba** (`sohomdatta1.github.io`). Atakujący może **utworzyć swoją własną stronę zewnętrzną** (w Gihubie w tym przypadku) i powiedzieć, że `something.testing.com` wskazuje tam. Ponieważ **CNAME wildcard** zgodzi się, atakujący będzie mógł **generować dowolne subdomeny dla domeny ofiary wskazujące na jego strony**.
Jednak jeśli zamiast wskazywać na adres IP, administrator systemu wskaże to na **usługę zewnętrzną przez CNAME**, jak na przykład subdomena G**ithuba** (`sohomdatta1.github.io`). Atakujący może **utworzyć swoją własną stronę zewnętrzną** (w Gihub w tym przypadku) i powiedzieć, że `something.testing.com` wskazuje tam. Ponieważ **CNAME wildcard** zgodzi się, atakujący będzie mógł **generować dowolne subdomeny dla domeny ofiary wskazujące na jego strony**.
Możesz znaleźć przykład tej luki w opisie CTF: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
Możesz znaleźć przykład tej vulnerabilności w opisie CTF: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
## Wykorzystywanie przejęcia subdomeny
Przejęcie subdomeny to w zasadzie spoofing DNS dla konkretnej domeny w internecie, pozwalający atakującym ustawiać rekordy A dla domeny, co prowadzi do wyświetlania treści z serwera atakującego w przeglądarkach. Ta **przejrzystość** w przeglądarkach sprawia, że domeny są podatne na phishing. Atakujący mogą stosować [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) lub [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) w tym celu. Szczególnie podatne są domeny, w których URL w phishingowym e-mailu wydaje się być legalny, oszukując użytkowników i omijając filtry spamowe z powodu wrodzonego zaufania do domeny.
Przejęcie subdomeny to zasadniczo spoofing DNS dla konkretnej domeny w internecie, pozwalający atakującym ustawiać rekordy A dla domeny, co prowadzi do wyświetlania treści z serwera atakującego w przeglądarkach. Ta **przejrzystość** w przeglądarkach sprawia, że domeny są podatne na phishing. Atakujący mogą stosować [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) lub [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) w tym celu. Szczególnie podatne są domeny, w których URL w phishingowym e-mailu wydaje się być legalny, oszukując użytkowników i omijając filtry spamowe z powodu wrodzonego zaufania do domeny.
Sprawdź ten [post po więcej szczegółów](https://0xpatrik.com/subdomain-takeover/)
### **Certyfikaty SSL**
Certyfikaty SSL, jeśli są generowane przez atakujących za pośrednictwem usług takich jak [_Let's Encrypt_](https://letsencrypt.org/), zwiększają wiarygodność tych fałszywych domen, czyniąc ataki phishingowe bardziej przekonującymi.
Certyfikaty SSL, jeśli są generowane przez atakujących za pomocą usług takich jak [_Let's Encrypt_](https://letsencrypt.org/), zwiększają wiarygodność tych fałszywych domen, czyniąc ataki phishingowe bardziej przekonującymi.
### **Bezpieczeństwo ciasteczek i przejrzystość przeglądarki**
Przejrzystość przeglądarki dotyczy również bezpieczeństwa ciasteczek, regulowanego przez polityki takie jak [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Ciasteczka, często używane do zarządzania sesjami i przechowywania tokenów logowania, mogą być wykorzystywane przez przejęcie subdomeny. Atakujący mogą **zbierać ciasteczka sesyjne** po prostu kierując użytkowników do skompromitowanej subdomeny, zagrażając danym i prywatności użytkowników.
Przejrzystość przeglądarki dotyczy również bezpieczeństwa ciasteczek, regulowanego przez polityki takie jak [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Ciasteczka, często używane do zarządzania sesjami i przechowywania tokenów logowania, mogą być wykorzystywane przez przejęcie subdomeny. Atakujący mogą **zbierać ciasteczka sesyjne** po prostu kierując użytkowników do skompromitowanej subdomeny, narażając dane użytkowników i prywatność.
### Ominięcie CORS
Może być możliwe, że każda subdomena ma dostęp do zasobów CORS z głównej domeny lub innych subdomen. Może to być wykorzystane przez atakującego do **dostępu do wrażliwych informacji** poprzez nadużycie żądań CORS.
### CSRF - Ominięcie ciasteczek Same-Site
Może być możliwe, że subdomena ma prawo wysyłać ciasteczka do domeny lub innych subdomen, co zostało zablokowane przez atrybut `Same-Site` ciasteczek. Należy jednak zauważyć, że tokeny anty-CSRF nadal zapobiegną temu atakowi, jeśli są prawidłowo wdrożone.
### Przekierowanie tokenów OAuth
Może być możliwe, że skompromitowana subdomena może być używana w URL `redirect_uri` w przepływie OAuth. Może to być wykorzystane przez atakującego do **kradzieży tokena OAuth**.
### Ominięcie CSP
Może być możliwe, że skompromitowana subdomena (lub każda subdomena) może być używana na przykład w `script-src` CSP. Może to być wykorzystane przez atakującego do **wstrzykiwania złośliwych skryptów** i nadużywania potencjalnych luk XSS.
### **E-maile i przejęcie subdomeny**
Kolejny aspekt przejęcia subdomeny dotyczy usług e-mailowych. Atakujący mogą manipulować **rekordami MX**, aby odbierać lub wysyłać e-maile z legalnej subdomeny, zwiększając skuteczność ataków phishingowych.
Innym aspektem przejęcia subdomeny są usługi e-mailowe. Atakujący mogą manipulować **rekordami MX**, aby odbierać lub wysyłać e-maile z legalnej subdomeny, zwiększając skuteczność ataków phishingowych.
### **Wyższe ryzyko**
Dalsze ryzyka obejmują **przejęcie rekordu NS**. Jeśli atakujący zdobędzie kontrolę nad jednym rekordem NS domeny, mogą potencjalnie skierować część ruchu do serwera pod swoją kontrolą. To ryzyko jest zwiększone, jeśli atakujący ustawi wysoki **TTL (Time to Live)** dla rekordów DNS, wydłużając czas trwania ataku.
Dalsze ryzyka obejmują **przejęcie rekordu NS**. Jeśli atakujący zdobędzie kontrolę nad jednym rekordem NS domeny, mogą potencjalnie skierować część ruchu do serwera pod swoją kontrolą. To ryzyko wzrasta, jeśli atakujący ustawi wysoki **TTL (Time to Live)** dla rekordów DNS, wydłużając czas trwania ataku.
### Luka w rekordzie CNAME
### Wrażliwość rekordu CNAME
Atakujący mogą wykorzystać nieprzypisane rekordy CNAME wskazujące na zewnętrzne usługi, które nie są już używane lub zostały wycofane. Pozwala im to stworzyć stronę pod zaufaną domeną, co dodatkowo ułatwia phishing lub dystrybucję złośliwego oprogramowania.
Atakujący mogą wykorzystać nieprzypisane rekordy CNAME wskazujące na zewnętrzne usługi, które nie są już używane lub zostały wycofane. Pozwala to im na stworzenie strony pod zaufaną domeną, co dodatkowo ułatwia phishing lub dystrybucję złośliwego oprogramowania.
### **Strategie łagodzenia**
Strategie łagodzenia obejmują:
1. **Usunięcie podatnych rekordów DNS** - To jest skuteczne, jeśli subdomena nie jest już potrzebna.
1. **Usunięcie wrażliwych rekordów DNS** - To jest skuteczne, jeśli subdomena nie jest już potrzebna.
2. **Przypisanie nazwy domeny** - Zarejestrowanie zasobu u odpowiedniego dostawcy chmurowego lub ponowne zakupienie wygasłej domeny.
3. **Regularne monitorowanie luk** - Narzędzia takie jak [aquatone](https://github.com/michenriksen/aquatone) mogą pomóc w identyfikacji podatnych domen. Organizacje powinny również zrewidować swoje procesy zarządzania infrastrukturą, zapewniając, że tworzenie rekordów DNS jest ostatnim krokiem w tworzeniu zasobów i pierwszym krokiem w ich usuwaniu.
3. **Regularne monitorowanie wrażliwości** - Narzędzia takie jak [aquatone](https://github.com/michenriksen/aquatone) mogą pomóc w identyfikacji podatnych domen. Organizacje powinny również zrewidować swoje procesy zarządzania infrastrukturą, zapewniając, że tworzenie rekordów DNS jest ostatnim krokiem w tworzeniu zasobów i pierwszym krokiem w ich usuwaniu.
Dla dostawców chmurowych weryfikacja własności domeny jest kluczowa, aby zapobiec przejęciom subdomen. Niektórzy, jak [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), dostrzegli ten problem i wdrożyli mechanizmy weryfikacji domen.
@ -77,5 +93,6 @@ Dla dostawców chmurowych weryfikacja własności domeny jest kluczowa, aby zapo
- [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
- [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)
{{#include ../banners/hacktricks-training.md}}

109
src/pentesting-web/hacking-with-cookies/README.md
View File

@ -1,4 +1,4 @@
# Hacking Cookies
# Cookies Hacking
{{#include ../../banners/hacktricks-training.md}}
@ -6,15 +6,15 @@
Ciasteczka mają kilka atrybutów, które kontrolują ich zachowanie w przeglądarce użytkownika. Oto przegląd tych atrybutów w bardziej pasywnej formie:
### Expires i Max-Age
### Wygasa i Max-Age
Data wygaśnięcia ciasteczka jest określona przez atrybut `Expires`. Z kolei atrybut `Max-age` definiuje czas w sekundach, po którym ciasteczko zostanie usunięte. **Wybierz `Max-age`, ponieważ odzwierciedla to nowocześniejsze praktyki.**
### Domain
### Domeny
Hosty, które mają otrzymać ciasteczko, są określone przez atrybut `Domain`. Domyślnie jest on ustawiony na hosta, który wydał ciasteczko, nie obejmując jego subdomen. Jednak gdy atrybut `Domain` jest wyraźnie ustawiony, obejmuje również subdomeny. To sprawia, że specyfikacja atrybutu `Domain` jest mniej restrykcyjną opcją, przydatną w scenariuszach, gdzie konieczne jest udostępnianie ciasteczek między subdomenami. Na przykład ustawienie `Domain=mozilla.org` sprawia, że ciasteczka są dostępne na jego subdomenach, takich jak `developer.mozilla.org`.
Hosty, które mają otrzymać ciasteczko, są określone przez atrybut `Domain`. Domyślnie jest on ustawiony na hosta, który wydał ciasteczko, nie uwzględniając jego subdomen. Jednak gdy atrybut `Domain` jest wyraźnie ustawiony, obejmuje również subdomeny. To sprawia, że specyfikacja atrybutu `Domain` jest mniej restrykcyjną opcją, przydatną w scenariuszach, gdzie konieczne jest udostępnianie ciasteczek między subdomenami. Na przykład, ustawienie `Domain=mozilla.org` sprawia, że ciasteczka są dostępne na jego subdomenach, takich jak `developer.mozilla.org`.
### Path
### Ścieżka
Atrybut `Path` wskazuje konkretną ścieżkę URL, która musi być obecna w żądanym URL, aby nagłówek `Cookie` został wysłany. Atrybut ten traktuje znak `/` jako separator katalogów, co pozwala na dopasowania w podkatalogach.
@ -23,7 +23,7 @@ Atrybut `Path` wskazuje konkretną ścieżkę URL, która musi być obecna w ż
Gdy dwa ciasteczka mają tę samą nazwę, wybór ciasteczka do wysłania opiera się na:
- Ciasteczku pasującym do najdłuższej ścieżki w żądanym URL.
- Najnowszym ustawionym ciasteczku, jeśli ścieżki są identyczne.
- Najnowszym ciasteczku, jeśli ścieżki są identyczne.
### SameSite
@ -34,15 +34,15 @@ Gdy dwa ciasteczka mają tę samą nazwę, wybór ciasteczka do wysłania opiera
Pamiętaj, że podczas konfigurowania ciasteczek zrozumienie tych atrybutów może pomóc zapewnić, że będą one działać zgodnie z oczekiwaniami w różnych scenariuszach.
| **Typ żądania** | **Przykładowy kod** | **Ciasteczka wysyłane, gdy** |
| ---------------- | ---------------------------------- | ----------------------------- |
| Link | \<a href="...">\</a> | NotSet\*, Lax, None |
| Prerender | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None |
| Form GET | \<form method="GET" action="..."> | NotSet\*, Lax, None |
| Form POST | \<form method="POST" action="..."> | NotSet\*, None |
| iframe | \<iframe src="...">\</iframe> | NotSet\*, None |
| AJAX | $.get("...") | NotSet\*, None |
| Obraz | \<img src="..."> | NetSet\*, None |
| **Typ żądania** | **Przykładowy kod** | **Ciasteczka wysyłane, gdy** |
| ---------------- | ---------------------------------- | --------------------- |
| Link | \<a href="...">\</a> | NotSet\*, Lax, None |
| Prerender | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None |
| Form GET | \<form method="GET" action="..."> | NotSet\*, Lax, None |
| Form POST | \<form method="POST" action="..."> | NotSet\*, None |
| iframe | \<iframe src="...">\</iframe> | NotSet\*, None |
| AJAX | $.get("...") | NotSet\*, None |
| Obraz | \<img src="..."> | NetSet\*, None |
Tabela z [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) i nieco zmodyfikowana.\
Ciasteczko z atrybutem _**SameSite**_ **łagodzi ataki CSRF**, gdzie potrzebna jest zalogowana sesja.
@ -76,7 +76,7 @@ cookie-jar-overflow.md
## Prefiksy ciasteczek
Ciasteczka z prefiksem `__Secure-` muszą być ustawione wraz z flagą `secure` z stron zabezpieczonych przez HTTPS.
Ciasteczka z prefiksem `__Secure-` muszą być ustawione wraz z flagą `secure` z stron, które są zabezpieczone przez HTTPS.
Dla ciasteczek z prefiksem `__Host-` musi być spełnionych kilka warunków:
@ -103,7 +103,7 @@ Jeśli niestandardowe ciasteczko zawiera wrażliwe dane, sprawdź je (szczególn
### Dekodowanie i manipulowanie ciasteczkami
Wrażliwe dane osadzone w ciasteczkach powinny być zawsze dokładnie sprawdzane. Ciasteczka zakodowane w Base64 lub podobnych formatach można często dekodować. Ta luka pozwala atakującym na zmianę zawartości ciasteczka i podszywanie się pod innych użytkowników, kodując ich zmodyfikowane dane z powrotem do ciasteczka.
Wrażliwe dane osadzone w ciasteczkach powinny być zawsze dokładnie sprawdzane. Ciasteczka zakodowane w Base64 lub podobnych formatach można często dekodować. Ta luka pozwala atakującym na modyfikację zawartości ciasteczka i podszywanie się pod innych użytkowników, kodując ich zmodyfikowane dane z powrotem do ciasteczka.
### Przechwytywanie sesji
@ -133,7 +133,7 @@ cookie-tossing.md
Kliknij na poprzedni link, aby uzyskać dostęp do strony wyjaśniającej możliwe luki w JWT.
JSON Web Tokens (JWT) używane w ciasteczkach mogą również przedstawiać luki. Aby uzyskać szczegółowe informacje na temat potencjalnych luk i sposobów ich wykorzystania, zaleca się dostęp do powiązanego dokumentu dotyczącego hackowania JWT.
JSON Web Tokens (JWT) używane w ciasteczkach mogą również przedstawiać luki. Aby uzyskać szczegółowe informacje na temat potencjalnych luk i sposobów ich wykorzystania, zaleca się dostęp do powiązanego dokumentu dotyczącego hakowania JWT.
### Cross-Site Request Forgery (CSRF)
@ -155,7 +155,7 @@ document.cookie = `${name}=${value}`
setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
```
To prowadzi do tego, że przeglądarka wysyła nagłówek cookie interpretowany przez każdy serwer WWW jako cookie o nazwie `a` z wartością `b`.
To prowadzi do wysłania przez przeglądarkę nagłówka cookie, który jest interpretowany przez każdy serwer WWW jako cookie o nazwie `a` z wartością `b`.
#### Chrome Bug: Problem z kodem zastępczym Unicode
@ -163,49 +163,74 @@ W Chrome, jeśli kod zastępczy Unicode jest częścią ustawionego cookie, `doc
```js
document.cookie = "\ud800=meep"
```
To skutkuje tym, że `document.cookie` zwraca pusty ciąg, co wskazuje na trwałą korupcję.
To skutkuje tym, że `document.cookie` zwraca pusty ciąg, co wskazuje na trwałe uszkodzenie.
#### Smuggling ciasteczek z powodu problemów z analizą
#### Przechwytywanie ciasteczek z powodu problemów z analizą
(Zobacz dalsze szczegóły w [oryginalnych badaniach](https://blog.ankursundara.com/cookie-bugs/)) Kilka serwerów internetowych, w tym te z Javy (Jetty, TomCat, Undertow) i Pythona (Zope, cherrypy, web.py, aiohttp, bottle, webob), niewłaściwie obsługuje ciągi ciasteczek z powodu przestarzałego wsparcia dla RFC2965. Odczytują podwójnie cytowaną wartość ciasteczka jako jedną wartość, nawet jeśli zawiera średniki, które normalnie powinny oddzielać pary klucz-wartość:
(Sprawdź szczegóły w[oryginalnych badaniach](https://blog.ankursundara.com/cookie-bugs/)) Kilka serwerów internetowych, w tym te z Javy (Jetty, TomCat, Undertow) i Pythona (Zope, cherrypy, web.py, aiohttp, bottle, webob), niewłaściwie obsługuje ciągi ciasteczek z powodu przestarzałego wsparcia dla RFC2965. Odczytują wartość ciasteczka w podwójnych cudzysłowach jako jedną wartość, nawet jeśli zawiera średniki, które normalnie powinny oddzielać pary klucz-wartość:
```
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
```
#### Luki w wstrzykiwaniu ciasteczek
#### Luki w Iniekcji Ciasteczek
(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) Nieprawidłowe analizowanie ciasteczek przez serwery, szczególnie Undertow, Zope oraz te korzystające z `http.cookie.SimpleCookie` i `http.cookie.BaseCookie` w Pythonie, stwarza możliwości ataków wstrzykiwania ciasteczek. Serwery te nieprawidłowo delimitują początek nowych ciasteczek, co pozwala atakującym na fałszowanie ciasteczek:
(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) Nieprawidłowe analizowanie ciasteczek przez serwery, szczególnie Undertow, Zope oraz te korzystające z `http.cookie.SimpleCookie` i `http.cookie.BaseCookie` w Pythonie, stwarza możliwości ataków iniekcji ciasteczek. Serwery te nieprawidłowo delimitują początek nowych ciasteczek, co pozwala atakującym na fałszowanie ciasteczek:
- Undertow oczekuje nowego ciasteczka natychmiast po wartości w cudzysłowie bez średnika.
- Zope szuka przecinka, aby rozpocząć analizowanie następnego ciasteczka.
- Klasy ciasteczek Pythona zaczynają analizowanie od znaku spacji.
Ta luka jest szczególnie niebezpieczna w aplikacjach internetowych polegających na ochronie CSRF opartej na ciasteczkach, ponieważ pozwala atakującym na wstrzykiwanie fałszywych ciasteczek z tokenami CSRF, co potencjalnie omija środki bezpieczeństwa. Problem ten jest zaostrzany przez sposób, w jaki Python obsługuje duplikaty nazw ciasteczek, gdzie ostatnie wystąpienie nadpisuje wcześniejsze. Budzi to również obawy dotyczące ciasteczek `__Secure-` i `__Host-` w niebezpiecznych kontekstach i może prowadzić do obejść autoryzacji, gdy ciasteczka są przekazywane do serwerów zaplecza podatnych na fałszowanie.
Ta luka jest szczególnie niebezpieczna w aplikacjach webowych polegających na ochronie CSRF opartej na ciasteczkach, ponieważ pozwala atakującym na wstrzykiwanie fałszywych ciasteczek z tokenami CSRF, potencjalnie omijając środki bezpieczeństwa. Problem ten jest zaostrzony przez sposób, w jaki Python obsługuje duplikaty nazw ciasteczek, gdzie ostatnie wystąpienie nadpisuje wcześniejsze. Budzi to również obawy dotyczące ciasteczek `__Secure-` i `__Host-` w niebezpiecznych kontekstach i może prowadzić do obejść autoryzacji, gdy ciasteczka są przekazywane do serwerów zaplecza podatnych na fałszowanie.
### Ciasteczka $version i obejścia WAF
### Ciasteczka $version
Zgodnie z [**tym wpisem na blogu**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), możliwe jest użycie atrybutu ciasteczka **`$Version=1`**, aby backend używał starej logiki do analizy ciasteczka z powodu **RFC2109**. Ponadto inne wartości, takie jak **`$Domain`** i **`$Path`**, mogą być używane do modyfikacji zachowania backendu z ciasteczkiem.
#### Ominięcie WAF
#### Analiza obejścia wartości z kodowaniem ciągów cytowanych
Zgodnie z [**tym wpisem na blogu**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), możliwe jest użycie atrybutu ciasteczka **`$Version=1`**, aby backend używał starej logiki do analizy ciasteczka zgodnie z **RFC2109**. Ponadto, inne wartości takie jak **`$Domain`** i **`$Path`** mogą być używane do modyfikacji zachowania backendu z ciasteczkiem.
Ta analiza wskazuje na usunięcie znaków ucieczki z wartości wewnątrz ciasteczek, więc "\a" staje się "a". Może to być przydatne do obejścia WAF, ponieważ:
#### Atak Ciasteczkowy Sandwich
Zgodnie z [**tym wpisem na blogu**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), możliwe jest użycie techniki ciasteczkowego sandwichu do kradzieży ciasteczek HttpOnly. Oto wymagania i kroki:
- Znajdź miejsce, w którym pozornie bezużyteczne **ciasteczko jest odzwierciedlane w odpowiedzi**
- **Utwórz ciasteczko o nazwie `$Version`** z wartością `1` (możesz to zrobić w ataku XSS z JS) z bardziej specyficzną ścieżką, aby uzyskać początkową pozycję (niektóre frameworki, takie jak Python, nie potrzebują tego kroku)
- **Utwórz ciasteczko, które jest odzwierciedlane** z wartością, która pozostawia **otwarte podwójne cudzysłowy** i z określoną ścieżką, aby było umiejscowione w bazie ciasteczek po poprzednim (`$Version`)
- Następnie, legalne ciasteczko będzie następne w kolejności
- **Utwórz fałszywe ciasteczko, które zamyka podwójne cudzysłowy** wewnątrz swojej wartości
W ten sposób ciasteczko ofiary zostaje uwięzione wewnątrz nowego ciasteczka wersji 1 i będzie odzwierciedlane, gdy tylko zostanie odzwierciedlone.
```javascript
document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;
```
### WAF bypasses
#### Cookies $version
Sprawdź poprzednią sekcję.
#### Bypassing value analysis with quoted-string encoding
To parsowanie wskazuje na usunięcie znaków ucieczki z wartości wewnątrz ciasteczek, więc "\a" staje się "a". Może to być przydatne do obejścia WAFS, ponieważ:
- `eval('test') => forbidden`
- `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`
#### Obejście blokad nazw ciasteczek
#### Bypassing cookie-name blocklists
W RFC2109 wskazano, że **przecinek może być używany jako separator między wartościami ciasteczek**. Możliwe jest również dodanie **spacji i tabulatorów przed i po znaku równości**. Dlatego ciasteczko takie jak `$Version=1; foo=bar, abc = qux` nie generuje ciasteczka `"foo":"bar, admin = qux"`, ale ciasteczka `foo":"bar"` i `"admin":"qux"`. Zauważ, jak generowane są 2 ciasteczka i jak usunięto spację przed i po znaku równości.
W RFC2109 wskazano, że **przecinek może być użyty jako separator między wartościami ciasteczek**. Możliwe jest również dodanie **spacji i tabulatorów przed i po znaku równości**. Dlatego ciasteczko takie jak `$Version=1; foo=bar, abc = qux` nie generuje ciasteczka `"foo":"bar, admin = qux"`, ale ciasteczka `foo":"bar"` i `"admin":"qux"`. Zauważ, jak generowane są 2 ciasteczka i jak usunięto spację przed i po znaku równości.
#### Analiza obejścia wartości z dzieleniem ciasteczek
#### Bypassing value analysis with cookie splitting
Na koniec różne tylne drzwi mogą łączyć w jeden ciąg różne ciasteczka przekazywane w różnych nagłówkach ciasteczek, jak w:
Na koniec różne backdoory mogą łączyć w jeden ciąg różne ciasteczka przekazywane w różnych nagłówkach ciasteczek, jak w:
```
GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;
```
Co mogłoby pozwolić na ominięcie WAF, jak w tym przykładzie:
Co może pozwolić na ominięcie WAF, jak w tym przykładzie:
```
Cookie: name=eval('test//
Cookie: comment')
@ -220,19 +245,19 @@ Resulting cookie: name=eval('test//, comment') => allowed
- Wyloguj się i spróbuj użyć tego samego ciasteczka.
- Spróbuj zalogować się z 2 urządzeń (lub przeglądarek) do tego samego konta, używając tego samego ciasteczka.
- Sprawdź, czy ciasteczko zawiera jakiekolwiek informacje i spróbuj je zmodyfikować.
- Spróbuj utworzyć kilka kont z prawie tym samym nazwiskiem i sprawdź, czy możesz dostrzec podobieństwa.
- Spróbuj utworzyć kilka kont z prawie tym samym nazwiskiem użytkownika i sprawdź, czy możesz dostrzec podobieństwa.
- Sprawdź opcję "**zapamiętaj mnie**", jeśli istnieje, aby zobaczyć, jak działa. Jeśli istnieje i może być podatna, zawsze używaj ciasteczka **zapamiętaj mnie** bez żadnego innego ciasteczka.
- Sprawdź, czy poprzednie ciasteczko działa nawet po zmianie hasła.
#### **Zaawansowane ataki na ciasteczka**
Jeśli ciasteczko pozostaje takie samo (lub prawie takie samo) podczas logowania, prawdopodobnie oznacza to, że ciasteczko jest związane z jakimś polem twojego konta (prawdopodobnie nazwiskiem). Wtedy możesz:
Jeśli ciasteczko pozostaje takie samo (lub prawie takie samo) po zalogowaniu, prawdopodobnie oznacza to, że ciasteczko jest związane z jakimś polem twojego konta (prawdopodobnie nazwiskiem użytkownika). Wtedy możesz:
- Spróbować utworzyć wiele **kont** z bardzo **podobnymi** nazwiskami i spróbować **zgadnąć**, jak działa algorytm.
- Spróbować **bruteforce'ować nazwisko**. Jeśli ciasteczko jest zapisywane tylko jako metoda uwierzytelniania dla twojego nazwiska, wtedy możesz utworzyć konto z nazwiskiem "**Bmin**" i **bruteforce'ować** każdy pojedynczy **bit** swojego ciasteczka, ponieważ jedno z ciasteczek, które spróbujesz, będzie należało do "**admin**".
- Spróbować utworzyć wiele **kont** z bardzo **podobnymi** nazwiskami użytkowników i spróbować **zgadnąć**, jak działa algorytm.
- Spróbować **bruteforce'ować nazwisko użytkownika**. Jeśli ciasteczko jest zapisywane tylko jako metoda uwierzytelniania dla twojego nazwiska użytkownika, wtedy możesz utworzyć konto z nazwiskiem użytkownika "**Bmin**" i **bruteforce'ować** każdy pojedynczy **bit** swojego ciasteczka, ponieważ jedno z ciasteczek, które spróbujesz, będzie należało do "**admin**".
- Spróbuj **Padding** **Oracle** (możesz odszyfrować zawartość ciasteczka). Użyj **padbuster**.
**Padding Oracle - przykłady Padbuster**
**Padding Oracle - Przykłady Padbuster**
```bash
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
@ -254,7 +279,7 @@ To wykonanie da ci ciasteczko poprawnie zaszyfrowane i zakodowane z ciągiem **u
**CBC-MAC**
Może ciasteczko mogłoby mieć jakąś wartość i mogłoby być podpisane przy użyciu CBC. Wtedy integralność wartości to podpis stworzony przy użyciu CBC z tą samą wartością. Ponieważ zaleca się użycie jako IV wektora zerowego, ten typ sprawdzania integralności może być podatny na ataki.
Może ciasteczko mogłoby mieć jakąś wartość i mogłoby być podpisane przy użyciu CBC. Wtedy integralność wartości to podpis stworzony przy użyciu CBC z tą samą wartością. Ponieważ zaleca się użycie jako IV wektora zerowego, ten typ sprawdzania integralności może być podatny.
**Atak**
@ -273,9 +298,9 @@ Utwórz 2 użytkowników z prawie tymi samymi danymi (nazwa użytkownika, hasło
Utwórz użytkownika o nazwie na przykład "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i sprawdź, czy w ciasteczku jest jakiś wzór (ponieważ ECB szyfruje z tym samym kluczem każdy blok, te same zaszyfrowane bajty mogą się pojawić, jeśli nazwa użytkownika jest szyfrowana).
Powinien być wzór (o rozmiarze używanego bloku). Zatem, wiedząc, jak jest zaszyfrowana grupa "a", możesz stworzyć nazwę użytkownika: "a"\*(rozmiar bloku)+"admin". Następnie możesz usunąć zaszyfrowany wzór bloku "a" z ciasteczka. I będziesz miał ciasteczko dla nazwy użytkownika "admin".
Powinien być wzór (o rozmiarze używanego bloku). Zatem, wiedząc, jak jest zaszyfrowana masa "a", możesz stworzyć nazwę użytkownika: "a"\*(rozmiar bloku)+"admin". Następnie możesz usunąć zaszyfrowany wzór bloku "a" z ciasteczka. I będziesz miał ciasteczko dla nazwy użytkownika "admin".
## References
## Referencje
- [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
- [https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd)