Translated ['pentesting-web/oauth-to-account-takeover.md'] to pl

2025-02-02 23:33:27 +00:00 · 2024-07-18 11:48:12 +00:00 · 2024-07-18 11:48:12 +00:00 · 2a72e12925
commit 2a72e12925
parent 5ce7e6e4cd
1 changed files with 106 additions and 95 deletions
--- a/pentesting-web/oauth-to-account-takeover.md
+++ b/pentesting-web/oauth-to-account-takeover.md
@ -1,16 +1,16 @@
-# OAuth do przejęcia konta
+# OAuth to Account takeover

 <details>

-<summary><strong>Nauka hakowania 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>
+<summary><strong>Naucz się hackingu 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ź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
+* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w PDF** Sprawdź [**PLANY 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.
+* Odkryj [**The PEASS Family**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
+* **Podziel się swoimi trikami hakerskimi, przesyłając PR do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.

 </details>

@ -18,36 +18,35 @@ Inne sposoby wsparcia HackTricks:

 {% embed url="https://websec.nl/" %}

-
 ## Podstawowe informacje <a href="#d4a8" id="d4a8"></a>

-OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi na stronie [dokumentacji OAuth 2.0](https://oauth.net/2/). Ta dyskusja koncentruje się głównie na powszechnie używanym [typie udzielenia 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).
+OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi w [OAuth 2.0 documentation](https://oauth.net/2/). Ta dyskusja koncentruje się głównie na szeroko stosowanym [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), zapewniającym **ramy autoryzacji, które umożliwiają 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 autoryzacji, _https://example.com_ uzyskuje możliwość **dostępu do twoich postów w twoim imieniu**.
+Rozważmy hipotetyczną stronę _**https://example.com**_, zaprojektowaną do **prezentowania wszystkich Twoich postów w mediach społecznościowych**, w tym prywatnych. Aby to osiągnąć, stosowany jest 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 **uprawnienia, o które się prosi, oraz dewelopera składającego prośbę**. Po Twojej autoryzacji, _https://example.com_ zyska możliwość **dostępu do Twoich postów w Twoim imieniu**.

-Należy zrozumieć następujące komponenty w ramach frameworka OAuth 2.0:
+Ważne jest, aby zrozumieć następujące komponenty w ramach OAuth 2.0:

- **właściciel zasobu**: Ty, jako **użytkownik/encja**, autoryzujesz dostęp do swojego zasobu, takiego jak twoje 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 **żądająca 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**.
- **client\_id**: Publiczny, unikalny identyfikator aplikacji.
- **client\_secret:** Poufny klucz, znany wyłącznie 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**: **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 udzielenia 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`.
- **refresh\_token**: Umożliwia aplikacji **uzyskanie nowego `tokena dostępu` bez ponownego pytania użytkownika**.
+* **resource owner**: Ty, jako **użytkownik/podmiot**, autoryzujesz dostęp do swojego zasobu, np. postów na koncie w mediach społecznościowych.
+* **resource server**: **Serwer zarządzający uwierzytelnionymi żądaniami** po tym, jak aplikacja uzyska `access token` w imieniu `resource owner`, np. **https://socialmedia.com**.
+* **client application**: **Aplikacja ubiegająca się o autoryzację** od `resource owner`, taka jak **https://example.com**.
+* **authorization server**: **Serwer, który wydaje `access tokens`** do `client application` po pomyślnym uwierzytelnieniu `resource owner` i uzyskaniu autoryzacji, np. **https://socialmedia.com**.
+* **client\_id**: Publiczny, unikalny identyfikator aplikacji.
+* **client\_secret:** Poufny klucz, znany tylko aplikacji i serwerowi autoryzacji, używany do generowania `access_tokens`.
+* **response\_type**: Wartość określająca **typ żądanego tokena**, np. `code`.
+* **scope**: **Poziom dostępu**, o który ubiega się `client application` od `resource owner`.
+* **redirect\_uri**: **URL, na który użytkownik jest przekierowywany po autoryzacji**. Zazwyczaj musi być zgodny z wcześniej zarejestrowanym URL przekierowania.
+* **state**: Parametr do **utrzymania danych podczas przekierowania użytkownika do i z serwera autoryzacji**. Jego unikalność jest kluczowa dla pełnienia funkcji **mechanizmu ochrony przed CSRF**.
+* **grant\_type**: Parametr wskazujący **typ grantu i typ tokena, który ma zostać zwrócony**.
+* **code**: Kod autoryzacyjny z `authorization server`, używany w połączeniu z `client_id` i `client_secret` przez aplikację kliencką do uzyskania `access_token`.
+* **access\_token**: **Token, którego aplikacja kliencka używa do żądań API** w imieniu `resource owner`.
+* **refresh\_token**: Umożliwia aplikacji **uzyskanie nowego `access_token` bez ponownego pytania użytkownika**.

-### Przepływ
+### Przebieg

-**Rzeczywisty przepływ OAuth** przebiega następująco:
+**Rzeczywisty przebieg OAuth** wygląda następująco:

-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:
+1. Przechodzisz na [https://example.com](https://example.com) i wybierasz przycisk „Integrate with Social Media”.
+2. Strona wysyła żądanie do [https://socialmedia.com](https://socialmedia.com) prosząc o Twoją autoryzację, aby aplikacja https://example.com mogła uzyskać dostęp do Twoich postów. Żądanie jest skonstruowane jako:
 ```
 https://socialmedia.com/auth
 ?response_type=code
@ -56,64 +55,64 @@ https://socialmedia.com/auth
 &scope=readPosts
 &state=randomString123
 ```
-3. Następnie zostajesz poproszony o zgodę na dostęp.
-
-4. Po udzieleniu zgody, Media Społecznościowe wysyła odpowiedź do `redirect_uri` z parametrami `code` i `state`:
+3. Następnie zostanie wyświetlona strona zgody.
+4. Po zatwierdzeniu, Social Media wysyła odpowiedź do `redirect_uri` z parametrami `code` i `state`:
 ```
 https://example.com?code=uniqueCode123&state=randomString123
 ```
-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ę:
+5. https://example.com wykorzystuje ten `code`, razem z `client_id` i `client_secret`, aby wykonać żądanie po stronie serwera w celu uzyskania `access_token` w Twoim imieniu, umożliwiając dostęp do uprawnień, na które wyraziłeś zgodę:
 ```
 POST /oauth/access_token
 Host: socialmedia.com
 ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
 ```
-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
+```markdown
+6. Finally, the process concludes as https://example.com employs your `access_token` to make an API call to Social Media to access

-## Vulnerabilities <a href="#323a" id="323a"></a>
+## Vulnerabilities <a href="#id-323a" id="id-323a"></a>

-### Otwarte przekierowanie\_uri <a href="#cc36" id="cc36"></a>
+### Open redirect\_uri <a href="#cc36" id="cc36"></a>

-`redirect_uri` jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ określa, gdzie po autoryzacji są wysyłane wrażliwe dane, takie jak kody autoryzacyjne. 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.
+`redirect_uri` jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ kieruje, gdzie wysyłane są wrażliwe dane, takie jak kody autoryzacyjne, po autoryzacji. Jeśli jest źle skonfigurowany, może pozwolić atakującym na przekierowanie tych żądań na złośliwe serwery, 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 tokenów.
+Techniki eksploatacji różnią się w zależności od logiki walidacji serwera autoryzacyjnego. Mogą obejmować od ścisłego dopasowania ścieżki do akceptowania dowolnego URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, przejścia ś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.
+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 i 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 konfiguracji, takie jak `registration_endpoint`, `request_uri_parameter_supported` i "`require_request_uri_registration`. Te szczegóły mogą pomóc zidentyfikować punkt końcowy rejestracji i inne konkretne konfiguracje serwera.
+Dla tych, którzy celują w serwer OpenID, punkt 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 rejestracji i innych specyfikacji konfiguracyjnych serwera.

-### XSS w implementacji przekierowania <a href="#bda5" id="bda5"></a>
+### XSS in redirect implementation <a href="#bda5" id="bda5"></a>

-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:
+Jak wspomniano w tym raporcie o 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że być możliwe, że **URL przekierowania jest odzwierciedlany w odpowiedzi** serwera po uwierzytelnieniu użytkownika, będąc **podatnym na XSS**. Możliwy ładunek do testowania:
+```
 ```
 https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
 ```
-### CSRF - Niewłaściwe obchodzenie parametru stanu <a href="#bda5" id="bda5"></a>
+### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>

-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 podatność 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.
+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 wartość statyczna lub nie jest odpowiednio walidowany**, co pozwala atakującym na 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 do celów **uwierzytelniania**.
+Atakujący mogą to wykorzystać, przechwytując proces autoryzacji, aby połączyć swoje konto z kontem ofiary, co może prowadzić do potencjalnych **przejęć 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.
+Przykłady tej podatności w rzeczywistych sytuacjach zostały udokumentowane w różnych **wyzwaniach CTF** i **platformach hakerskich**, co podkreśla jej praktyczne implikacje. Problem ten dotyczy również integracji z usługami zewnętrznymi, takimi jak **Slack**, **Stripe** i **PayPal**, gdzie atakujący mogą przekierowywać powiadomienia lub płatności na swoje konta.

-Prawidłowe obchodzenie i weryfikacja parametru **`state`** są kluczowe dla ochrony przed CSRF i zabezpieczenia przepływu OAuth.
+Prawidłowe obsługiwanie i walidacja **parametru `state`** są kluczowe dla ochrony przed CSRF i zabezpieczenia przepływu OAuth.

-### Przed Przejęciem Konta <a href="#ebe4" id="ebe4"></a>
+### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>

-1. **Bez Weryfikacji Emaila podczas Tworzenia Konta**: Atakujący mogą uprzednio utworzyć konto, używając emaila 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.
+1. **Bez weryfikacji e-maila przy tworzeniu konta**: Atakujący mogą z wyprzedzeniem utworzyć konto, używając e-maila ofiary. Jeśli ofiara później użyje usługi zewnętrznej do logowania, aplikacja może nieumyślnie połączyć to konto zewnętrzne z wcześniej utworzonym kontem atakującego, prowadząc 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 e-mail konta na e-mail ofiary. Ta metoda podobnie ryzykuje nieautoryzowany dostęp do konta, podobnie jak w pierwszym scenariuszu, ale przez inny wektor ataku.

-2. **Wykorzystanie Luźnej Weryfikacji Emaili w OAuth**: Atakujący mogą wykorzystać usługi OAuth, które nie weryfikują emaili, rejestrując się w ich usłudze, a następnie zmieniając email konta na email ofiary. Ta metoda podobnie niesie ryzyko nieautoryzowanego dostępu do konta, podobnie jak w pierwszym scenariuszu, ale poprzez inny wektor ataku.
+### Disclosure of Secrets <a href="#e177" id="e177"></a>

-### Ujawnienie Sekretów <a href="#e177" id="e177"></a>
+Identyfikacja i ochrona tajnych parametrów OAuth jest kluczowa. Podczas gdy **`client_id`** może być bezpiecznie ujawniony, ujawnienie **`client_secret`** niesie ze sobą znaczące ryzyko. Jeśli `client_secret` zostanie skompromitowany, 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 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.
+Częstą podatnością jest sytuacja, gdy aplikacje błędnie obsługują wymianę kodu autoryzacyjnego (`code`) 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 pozorem aplikacji. Ponadto, poprzez inżynierię społeczną, atakujący mogą eskalować uprawnienia, dodając dodatkowe zakresy do autoryzacji OAuth, jeszcze bardziej wykorzystując zaufany status aplikacji.

-Powszechna podatność pojawia się, 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.
+### Client Secret Bruteforce

-### Bruteforce Sekretu Klienta
-
-Możesz spróbować **przeprowadzić atak bruteforce na client\_secret** dostawcy usług z dostawcą tożsamości, aby próbować kraść konta.\
-Żądanie do BF może wyglądać podobnie jak:
+Możesz spróbować **bruteforce client\_secret** dostawcy usług z dostawcą tożsamości, aby spróbować ukraść konta.\
+Żądanie do BF może wyglądać podobnie do:
 ```
 POST /token HTTP/1.1
 content-type: application/x-www-form-urlencoded
@ -123,29 +122,29 @@ Connection: close

 code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]
 ```
-### Referer Header wycieka Kod + Stan
+### Referer Header leaking Code + State

-Kiedy klient ma **kod i stan**, jeśli jest **odzwierciedlony w nagłówku Referer** podczas przeglądania innej strony, to jest podatny.
+Gdy klient ma **code i state**, jeśli są one **odzwierciedlone w nagłówku Referer** podczas przeglądania innej strony, to jest podatny.

-### Token dostępu przechowywany w historii przeglądarki
+### Access Token Stored in Browser History

-Przejdź do **historii przeglądarki i sprawdź, czy token dostępu jest tam zapisany**.
+Przejdź do **historii przeglądarki i sprawdź, czy access token jest tam zapisany**.

-### Wieczny kod autoryzacyjny
+### Everlasting Authorization Code

-Kod **autoryzacyjny powinien istnieć tylko przez pewien czas, aby ograniczyć okno czasowe, w którym atakujący może go ukraść i użyć**.
+**Authorization code powinien żyć tylko przez pewien czas, aby ograniczyć okno czasowe, w którym atakujący może go ukraść i użyć**.

-### Token autoryzacji/Odświeżania niezwiązany z klientem
+### Authorization/Refresh Token not bound to client

-Jeśli możesz uzyskać **kod autoryzacyjny i użyć go z innym klientem, to możesz przejąć inne konta**.
+Jeśli możesz uzyskać **authorization code i użyć go z innym klientem, możesz przejąć inne konta**.

-### Szczęśliwe ścieżki, XSS, Iframes & Post Messages do wycieku kodu & wartości stanu
+### Happy Paths, XSS, Iframes & Post Messages to leak code & state values

-**[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)**
+[**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)

 ### AWS Cognito <a href="#bda5" id="bda5"></a>

-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ąć** konta innych osób.
+W tym raporcie z 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ć email użytkownika na inny email**, możesz być w stanie **przejąć** inne konta.
 ```bash
 # Read info of the user
 aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
@ -162,71 +161,83 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
 ]
 }
 ```
-Dla bardziej szczegółowych informacji na temat nadużywania AWS Cognito sprawdź:
+Aby uzyskać bardziej szczegółowe informacje na temat wykorzystywania AWS Cognito, sprawdź:

 {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

-### Nadużywanie tokenów innych aplikacji <a href="#bda5" id="bda5"></a>
+### Wykorzystywanie tokenów innych aplikacji <a href="#bda5" id="bda5"></a>

-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.
+Jak [**wspomniano w tym artykule**](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, ponieważ **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**.
+Dzieje się tak, ponieważ **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 przyznany jego aplikacji i użyć go do zalogowania się w aplikacji OAuth ofiary, używając tokenu użytkownika ofiary**.

 {% hint style="danger" %}
-Dlatego jeśli atakujący zdoła namówić użytkownika do udzielenia 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ł udzielony dla ich identyfikatora aplikacji.
+Dlatego, jeśli atakujący zdoła skłonić użytkownika do uzyskania 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 ich ID aplikacji.
 {% endhint %}

-### Dwa linki i ciasteczko <a href="#bda5" id="bda5"></a>
+### Dwa linki i cookie <a href="#bda5" id="bda5"></a>

-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 udzielić dostępu do tego 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 skłonienie ofiary do otwarcia strony z **returnUrl** wskazującym na hosta atakującego. Ta informacja byłaby **przechowywana w cookie (RU)** i w **późniejszym kroku** **prompt** zapyta **użytkownika**, czy chce dać dostęp do hosta atakującego.

-Aby ominąć ten prompt, można było otworzyć kartę, aby zainicjować **przepływ OAuth**, który ustawiłby to ciasteczko RU, używając **returnUrl**, zamknąć kartę przed pokazaniem się promptu i otworzyć nową kartę bez tej wartości. Następnie **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.
+Aby ominąć ten prompt, możliwe było otwarcie karty, aby zainicjować **przepływ OAuth**, który ustawiłby to cookie RU za pomocą **returnUrl**, zamknięcie karty przed wyświetleniem promptu i otwarcie nowej karty bez tej wartości. Wtedy **prompt nie poinformuje o hoście atakującego**, ale cookie będzie ustawione na niego, więc **token zostanie wysłany do hosta atakującego** w przekierowaniu.
+
+### Ominię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ą na wskazanie parametru GET **`prompt`** jako None (**`&prompt=none`**), aby **zapobiec pytaniu użytkowników o potwierdzenie** danego dostępu w promptie na stronie, 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ł dostarczony w końcowym URL:
+
+* `response_mode=query` -> Kod jest dostarczany wewnątrz parametru GET: `?code=2397rf3gu93f`
+* `response_mode=fragment` -> Kod jest dostarczany wewnątrz parametru fragmentu URL `#code=2397rf3gu93f`
+* `response_mode=form_post` -> Kod jest dostarczany wewnątrz formularza POST z inputem o nazwie `code` i wartością
+* `response_mode=web_message` -> Kod jest wysyłany w wiadomości post: `window.opener.postMessage({"code": "asdasdasd...`

 ### Parametry SSRF <a href="#bda5" id="bda5"></a>

-**[Sprawdź tę analizę](https://portswigger.net/research/hidden-oauth-attack-vectors) dla dalszych szczegółów tej techniki.**
+[**Sprawdź to badanie**](https://portswigger.net/research/hidden-oauth-attack-vectors) **dla dalszych szczegółów tej techniki.**

-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 typu **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 w OAuth służy jako mniej oczywisty, ale krytyczny wektor dla luk bezpieczeństwa, szczególnie dla ataków **Server-Side Request Forgery (SSRF)**. Ten endpoint pozwala serwerom OAuth na odbieranie szczegółów dotyczących aplikacji klienckich, w tym wrażliwych 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 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.
- 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 zostać 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 sprawić, ż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.
+* **Dynamiczna rejestracja klienta** jest często mapowana na `/register` i akceptuje szczegóły takie jak `client_name`, `client_secret`, `redirect_uris` oraz URL dla logo lub JSON Web Key Sets (JWKs) 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`**: URL dla logo aplikacji klienckiej, który może być pobrany przez serwer, wywołując SSRF lub prowadząc do XSS, jeśli URL jest niewłaściwie obsługiwany.
+* **`jwks_uri`**: URL do dokumentu JWK klienta, który, jeśli jest złośliwie skonstruowany, może spowodować, że serwer wykona żądania wychodzące 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`**: Lista dozwolonych URI żądań dla klienta, które mogą być wykorzystane, jeśli serwer pobiera te URI na początku procesu autoryzacji.

 **Strategia eksploatacji:**

- 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ś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.
+* SSRF można wywołać, rejestrując nowego klienta z złośliwymi 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ścigowe dostawców OAuth
+## Warunki wyścigu dostawców OAuth

-Jeśli platforma, którą testujesz, jest dostawcą OAuth, [**przeczytaj to, aby przetestować możliwe warunki wyścigowe**](race-condition.md).
+Jeśli platforma, którą testujesz, jest dostawcą OAuth, [**przeczytaj to, aby przetestować możliwe warunki wyścigu**](race-condition.md).

-## Odnośniki
+## Referencje

 * [**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)

-
 <figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

 {% embed url="https://websec.nl/" %}

 <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>
+<summary><strong>Naucz się hakowania 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ź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
-* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
+* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w PDF** Sprawdź [**PLANY SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
+* Kup [**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.
+* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
+* **Podziel się swoimi trikami hakerskimi, przesyłając PR do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.

 </details>