<summary><strong>Dowiedz się, jak hakować 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ź [**SUBSCRIPTION PLANS**](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) github repos.
OAuth oferuje różne wersje, a podstawowe informacje są dostępne w [dokumentacji OAuth 2.0](https://oauth.net/2/). Niniejsza dyskusja skupia się głównie na powszechnie stosowanym typie autoryzacji [OAuth 2.0 - kod autoryzacyjny](https://oauth.net/2/grant-types/authorization-code/), który zapewnia **ramy autoryzacji, umożliwiające aplikacji dostęp lub wykonywanie działań na koncie użytkownika w innej aplikacji** (serwer autoryzacji).
Rozważmy hipotetyczną witrynę _**https://example.com**_, która ma na celu **prezentację wszystkich Twoich postów w mediach społecznościowych**, w tym prywatnych. W tym celu wykorzystywany jest OAuth 2.0. _https://example.com_ poprosi o zgodę na **dostęp do Twoich postów w mediach społecznościowych**. W rezultacie na _https://socialmedia.com_ pojawi się ekran zgody, na którym będą przedstawione **uprawnienia, które są żądane, oraz deweloper, który składa żądanie**. Po udzieleniu autoryzacji _https://example.com_ uzyskuje możliwość **dostępu do Twoich postów w Twoim imieniu**.
- **właściciel zasobu**: Ty, jako **użytkownik/entitet**, autoryzujesz dostęp do swojego zasobu, takiego jak posty na koncie w 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 ubiega się o autoryzację** od `właściciela zasobu`, np. **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**.
- **client\_secret:** Tajny klucz, znany tylko aplikacji i serwerowi autoryzacji, używany do generowania `tokenów dostępu`.
- **response\_type**: Wartość określająca **typ żądanego tokenu**, np. `code`.
- **scope**: **Poziom dostępu**, który `aplikacja klienta` żąda od `właściciela zasobu`.
- **redirect\_uri**: **Adres URL, na który użytkownik zostanie przekierowany po autoryzacji**. Zazwyczaj musi być zgodny z wcześniej zarejestrowanym adresem URL przekierowania.
- **state**: Parametr służący do **przekazywania danych między przekierowaniem użytkownika a serwerem autoryzacji**. Jego unikalność jest istotna dla zapewnienia **ochrony przed CSRF**.
- **grant\_type**: Parametr wskazujący **typ autoryzacji i typ żądanego tokenu**.
- **code**: Kod autoryzacji z `serwera autoryzacji`, używany w połączeniu z `client_id` i `client_secret` przez aplikację klienta do uzyskania `tokena dostępu`.
- **access\_token**: **Token, który aplikacja klienta używa do żądań API** w imieniu `właściciela zasobu`.
- **refresh\_token**: Umożliwia aplikacji **uzyskanie nowego `tokena dostępu` bez ponownego pytania użytkownika**.
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 autoryzację dostępu aplikacji https://example.com do Twoich postów. Żądanie jest zbudowane w następujący sposób:
5. https://example.com wykorzystuje ten `code`, wraz z `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 używa twojego `access_token` do wykonania wywołania API do Social Media w celu uzyskania dostępu.
`redirect_uri` jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ kieruje, gdzie wysyłane są wrażliwe dane, takie jak kody autoryzacji, po autoryzacji. Jeśli jest źle skonfigurowany, 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 autoryzacji. Mogą obejmować odporne dopasowanie ścieżki, akceptowanie dowolnego adresu URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, przechodzenie ścieżek, wykorzystywanie słabych wyrażeń regularnych i 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 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), możliwe jest, że **URL przekierowania jest odbijany w odpowiedzi** serwera po uwierzytelnieniu użytkownika, co czyni go **podatnym na XSS**. Możliwy ładunek do przetestowania:
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 albo **nie używany, używany jako wartość statyczna, albo nieprawidłowo sprawdzany**, co umożliwia atakującym obejście zabezpieczeń 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 w celach **uwierzytelniania**.
Przykłady tej podatności w świecie rzeczywistym zostały udokumentowane w różnych **wyzwaniach CTF** i **platformach do hakowania**, co podkreśla 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ą przekierowywać powiadomienia lub płatności na swoje konta.
1.**Bez weryfikacji adresu e-mail podczas tworzenia konta**: Atakujący mogą wcześniej 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 e-mail 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 naraża na nieautoryzowany dostęp do konta, podobnie jak w pierwszym scenariuszu, ale za pomocą innego wektora ataku.
Identyfikacja i ochrona tajnych parametrów OAuth jest kluczowa. Podczas gdy **`client_id`** można bezpiecznie ujawnić, ujawnienie **`client_secret`** niesie ze sobą znaczne ryzyko. Jeśli `client_secret` zostanie kompromitowany, atakujący mogą wykorzystać tożsamość i zaufanie aplikacji, aby **ukraść `access_tokeny`** i prywatne informacje.
Powszechną podatnością jest niewłaściwe obsługiwane wymiany 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_tokenów` pod przykrywką aplikacji. Ponadto, za pomocą inżynierii społecznej, atakujący mogą eskalować uprawnienia, dodając dodatkowe zakresy do autoryzacji OAuth, dalsze wykorzystując zaufane statusu 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 raporcie z programu bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) można 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 **tokenu** (a nie kodu), mogą być podatne, jeśli nie sprawdzają, czy token należy do aplikacji.
Dzieje się tak dlatego, że **atakujący** może stworzyć **aplikację obsługującą OAuth i zalogować się za pomocą Facebooka** (na przykład) w swojej własnej aplikacji. Następnie, gdy ofiara zaloguje się za pomocą Facebooka w **aplikacji atakującego**, atakujący może uzyskać **token OAuth użytkownika przekazany do swojej aplikacji i użyć go do zalogowania się w aplikacji OAuth ofiary, używając tokenu użytkownika ofiary**.
Dlatego jeśli atakujący zdoła skłonić użytkownika do udostępnienia dostępu 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ł przyznany 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 zmuszenie ofiary do otwarcia strony z **returnUrl**, wskazującą na host atakującego. Te informacje były **przechowywane w pliku cookie (RU)**, a w **kolejnym kroku****okno dialogowe** pytało **użytkownika**, czy chce udzielić dostępu temu hostowi atakującego.
Aby ominąć to okno dialogowe, można było otworzyć kartę, aby rozpocząć **przepływ OAuth**, który ustawiałby to plik cookie RU za pomocą **returnUrl**, zamknąć kartę przed wyświetleniem okna dialogowego i otworzyć nową kartę bez tej wartości. Wtedy **okno dialogowe nie informowałoby o hostu atakującego**, ale plik cookie byłby do niego ustawiony, więc **token zostanie wysłany do hosta atakującego** w przekierowaniu.
Dynamiczna rejestracja klienta w OAuth stanowi mniej oczywisty, ale krytyczny wektor podatności na bezpieczeństwo, zwłaszcza dla ataków typu **Server-Side Request Forgery (SSRF)**. Ten punkt końcowy umożliwia serwerom OAuth otrzymywanie informacji na temat aplikacji klienta, w tym wrażliwych adresów 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 dla logotypów lub zestawów kluczy JSON Web (JWKs) za pomocą żądań POST.
- Ta funkcja przestrzega specyfikacji określonej w **RFC7591** i **OpenID Connect Registration 1.0**, która obejmuje parametry podatne na SSRF.
- Proces rejestracji może nieumyślnie narazić serwery na SSRF na kilka sposobów:
- **`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 nieprawidłowo 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óre serwer może pobrać, tworząc możliwość SSRF.
- **`request_uris`**: Wylicza dozwolone adresy URL żądań dla klienta, które mogą być wykorzystane, jeśli serwer pobiera te adresy URL na początku procesu autoryzacji.
- 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`.
- Chociaż bezpośrednie wykorzystanie za pomocą `request_uris` może być ograniczone przez kontrolę listy białej, dostarczenie wcześniej zarejestrowanego, kontrolowanego przez atakującego `request_uri` może ułatwić SSRF podczas fazy autoryzacji.
