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/generic-methodologies-and-resources/external-recon-meth

Browse Source
This commit is contained in:
Translator 2025-03-29 22:58:52 +00:00
parent b67f83d2f4
commit 9404e920d5
3 changed files with 76 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md
View File

@ -2,18 +2,13 @@
{{#include ../../banners/hacktricks-training.md}}
Teraz, gdy zbudowaliśmy listę zasobów w naszym zakresie, czas poszukać kilku łatwych do znalezienia owoców OSINT.
### Platformy, które już szukały wycieków
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
### Wyciek kluczy API w github
### Narzędzia do znajdowania sekretów w repozytoriach git i systemie plików
- [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
- [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
- [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)

80
src/pentesting-web/oauth-to-account-takeover.md
View File

@ -4,21 +4,21 @@
## Podstawowe informacje <a href="#d4a8" id="d4a8"></a>
OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi w [dokumentacji OAuth 2.0](https://oauth.net/2/). Ta dyskusja koncentruje się głównie na szeroko stosowanym [typie przyznawania kodu autoryzacji OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), zapewniającym **ramy autoryzacji, które umożliwiają aplikacji dostęp do konta użytkownika w innej aplikacji lub wykonywanie działań na tym koncie** (serwer autoryzacji).
OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi w [dokumentacji OAuth 2.0](https://oauth.net/2/). Ta dyskusja koncentruje się głównie na szeroko stosowanym [typie przyznawania kodu autoryzacji OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), zapewniającym **ramy autoryzacji, które umożliwiają aplikacji dostęp do konta użytkownika w innej aplikacji lub wykonywanie działań w jego imieniu** (serwer autoryzacji).
Rozważmy hipotetyczną stronę internetową _**https://example.com**_, zaprojektowaną w celu **prezentacji wszystkich Twoich postów w mediach społecznościowych**, w tym prywatnych. Aby to osiągnąć, wykorzystuje się OAuth 2.0. _https://example.com_ poprosi o Twoją zgodę na **dostęp do Twoich postów w mediach społecznościowych**. W konsekwencji na _https://socialmedia.com_ pojawi się ekran zgody, przedstawiający **żądane uprawnienia oraz dewelopera składającego prośbę**. Po Twojej autoryzacji, _https://example.com_ zyskuje możliwość **dostępu do Twoich postów w Twoim imieniu**.
Ważne jest, aby zrozumieć następujące komponenty w ramach OAuth 2.0:
- **właściciel zasobu**: Ty, jako **użytkownik/podmiot**, autoryzujesz dostęp do swojego zasobu, jak posty na Twoim koncie w mediach społecznościowych.
- **serwer zasobów**: **serwer zarządzający uwierzytelnionymi żądaniami** po tym, jak aplikacja uzyskała `access token` w imieniu `właściciela zasobu`, np. **https://socialmedia.com**.
- **serwer zasobów**: **serwer zarządzający uwierzytelnionymi żądaniami** po tym, jak aplikacja zabezpieczyła `access token` w imieniu `właściciela zasobu`, np. **https://socialmedia.com**.
- **aplikacja kliencka**: **aplikacja ubiegająca się o autoryzację** od `właściciela zasobu`, taka jak **https://example.com**.
- **serwer autoryzacji**: **serwer, który wydaje `access tokens`** dla `aplikacji klienckiej` po pomyślnej autoryzacji `właściciela zasobu`, np. **https://socialmedia.com**.
- **serwer autoryzacji**: **serwer, który wydaje `access tokens`** dla `aplikacji klienckiej` po pomyślnej autoryzacji `właściciela zasobu` i zabezpieczeniu autoryzacji, np. **https://socialmedia.com**.
- **client_id**: Publiczny, unikalny identyfikator aplikacji.
- **client_secret:** Poufny klucz, znany wyłącznie aplikacji i serwerowi autoryzacji, używany do generowania `access_tokens`.
- **response_type**: Wartość określająca **typ żądanego tokena**, jak `code`.
- **scope**: **poziom dostępu**, o który `aplikacja kliencka` prosi `właściciela zasobu`.
- **redirect_uri**: **URL, na który użytkownik jest przekierowywany po autoryzacji**. Zazwyczaj musi być zgodny z wcześniej zarejestrowanym URL przekierowania.
- **redirect_uri**: **URL, na który użytkownik jest przekierowywany po autoryzacji**. Zazwyczaj musi on odpowiadać wcześniej zarejestrowanemu URL przekierowania.
- **state**: Parametr do **utrzymywania danych podczas przekierowania użytkownika do i z serwera autoryzacji**. Jego unikalność jest kluczowa jako **mechanizm ochrony przed CSRF**.
- **grant_type**: Parametr wskazujący **typ przyznania i typ tokena, który ma być zwrócony**.
- **code**: Kod autoryzacji z `serwera autoryzacji`, używany razem z `client_id` i `client_secret` przez aplikację kliencką do uzyskania `access_token`.
@ -29,7 +29,7 @@ Ważne jest, aby zrozumieć następujące komponenty w ramach OAuth 2.0:
**Rzeczywisty przepływ OAuth** przebiega następująco:
1. Przechodzisz do [https://example.com](https://example.com) i wybierasz przycisk „Integracja z mediami społecznościowymi”.
1. Przechodzisz do [https://example.com](https://example.com) i wybierasz przycisk „Integruj z mediami społecznościowymi”.
2. Strona wysyła żądanie do [https://socialmedia.com](https://socialmedia.com) z prośbą o Twoją autoryzację, aby aplikacja https://example.com mogła uzyskać dostęp do Twoich postów. Żądanie jest skonstruowane w następujący sposób:
```
https://socialmedia.com/auth
@ -40,7 +40,7 @@ https://socialmedia.com/auth
&state=randomString123
```
3. Następnie zostaniesz przedstawiony stronie zgody.
4. Po twojej akceptacji, Social Media wysyła odpowiedź na `redirect_uri` z parametrami `code` i `state`:
4. Po twojej akceptacji, Social Media wysyła odpowiedź do `redirect_uri` z parametrami `code` i `state`:
```
https://example.com?code=uniqueCode123&state=randomString123
```
@ -56,13 +56,13 @@ Host: socialmedia.com
### Otwarty redirect_uri <a href="#cc36" id="cc36"></a>
`redirect_uri` jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ kieruje, gdzie wrażliwe dane, takie jak kody autoryzacyjne, są wysyłane po autoryzacji. Jeśli jest źle skonfigurowany, może umożliwić atakującym przekierowanie tych żądań do złośliwych serwerów, co umożliwia przejęcie konta.
`redirect_uri` jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ kieruje, gdzie wrażliwe dane, takie jak kody autoryzacji, są wysyłane po autoryzacji. Jeśli jest źle skonfigurowany, może pozwolić atakującym na przekierowanie tych żądań do złośliwych serwerów, co umożliwia przejęcie konta.
Techniki eksploatacji różnią się w zależności od logiki walidacji serwera autoryzacji. Mogą obejmować od ścisłego dopasowania ścieżek do akceptowania dowolnego URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, traversale ścieżek, wykorzystywanie słabych wyrażeń regularnych oraz wstrzykiwanie HTML w celu kradzieży tokenów.
Techniki eksploatacji różnią się w zależności od logiki walidacji serwera autoryzacji. Mogą obejmować od ścisłego dopasowania ścieżek do akceptowania dowolnego URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, przechodzenie przez ścieżki, wykorzystywanie słabych wyrażeń regularnych oraz wstrzykiwanie HTML w celu kradzieży tokenów.
Oprócz `redirect_uri`, inne parametry OAuth i OpenID, takie jak `client_uri`, `policy_uri`, `tos_uri` i `initiate_login_uri`, są również podatne na ataki przekierowujące. Parametry te są opcjonalne, a ich wsparcie różni się w zależności od serwerów.
Dla tych, którzy celują w serwer OpenID, punkt końcowy odkrywania (`**.well-known/openid-configuration**`) często zawiera cenne szczegóły konfiguracyjne, takie jak `registration_endpoint`, `request_uri_parameter_supported` oraz "`require_request_uri_registration`. Te szczegóły mogą pomóc w identyfikacji punktu końcowego rejestracji i innych specyfikacji konfiguracyjnych serwera.
Dla tych, którzy celują w serwer OpenID, punkt końcowy odkrywania (`**.well-known/openid-configuration**`) często zawiera cenne szczegóły konfiguracyjne, takie jak `registration_endpoint`, `request_uri_parameter_supported` i "`require_request_uri_registration`. Te szczegóły mogą pomóc w identyfikacji punktu końcowego rejestracji i innych specyfikacji konfiguracyjnych serwera.
### XSS w implementacji przekierowania <a href="#bda5" id="bda5"></a>
@ -72,9 +72,9 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
```
### CSRF - Niewłaściwe zarządzanie parametrem state <a href="#bda5" id="bda5"></a>
W implementacjach OAuth, niewłaściwe użycie lub pominięcie **parametru `state`** może znacznie zwiększyć ryzyko ataków **Cross-Site Request Forgery (CSRF)**. Ta podatność występuje, gdy parametr `state` jest **nieużywany, używany jako statyczna wartość lub niewłaściwie walidowany**, co pozwala atakującym na ominięcie ochrony CSRF.
W implementacjach OAuth, niewłaściwe użycie lub pominięcie **parametru `state`** może znacznie zwiększyć ryzyko ataków **Cross-Site Request Forgery (CSRF)**. Ta podatność pojawia się, gdy parametr `state` jest **nieużywany, używany jako statyczna wartość lub nieprawidłowo walidowany lub powiązany z sesją użytkownika** podczas logowania, co pozwala atakującym na ominięcie ochrony CSRF.
Atakujący mogą to wykorzystać, przechwytując proces autoryzacji, aby powiązać swoje konto z kontem ofiary, co prowadzi do potencjalnych **przejęć konta**. Jest to szczególnie krytyczne w aplikacjach, w których OAuth jest używany do **celów uwierzytelniania**.
Atakujący mogą to wykorzystać, przechwytując proces autoryzacji, aby powiązać swoje konto z kontem ofiary, co prowadzi do potencjalnych **przejęć kont** poprzez zmuszenie użytkownika do zalogowania się za pomocą prawie zakończonego przepływu oauth należącego do atakującego. Jest to szczególnie krytyczne w aplikacjach, w których OAuth jest używany do **celów uwierzytelniania**.
Przykłady tej podatności w rzeczywistych sytuacjach zostały udokumentowane w różnych **wyzwaniach CTF** i **platformach hackingowych**, podkreślając jej praktyczne implikacje. Problem ten dotyczy również integracji z usługami stron trzecich, takimi jak **Slack**, **Stripe** i **PayPal**, gdzie atakujący mogą przekierowywać powiadomienia lub płatności na swoje konta.
@ -82,16 +82,16 @@ Właściwe zarządzanie i walidacja **parametru `state`** są kluczowe dla ochro
### Przed przejęciem konta <a href="#ebe4" id="ebe4"></a>
1. **Bez weryfikacji e-maila przy tworzeniu konta**: Atakujący mogą z wyprzedzeniem stworzyć konto używając e-maila ofiary. Jeśli ofiara później użyje usługi strony trzeciej do logowania, aplikacja może nieumyślnie powiązać to konto strony trzeciej z wcześniej utworzonym kontem atakującego, co prowadzi do nieautoryzowanego dostępu.
1. **Bez weryfikacji e-maila przy tworzeniu konta**: Atakujący mogą z wyprzedzeniem stworzyć konto używając e-maila ofiary. Jeśli ofiara później użyje usługi stron trzecich do logowania, aplikacja może nieumyślnie powiązać to konto z wcześniej stworzonym kontem atakującego, co prowadzi do nieautoryzowanego dostępu.
2. **Wykorzystywanie luźnej weryfikacji e-maila w OAuth**: Atakujący mogą wykorzystać usługi OAuth, które nie weryfikują e-maili, rejestrując się w ich usłudze, a następnie zmieniając adres e-mail konta na e-mail ofiary. Ta metoda również niesie ryzyko nieautoryzowanego dostępu do konta, podobnie jak w pierwszym scenariuszu, ale przez inny wektor ataku.
### Ujawnienie sekretów <a href="#e177" id="e177"></a>
Identyfikacja i ochrona tajnych parametrów OAuth jest kluczowa. Podczas gdy **`client_id`** można bezpiecznie ujawniać, ujawnienie **`client_secret`** stwarza znaczące ryzyko. Jeśli `client_secret` zostanie skompromitowane, atakujący mogą wykorzystać tożsamość i zaufanie aplikacji do **kradzieży `access_tokens`** użytkowników i prywatnych informacji.
Identyfikacja i ochrona tajnych parametrów OAuth jest kluczowa. Podczas gdy **`client_id`** można bezpiecznie ujawniać, ujawnienie **`client_secret`** stwarza znaczące ryzyko. Jeśli `client_secret` zostanie skompromitowane, atakujący mogą wykorzystać tożsamość i zaufanie aplikacji do **kradzieży `access_tokens` użytkowników** i prywatnych informacji.
Powszechna podatność występuje, gdy aplikacje błędnie obsługują wymianę `code` autoryzacji na `access_token` po stronie klienta zamiast po stronie serwera. Ten błąd prowadzi do ujawnienia `client_secret`, umożliwiając atakującym generowanie `access_tokens` pod pretekstem aplikacji. Ponadto, poprzez inżynierię społeczną, atakujący mogą eskalować uprawnienia, dodając dodatkowe zakresy do autoryzacji OAuth, dalej wykorzystując zaufany status aplikacji.
Powszechna podatność pojawia się, gdy aplikacje błędnie obsługują wymianę `code` autoryzacji na `access_token` po stronie klienta, a nie serwera. Ten błąd prowadzi do ujawnienia `client_secret`, umożliwiając atakującym generowanie `access_tokens` pod przykrywką aplikacji. Ponadto, poprzez inżynierię społeczną, atakujący mogą eskalować uprawnienia, dodając dodatkowe zakresy do autoryzacji OAuth, dalej wykorzystując zaufany status aplikacji.
### Bruteforce Client Secret
### Bruteforce sekretu klienta
Możesz spróbować **bruteforce'ować client_secret** dostawcy usług z dostawcą tożsamości, aby spróbować ukraść konta.\
Żądanie do BF może wyglądać podobnie do:
@ -160,17 +160,17 @@ Dzieje się tak, ponieważ **atakujący** może stworzyć **aplikację wspieraj
### Dwa linki i cookie <a href="#bda5" id="bda5"></a>
Zgodnie z [**tym artykułem**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), możliwe było zmuszenie ofiary do otwarcia strony z **returnUrl** wskazującym na host atakującego. Informacje te byłyby **przechowywane w cookie (RU)**, a w **późniejszym kroku** **prompt** **zapytuje** **użytkownika**, czy chce udzielić dostępu do hosta atakującego.
Zgodnie z [**tym artykułem**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), możliwe było zmuszenie ofiary do otwarcia strony z **returnUrl** wskazującym na host atakującego. Informacje te byłyby **przechowywane w cookie (RU)**, a w **późniejszym kroku** **prompt** zapyta **użytkownika**, czy chce udzielić dostępu do hosta atakującego.
Aby obejść ten prompt, możliwe było otwarcie zakładki w celu zainicjowania **przepływu Oauth**, który ustawiłby to cookie RU za pomocą **returnUrl**, zamknięcie zakładki przed wyświetleniem promptu i otwarcie nowej zakładki bez tej wartości. Wtedy **prompt nie poinformuje o hoście atakującego**, ale cookie zostanie ustawione na niego, więc **token zostanie wysłany do hosta atakującego** w przekierowaniu.
Aby obejść ten prompt, możliwe było otwarcie zakładki w celu zainicjowania **przepływu Oauth**, który ustawiłby to cookie RU używając **returnUrl**, zamknięcie zakładki przed wyświetleniem promptu i otwarcie nowej zakładki bez tej wartości. Wtedy **prompt nie poinformuje o hoście atakującego**, ale cookie zostanie ustawione na niego, więc **token zostanie wysłany do hosta atakującego** w przekierowaniu.
### Obejście interakcji z promptem <a href="#bda5" id="bda5"></a>
Jak wyjaśniono w [**tym filmie**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), niektóre implementacje OAuth pozwalają wskazać parametr **`prompt`** GET jako None (**`&prompt=none`**), aby **zapobiec pytaniu użytkowników o potwierdzenie** przyznanego dostępu w promptcie w sieci, jeśli są już zalogowani na platformie.
Jak wyjaśniono w [**tym filmie**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), niektóre implementacje OAuth pozwalają wskazać parametr **`prompt`** jako None (**`&prompt=none`**), aby **zapobiec pytaniu użytkowników o potwierdzenie** przyznanego dostępu w prompt w sieci, jeśli są już zalogowani na platformie.
### response_mode
Jak [**wyjaśniono w tym filmie**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), możliwe jest wskazanie parametru **`response_mode`**, aby określić, gdzie chcesz, aby kod został podany w ostatecznym URL:
Jak [**wyjaśniono w tym filmie**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), może być możliwe wskazanie parametru **`response_mode`**, aby określić, gdzie chcesz, aby kod został podany w ostatecznym URL:
- `response_mode=query` -> Kod jest podawany wewnątrz parametru GET: `?code=2397rf3gu93f`
- `response_mode=fragment` -> Kod jest podawany wewnątrz fragmentu URL `#code=2397rf3gu93f`
@ -179,45 +179,67 @@ Jak [**wyjaśniono w tym filmie**](https://www.youtube.com/watch?v=n9x7_J_a_7Q),
### Przepływ OAuth ROPC - obejście 2 FA <a href="#b440" id="b440"></a>
Zgodnie z [**tym wpisem na blogu**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), jest to przepływ OAuth, który pozwala na logowanie się w OAuth za pomocą **nazwa użytkownika** i **hasła**. Jeśli podczas tego prostego przepływu zwrócony zostanie **token** z dostępem do wszystkich działań, które użytkownik może wykonać, możliwe jest obejście 2FA za pomocą tego tokena.
Zgodnie z [**tym wpisem na blogu**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), jest to przepływ OAuth, który pozwala na logowanie się w OAuth za pomocą **nazwa użytkownika** i **hasła**. Jeśli podczas tego prostego przepływu zwrócony zostanie **token** z dostępem do wszystkich działań, które użytkownik może wykonać, to możliwe jest obejście 2FA przy użyciu tego tokena.
### ATO na stronie internetowej przekierowującej na podstawie otwartego przekierowania do referrera <a href="#bda5" id="bda5"></a>
Ten [**wpis na blogu**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) opisuje, jak możliwe było nadużycie **otwartego przekierowania** do wartości z **referrera**, aby nadużyć OAuth do ATO. Atak polegał na:
1. Ofiara uzyskuje dostęp do strony internetowej atakującego
2. Ofiara otwiera złośliwy link, a opener rozpoczyna przepływ Google OAuth z `response_type=id_token,code&prompt=none` jako dodatkowymi parametrami, używając jako **referrera strony internetowej atakującego**.
3. W openerze, po autoryzacji ofiary przez dostawcę, wysyła ich z powrotem do wartości parametru `redirect_uri` (strona internetowa ofiary) z kodem 30X, który nadal utrzymuje stronę internetową atakującego w refererze.
4. Strona internetowa ofiary **wywołuje otwarte przekierowanie na podstawie referrera**, przekierowując użytkownika ofiary na stronę internetową atakującego, ponieważ **`respose_type`** był **`id_token,code`**, kod zostanie wysłany z powrotem do atakującego w **fragmencie** URL, co pozwoli mu przejąć konto użytkownika za pomocą Google na stronie ofiary.
2. Ofiara otwiera złośliwy link, a otwieracz rozpoczyna przepływ Google OAuth z `response_type=id_token,code&prompt=none` jako dodatkowymi parametrami, używając jako **referrera strony internetowej atakującego**.
3. W otwieraczu, po autoryzacji ofiary przez dostawcę, wysyła ich z powrotem do wartości parametru `redirect_uri` (strona ofiary) z kodem 30X, który nadal utrzymuje stronę internetową atakującego w refererze.
4. Strona **ofiary wyzwala otwarte przekierowanie na podstawie referrera**, przekierowując użytkownika ofiary na stronę internetową atakującego, ponieważ **`respose_type`** był **`id_token,code`**, kod zostanie wysłany z powrotem do atakującego w **fragmencie** URL, co pozwoli mu przejąć konto użytkownika za pomocą Google na stronie ofiary.
### Parametry SSRFs <a href="#bda5" id="bda5"></a>
[**Sprawdź to badanie**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Aby uzyskać dalsze szczegóły na temat tej techniki.**
Dynamiczna rejestracja klienta w OAuth stanowi mniej oczywisty, ale krytyczny wektor dla luk w zabezpieczeniach, szczególnie dla ataków **Server-Side Request Forgery (SSRF)**. Ten punkt końcowy pozwala serwerom OAuth na otrzymywanie szczegółów dotyczących aplikacji klienckich, w tym wrażliwych adresów URL, które mogą być wykorzystywane.
Dynamiczna rejestracja klienta w OAuth służy jako mniej oczywisty, ale krytyczny wektor dla luk w zabezpieczeniach, szczególnie dla ataków **Server-Side Request Forgery (SSRF)**. Ten punkt końcowy pozwala serwerom OAuth na otrzymywanie szczegółów dotyczących aplikacji klienckich, w tym wrażliwych adresów URL, które mogą być wykorzystane.
**Kluczowe punkty:**
- **Dynamiczna rejestracja klienta** jest często mapowana na `/register` i akceptuje szczegóły takie jak `client_name`, `client_secret`, `redirect_uris` oraz adresy URL dla logo lub zestawów kluczy JSON Web (JWK) za pomocą żądań POST.
- Ta funkcja przestrzega specyfikacji określonych w **RFC7591** i **OpenID Connect Registration 1.0**, które zawierają parametry potencjalnie podatne na SSRF.
- Proces rejestracji może nieumyślnie narażać serwery na SSRF na kilka sposobów:
- **`logo_uri`**: Adres URL dla logo aplikacji klienckiej, które może być pobierane przez serwer, wywołując SSRF lub prowadząc do XSS, jeśli adres URL jest źle obsługiwany.
- **`logo_uri`**: Adres URL dla logo aplikacji klienckiej, który może być pobierany przez serwer, wyzwalając SSRF lub prowadząc do XSS, jeśli adres URL jest źle obsługiwany.
- **`jwks_uri`**: Adres URL do dokumentu JWK klienta, który, jeśli zostanie złośliwie skonstruowany, może spowodować, że serwer wykona zewnętrzne żądania do serwera kontrolowanego przez atakującego.
- **`sector_identifier_uri`**: Odnosi się do tablicy JSON `redirect_uris`, którą serwer może pobrać, tworząc możliwość SSRF.
- **`request_uris`**: Wymienia dozwolone URI żądań dla klienta, które mogą być wykorzystywane, jeśli serwer pobiera te URI na początku procesu autoryzacji.
**Strategia eksploatacji:**
- SSRF można wywołać, rejestrując nowego klienta z złośliwymi adresami URL w parametrach takich jak `logo_uri`, `jwks_uri` lub `sector_identifier_uri`.
- SSRF można wyzwolić, rejestrując nowego klienta z złośliwymi adresami URL w parametrach takich jak `logo_uri`, `jwks_uri` lub `sector_identifier_uri`.
- Chociaż bezpośrednia eksploatacja za pomocą `request_uris` może być ograniczona przez kontrole białej listy, dostarczenie wcześniej zarejestrowanego, kontrolowanego przez atakującego `request_uri` może ułatwić SSRF podczas fazy autoryzacji.
## Warunki wyścigu dostawców OAuth
## Wyścigi warunków dostawców OAuth
Jeśli platforma, którą testujesz, jest dostawcą OAuth [**przeczytaj to, aby przetestować możliwe warunki wyścigu**](race-condition.md).
Jeśli platforma, którą testujesz, jest dostawcą OAuth [**przeczytaj to, aby przetestować możliwe wyścigi warunków**](race-condition.md).
## Odniesienia
## Atak na zmienne mutowalne
W OAuth pole sub unikalnie identyfikuje użytkownika, ale jego format różni się w zależności od serwera autoryzacji. Aby ustandaryzować identyfikację użytkowników, niektórzy klienci używają adresów e-mail lub identyfikatorów użytkowników. Jednak jest to ryzykowne, ponieważ:
- Niektóre serwery autoryzacji nie zapewniają, że te właściwości (takie jak e-mail) pozostają niezmienne.
- W niektórych implementacjach—takich jak **"Zaloguj się za pomocą Microsoftu"**—klient polega na polu e-mail, które jest **kontrolowane przez użytkownika w Entra ID** i nie jest weryfikowane.
- Atakujący może to wykorzystać, tworząc własną organizację Azure AD (np. doyensectestorg) i używając jej do przeprowadzenia logowania Microsoft.
- Mimo że identyfikator obiektu (przechowywany w sub) jest niezmienny i bezpieczny, pole e-mail, na którym polega, może umożliwić przejęcie konta (na przykład, przejęcie konta takiego jak victim@gmail.com).
## Atak na mylenie klientów
W **Ataku na mylenie klientów**, aplikacja korzystająca z przepływu OAuth Implicit Flow nie weryfikuje, że ostateczny token dostępu jest generowany specjalnie dla jej własnego identyfikatora klienta. Atakujący zakłada publiczną stronę internetową, która korzysta z przepływu OAuth Implicit Flow Google, oszukując tysiące użytkowników na logowanie się i w ten sposób zbierając tokeny dostępu przeznaczone dla strony atakującego. Jeśli ci użytkownicy mają również konta na innej podatnej stronie internetowej, która nie weryfikuje identyfikatora klienta tokena, atakujący może ponownie wykorzystać zebrane tokeny, aby podszyć się pod ofiary i przejąć ich konta.
## Atak na podniesienie zakresu
Typ **Authorization Code Grant** obejmuje bezpieczną komunikację serwer-serwer w celu przesyłania danych użytkownika. Jednak jeśli **Serwer Autoryzacji** niejawnie ufa parametrowi zakresu w żądaniu tokena dostępu (parametr nieokreślony w RFC), złośliwa aplikacja może podnieść uprawnienia kodu autoryzacyjnego, żądając wyższego zakresu. Po wygenerowaniu **tokena dostępu** **Serwer Zasobów** musi go zweryfikować: dla tokenów JWT wiąże się to z sprawdzeniem podpisu JWT i wyodrębnieniem danych, takich jak client_id i scope, podczas gdy dla tokenów losowych serwer musi zapytać Serwer Autoryzacji, aby uzyskać szczegóły tokena.
## Przechwytywanie schematu przekierowania
W mobilnych implementacjach OAuth aplikacje używają **niestandardowych schematów URI** do odbierania przekierowań z kodami autoryzacyjnymi. Jednak ponieważ wiele aplikacji może zarejestrować ten sam schemat na urządzeniu, założenie, że tylko legalny klient kontroluje URI przekierowania, jest naruszane. Na Androidzie, na przykład, URI intencji takie jak `com.example.app://` oauth jest przechwytywane na podstawie schematu i opcjonalnych filtrów zdefiniowanych w filtrze intencji aplikacji. Ponieważ rozwiązywanie intencji w Androidzie może być szerokie—szczególnie jeśli tylko schemat jest określony—atakujący może zarejestrować złośliwą aplikację z starannie skonstruowanym filtrem intencji, aby przechwycić kod autoryzacyjny. To może **umożliwić przejęcie konta** zarówno poprzez interakcję użytkownika (gdy wiele aplikacji jest uprawnionych do obsługi intencji), jak i za pomocą technik omijających, które wykorzystują zbyt specyficzne filtry, jak opisano w schemacie oceny Ostorlab.
## Odnośniki
- [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
- [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)
{{#include ../banners/hacktricks-training.md}}

28
src/pentesting-web/unicode-injection/README.md
View File

@ -4,13 +4,13 @@
## Wprowadzenie
W zależności od tego, jak backend/frontend zachowuje się, gdy **otrzymuje dziwne znaki unicode**, atakujący może być w stanie **obejść zabezpieczenia i wstrzyknąć dowolne znaki**, które mogą być użyte do **wykorzystania luk w wstrzykiwaniu**, takich jak XSS czy SQLi.
W zależności od tego, jak zachowuje się back-end/front-end, gdy **otrzymuje dziwne znaki unicode**, atakujący może być w stanie **obejść zabezpieczenia i wstrzyknąć dowolne znaki**, które mogą być użyte do **wykorzystania luk w wstrzykiwaniu**, takich jak XSS czy SQLi.
## Normalizacja Unicode
Normalizacja Unicode zachodzi, gdy **znaki unicode są normalizowane do znaków ascii**.
Jednym z powszechnych scenariuszy tego typu luki jest sytuacja, gdy system **modyfikuje** w jakiś sposób **wejście** użytkownika **po jego sprawdzeniu**. Na przykład, w niektórych językach proste wywołanie, aby **zmienić wejście na wielkie lub małe litery**, może znormalizować podane wejście, a **unicode zostanie przekształcone na ASCII**, generując nowe znaki.\
Jednym z powszechnych scenariuszy tego typu luki jest sytuacja, gdy system **modyfikuje** w jakiś sposób **wejście** użytkownika **po jego sprawdzeniu**. Na przykład, w niektórych językach proste wywołanie do zamiany **wejścia na wielkie lub małe litery** może znormalizować dane wejściowe, a **unicode zostanie przekształcone na ASCII**, generując nowe znaki.\
Aby uzyskać więcej informacji, sprawdź:
{{#ref}}
@ -19,18 +19,18 @@ unicode-normalization.md
## `\u` do `%`
Znaki unicode są zazwyczaj reprezentowane za pomocą **prefiksu `\u`**. Na przykład znak `㱋` to `\u3c4b`([sprawdź to tutaj](https://unicode-explorer.com/c/3c4B)). Jeśli backend **przekształca** prefiks **`\u` w `%`**, wynikowy ciąg będzie `%3c4b`, który po dekodowaniu URL to: **`<4b`**. I, jak widać, **znak ` < ` jest wstrzykiwany**.\
Możesz użyć tej techniki, aby **wstrzyknąć dowolny rodzaj znaku**, jeśli backend jest podatny.\
Znaki unicode są zazwyczaj reprezentowane z **prefiksem `\u`**. Na przykład znak `㱋` to `\u3c4b`([sprawdź to tutaj](https://unicode-explorer.com/c/3c4B)). Jeśli backend **przekształca** prefiks **`\u` na `%`**, wynikowy ciąg będzie `%3c4b`, który po dekodowaniu URL to: **`<4b`**. I, jak widać, **znak ` < ` jest wstrzykiwany**.\
Możesz użyć tej techniki do **wstrzykiwania dowolnego rodzaju znaku**, jeśli backend jest podatny.\
Sprawdź [https://unicode-explorer.com/](https://unicode-explorer.com/), aby znaleźć potrzebne znaki.
Ta luka pochodzi z rzeczywistej luki, którą odkrył badacz, aby uzyskać bardziej szczegółowe wyjaśnienie, sprawdź [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
## Wstrzykiwanie Emoji
Back-endy dziwnie się zachowują, gdy **otrzymują emoji**. Tak było w [**tym opisie**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209), gdzie badacz zdołał osiągnąć XSS z ładunkiem takim jak: `💋img src=x onerror=alert(document.domain)//💛`
Back-endy zachowują się dziwnie, gdy **otrzymują emoji**. Tak było w [**tym opisie**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209), gdzie badacz zdołał osiągnąć XSS z ładunkiem takim jak: `💋img src=x onerror=alert(document.domain)//💛`
W tym przypadku błąd polegał na tym, że serwer po usunięciu złośliwych znaków **przekonwertował ciąg UTF-8 z Windows-1252 na UTF-8** (w zasadzie kodowanie wejściowe i konwersja kodowania były niezgodne). Wtedy to nie daje poprawnego <, tylko dziwne unicode: `‹`\
``Więc wzięli ten wynik i **przekonwertowali ponownie z UTF-8 na ASCII**. To **znormalizowało** `‹` do `<`, w ten sposób exploit mógł działać w tym systemie.\
``Więc wzięli ten wynik i **przekonwertowali ponownie z UTF-8 na ASCII**. To **znormalizowało** `‹` do ` < `, w ten sposób exploit mógł działać w tym systemie.\
To, co się wydarzyło:
```php
<?php
@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
echo "String: " . $str;
```
Lista emoji:
Emoji lists:
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
## Windows Best-Fit/Worst-fit
Jak wyjaśniono w **[tym świetnym poście](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, Windows ma funkcję nazwaną **Best-Fit**, która **zastępuje znaki unicode**, które nie mogą być wyświetlane w trybie ASCII, podobnym znakiem. Może to prowadzić do **nieoczekiwanego zachowania**, gdy backend **oczekuje konkretnego znaku**, ale otrzymuje inny.
Można znaleźć znaki best-fit w **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
Ponieważ Windows zazwyczaj konwertuje ciągi unicode na ciągi ascii jako jedną z ostatnich części wykonania (zwykle przechodząc z API z sufiksem "W" do API z sufiksem "A", jak `GetEnvironmentVariableA` i `GetEnvironmentVariableW`), pozwala to atakującym na obejście zabezpieczeń, wysyłając znaki unicode, które zostaną ostatecznie przekształcone w znaki ASCII, które wykonają nieoczekiwane działania.
W poście na blogu zaproponowano metody obejścia luk, które zostały naprawione przy użyciu **czarnej listy znaków**, wykorzystując **przechodzenie ścieżek** przy użyciu [znaków mapowanych na “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) i [znaków mapowanych na “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) lub nawet obejście zabezpieczeń przed ucieczką powłoki, takich jak `escapeshellarg` w PHP lub `subprocess.run` w Pythonie, używając listy; zrobiono to na przykład, używając **pełnozakresowych podwójnych cudzysłowów (U+FF02)** zamiast podwójnych cudzysłowów, więc na końcu to, co wyglądało jak 1 argument, zostało przekształcone w 2 argumenty.
**Zauważ, że aby aplikacja była podatna, musi używać "W" Windows API, ale kończyć wywołując "A" Windows API, aby utworzyć "Best-fit" ciągu unicode.**
**Wiele odkrytych luk nie zostanie naprawionych, ponieważ ludzie nie zgadzają się, kto powinien zająć się tym problemem.**
{{#include ../../banners/hacktricks-training.md}}