<summary><strong>Nauka hakowania AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **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.
OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi na stronie [dokumentacji OAuth 2.0](https://oauth.net/2/). Ta dyskusja skupia się głównie na powszechnie używanym [typie autoryzacji OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), zapewniającym **framework autoryzacji, który umożliwia aplikacji dostęp lub wykonywanie działań na koncie użytkownika w innej aplikacji** (serwer autoryzacji).
Rozważmy hipotetyczną stronę internetową _**https://example.com**_, zaprojektowaną do **prezentowania wszystkich Twoich postów na mediach społecznościowych**, w tym tych prywatnych. Aby to osiągnąć, wykorzystywane jest OAuth 2.0. _https://example.com_ poprosi o zgodę na **dostęp do Twoich postów na mediach społecznościowych**. W rezultacie na _https://socialmedia.com_ pojawi się ekran zgody, przedstawiający **uprawnienia, które są żądane, oraz dewelopera dokonującego żądania**. Po udzieleniu zgody, _https://example.com_ uzyskuje możliwość **dostępu do Twoich postów w Twoim imieniu**.
- **właściciel zasobu**: Ty, jako **użytkownik/encja**, autoryzujesz dostęp do swojego zasobu, takiego jak Twoje posty na mediach społecznościowych.
- **serwer zasobów**: Serwer zarządzający uwierzytelnionymi żądaniami po tym, jak aplikacja uzyskała `token dostępu` w imieniu `właściciela zasobu`, np. **https://socialmedia.com**.
- **aplikacja klienta**: Aplikacja, która **poszukuje autoryzacji** od `właściciela zasobu`, taka jak **https://example.com**.
- **serwer autoryzacji**: Serwer, który wydaje `tokeny dostępu` dla `aplikacji klienta` po pomyślnym uwierzytelnieniu `właściciela zasobu` i uzyskaniu autoryzacji, np. **https://socialmedia.com**.
- **redirect\_uri**: **URL, do którego użytkownik jest przekierowywany po autoryzacji**. Zazwyczaj musi to być zgodne z wcześniej zarejestrowanym adresem przekierowania.
- **state**: Parametr służący do **przechowywania danych podczas przekierowania użytkownika do i z serwera autoryzacji**. Jego unikalność jest kluczowa dla pełnienia roli **mechanizmu ochrony CSRF**.
- **grant\_type**: Parametr wskazujący **typ autoryzacji i typ zwracanego tokenu**.
- **code**: Kod autoryzacji z `serwera autoryzacji`, używany wspólnie z `client_id` i `client_secret` przez aplikację klienta do uzyskania `tokena dostępu`.
- **access\_token**: **Token, którego aplikacja klienta używa do żądań API** w imieniu `właściciela zasobu`.
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), prosząc o Twoją autoryzację, aby pozwolić aplikacji https://example.com na dostęp do Twoich postów. Żądanie jest zbudowane w następujący sposób:
5. https://example.com wykorzystuje ten `code`, wraz z jego `client_id` i `client_secret`, aby dokonać żądania po stronie serwera w celu uzyskania `access_token` w Twoim imieniu, umożliwiając dostęp do uprawnień, na które wyraziłeś zgodę:
6. Ostatecznie proces kończy się, gdy https://example.com wykorzystuje Twój `access_token` do wykonania wywołania interfejsu API do mediów społecznościowych w celu uzyskania dostępu
`redirect_uri` jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ określa, dokąd są wysyłane wrażliwe dane, takie jak kody autoryzacyjne, po autoryzacji. W przypadku błędnej konfiguracji, może umożliwić atakującym przekierowanie tych żądań do złośliwych serwerów, umożliwiając przejęcie konta.
Techniki eksploatacji różnią się w zależności od logiki walidacji serwera autoryzacyjnego. Mogą one obejmować od dokładnego dopasowania ścieżki do akceptowania dowolnego adresu URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, nawigację ścieżką, wykorzystywanie słabych wyrażeń regularnych oraz wstrzykiwanie HTML w celu kradzieży tokena.
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 przekierowania. Te parametry są opcjonalne, a ich obsługa różni się w zależności od serwerów.
Dla osób celujących w serwer OpenID, punkt końcowy odkrywania (`**.well-known/openid-configuration**`) często zawiera cenne szczegóły konfiguracji, 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 szczegółów konfiguracji serwera.
Jak wspomniano w tym raporcie z programu bug bounty [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), istnieje możliwość, że **adres URL przekierowania jest odzwierciedlany w odpowiedzi** serwera po uwierzytelnieniu użytkownika, co czyni go **podatnym na XSS**. Możliwy ładunek do testowania:
W implementacjach OAuth, nadużycie lub pominięcie parametru **`state`** może znacząco zwiększyć ryzyko ataków typu **Cross-Site Request Forgery (CSRF)**. Ta podnośność pojawia się, gdy parametr `state` jest albo **nie używany, używany jako wartość statyczna, albo nieprawidłowo zweryfikowany**, co pozwala atakującym ominąć zabezpieczenia CSRF.
Atakujący mogą wykorzystać to, przechwytując proces autoryzacji, aby połączyć swoje konto z kontem ofiary, co prowadzi do potencjalnego **przejęcia konta**. Jest to szczególnie krytyczne w aplikacjach, gdzie OAuth jest używany do **celów uwierzytelniania**.
Przykłady tej podatności w rzeczywistym świecie zostały udokumentowane w różnych **wyzwaniach CTF** i **platformach do hakowania**, podkreślając jej praktyczne implikacje. Problem ten dotyczy również integracji z usługami osób trzecich, takimi jak **Slack**, **Stripe** i **PayPal**, gdzie atakujący mogą przekierować powiadomienia lub płatności na swoje konta.
1.**Bez Weryfikacji Email podczas Tworzenia Konta**: Atakujący mogą uprzednio utworzyć konto, używając adresu e-mail ofiary. Jeśli ofiara później użyje usługi osób trzecich do logowania, aplikacja może nieumyślnie połączyć to konto osób trzecich z wcześniej utworzonym kontem atakującego, co prowadzi do nieautoryzowanego dostępu.
2.**Wykorzystanie Luźnej Weryfikacji Email w OAuth**: Atakujący mogą wykorzystać usługi OAuth, które nie weryfikują adresów e-mail, rejestrując się w ich usłudze, a następnie zmieniając adres e-mail konta na adres ofiary. Ta metoda podobnie niesie ryzyko nieautoryzowanego dostępu do konta, podobnie jak w pierwszym scenariuszu, ale poprzez inny wektor ataku.
Identyfikacja i ochrona tajnych parametrów OAuth są kluczowe. Podczas gdy **`client_id`** można bezpiecznie ujawnić, ujawnienie **`client_secret`** niesie ze sobą znaczne ryzyko. Jeśli `client_secret` zostanie skompromitowany, atakujący mogą wykorzystać tożsamość i zaufanie aplikacji do **kradzieży `access_tokens`** oraz prywatnych informacji.
Powszechną podatnością jest sytuacja, gdy aplikacje błędnie obsługują wymianę kodu autoryzacji na `access_token` po stronie klienta, a nie po stronie 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 autoryzacji OAuth, dalsze wykorzystując zaufane status aplikacji.
**[Sprawdź ten post](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
W tym raporcie z programu bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) możesz zobaczyć, że **token**, który **AWS Cognito** zwraca użytkownikowi, może mieć **wystarczające uprawnienia do nadpisania danych użytkownika**. Dlatego jeśli możesz **zmienić adres e-mail użytkownika na inny adres e-mail**, możesz **przejąć** inne konta.
Jak [**wspomniano w tym opracowaniu**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), przepływy OAuth, które oczekują otrzymania **tokena** (a nie kodu), mogą być podatne, jeśli nie sprawdzają, czy token należy do aplikacji.
To dlatego, że **atakujący** mógłby stworzyć **aplikację obsługującą OAuth i zalogować się przez Facebooka** (na przykład) w swojej własnej aplikacji. Następnie, gdy ofiara zaloguje się przez Facebooka w **aplikacji atakującego**, atakujący mógłby uzyskać **token OAuth użytkownika udzielony jego aplikacji i użyć go do zalogowania się w aplikacji OAuth ofiary, korzystając z tokenu użytkownika ofiary**.
Dlatego jeśli atakujący zdoła zdobyć dostęp użytkownika do swojej własnej aplikacji OAuth, będzie mógł przejąć konto ofiary w aplikacjach, które oczekują tokenu i nie sprawdzają, czy token został udzielony dla ich identyfikatora aplikacji.
Zgodnie z [**tym opracowaniem**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), było możliwe, aby sprawić, że ofiara otworzy stronę z **returnUrl** wskazującą na host atakującego. Te informacje byłyby **przechowywane w ciasteczku (RU)**, a w **późniejszym kroku****prompt** zapyta **użytkownika**, czy chce dać dostęp do tego hosta atakującego.
Aby ominąć ten prompt, można było otworzyć kartę, aby zainicjować **przepływ OAuth**, który ustawiałby to ciasteczko RU, używając **returnUrl**, zamknąć kartę przed pokazaniem się promptu i otworzyć nową kartę bez tej wartości. Wtedy **prompt nie poinformuje o hoście atakującego**, ale ciasteczko zostanie ustawione na niego, więc **token zostanie wysłany do hosta atakującego** w przekierowaniu.
Dynamiczna Rejestracja Klienta w OAuth służy jako mniej oczywisty, ale krytyczny wektor podatności na bezpieczeństwo, w szczególności dla ataków **Server-Side Request Forgery (SSRF)**. Ten punkt końcowy pozwala serwerom OAuth otrzymywać szczegóły dotyczące aplikacji klienta, w tym wrażliwe adresy URL, które mogą być wykorzystane.
- **Dynamiczna Rejestracja Klienta** jest często mapowana na `/register` i akceptuje szczegóły takie jak `client_name`, `client_secret`, `redirect_uris` oraz adresy URL do logotypów lub zestawów kluczy JSON Web Key (JWKs) za pomocą żądań POST.
- Ta funkcja przestrzega specyfikacji określonych w **RFC7591** i **OpenID Connect Registration 1.0**, które obejmują parametry potencjalnie podatne na SSRF.
- **`logo_uri`**: Adres URL logotypu aplikacji klienta, który może być pobrany przez serwer, wywołują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 w przypadku złośliwego opracowania może spowodować, że serwer wyśle żądania do serwera kontrolowanego przez atakującego.
- **`sector_identifier_uri`**: Odwołuje się do tablicy JSON `redirect_uris`, którą serwer może pobrać, tworząc okazję do SSRF.
- **`request_uris`**: Wylicza dozwolone adresy URI żądań dla klienta, które mogą być wykorzystane, jeśli serwer pobiera te adresy URI na początku procesu autoryzacji.
**Strategia Wykorzystania:**
- SSRF może zostać wywołane poprzez zarejestrowanie nowego klienta z złośliwymi adresami URL w parametrach takich jak `logo_uri`, `jwks_uri` lub `sector_identifier_uri`.
- Podczas gdy bezpośrednie wykorzystanie poprzez `request_uris` może być ograniczone przez kontrole białej listy, dostarczenie wcześniej zarejestrowanego, kontrolowanego przez atakującego `request_uri` może ułatwić SSRF podczas fazy autoryzacji.
## Wyścig dostawców OAuth
Jeśli platforma, którą testujesz, jest dostawcą OAuth, [**przeczytaj to, aby przetestować możliwe wyścigi**](race-condition.md).
<summary><strong>Naucz się hakować AWS od zfszero do bohatera z</strong><ahref="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ź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **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.
