Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
OAuth inatoa toleo mbalimbali, huku maarifa ya msingi yanapatikana katika [OAuth 2.0 documentation](https://oauth.net/2/). Majadiliano haya yanazingatia hasa [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), ikitoa **mfumo wa ruhusa unaowezesha programu kufikia au kufanya vitendo kwenye akaunti ya mtumiaji katika programu nyingine** (seva ya ruhusa).
Fikiria tovuti ya mfano _**https://example.com**_, iliyoundwa ili **kuonyesha machapisho yako yote ya mitandao ya kijamii**, ikiwa ni pamoja na ya faragha. Ili kufanikisha hili, OAuth 2.0 inatumika. _https://example.com_ itahitaji ruhusa yako ili **kufikia machapisho yako ya mitandao ya kijamii**. Kwa hivyo, skrini ya idhini itaonekana kwenye _https://socialmedia.com_, ikielezea **ruhusa zinazohitajika na mtengenezaji anayefanya ombi**. Baada ya idhini yako, _https://example.com_ inapata uwezo wa **kufikia machapisho yako kwa niaba yako**.
* **mwenye rasilimali**: Wewe, kama **mtumiaji/kitengo**, unaruhusu ufikiaji wa rasilimali yako, kama vile machapisho ya akaunti yako ya mitandao ya kijamii.
* **seva ya rasilimali**: **seva inayosimamia maombi yaliyothibitishwa** baada ya programu kupata `access token` kwa niaba ya `mwenye rasilimali`, mfano, **https://socialmedia.com**.
* **programu ya mteja**: **programu inayotafuta ruhusa** kutoka kwa `mwenye rasilimali`, kama vile **https://example.com**.
* **seva ya ruhusa**: **seva inayotoa `access tokens`** kwa `programu ya mteja` baada ya uthibitisho wa mafanikio wa `mwenye rasilimali` na kupata ruhusa, mfano, **https://socialmedia.com**.
* **client\_id**: Kitambulisho cha umma, cha kipekee kwa programu.
* **client\_secret:** Funguo ya siri, inayojulikana tu kwa programu na seva ya ruhusa, inayotumika kwa ajili ya kuzalisha `access_tokens`.
* **response\_type**: Thamani inayobainisha **aina ya token inayohitajika**, kama `code`.
* **scope**: **ngazi ya ufikiaji** ambayo `programu ya mteja` inahitaji kutoka kwa `mwenye rasilimali`.
* **redirect\_uri**: **URL ambayo mtumiaji anarejeshwa baada ya ruhusa**. Hii kwa kawaida inapaswa kuendana na URL ya kuhamasisha iliyosajiliwa awali.
* **state**: Kigezo cha **kuhifadhi data wakati wa kuelekeza mtumiaji kwenda na kutoka kwa seva ya ruhusa**. Upekee wake ni muhimu kwa ajili ya kutumikia kama **mekanismu ya ulinzi wa CSRF**.
* **grant\_type**: Kigezo kinachoashiria **aina ya ruhusa na aina ya token itakayorejeshwa**.
* **code**: Kodu ya ruhusa kutoka kwa `seva ya ruhusa`, inayotumika pamoja na `client_id` na `client_secret` na programu ya mteja ili kupata `access_token`.
* **access\_token**: **token ambayo programu ya mteja inatumia kwa maombi ya API** kwa niaba ya `mwenye rasilimali`.
* **refresh\_token**: Inaruhusu programu **kupata `access_token` mpya bila kumlazimisha mtumiaji tena**.
### Flow
**mchakato halisi wa OAuth** unafanyika kama ifuatavyo:
2. Tovuti hiyo kisha inatuma ombi kwa [https://socialmedia.com](https://socialmedia.com) ikitaka ruhusa yako ili kuruhusu programu ya https://example.com kufikia machapisho yako. Ombi limeundwa kama:
5. https://example.com inatumia `code` hii, pamoja na `client_id` na `client_secret` yake, kufanya ombi la upande wa seva ili kupata `access_token` kwa niaba yako, ikiruhusu ufikiaji wa ruhusa ulizokubali:
`redirect_uri` ni muhimu kwa usalama katika utekelezaji wa OAuth na OpenID, kwani inaelekeza mahali ambapo data nyeti, kama vile misimbo ya idhini, inatumwa baada ya idhini. Ikiwa imewekwa vibaya, inaweza kuruhusu washambuliaji kuelekeza maombi haya kwa seva mbaya, na kuwezesha kuchukua akaunti.
Mbinu za unyakuzi zinatofautiana kulingana na mantiki ya uthibitishaji ya seva ya idhini. Zinweza kutofautiana kutoka kwa mechi kali ya njia hadi kukubali URL yoyote ndani ya kikoa au saraka iliyoainishwa. Mbinu za kawaida za unyakuzi ni pamoja na kuelekeza wazi, kupita njia, kutumia regex dhaifu, na kuingiza HTML kwa wizi wa token.
Mbali na `redirect_uri`, vigezo vingine vya OAuth na OpenID kama `client_uri`, `policy_uri`, `tos_uri`, na `initiate_login_uri` pia vinaweza kuathiriwa na mashambulizi ya kuelekeza. Vigezo hivi ni hiari na msaada wao unatofautiana kati ya seva.
Kwa wale wanaolenga seva ya OpenID, mwisho wa ugunduzi (`**.well-known/openid-configuration**`) mara nyingi huorodhesha maelezo muhimu ya usanidi kama `registration_endpoint`, `request_uri_parameter_supported`, na "`require_request_uri_registration`. Maelezo haya yanaweza kusaidia katika kubaini mwisho wa usajili na maelezo mengine ya usanidi wa seva.
Kama ilivyotajwa katika ripoti hii ya bug bounty [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) inaweza kuwa inawezekana kwamba **URL ya kuelekeza inajitokeza katika jibu** la seva baada ya mtumiaji kuthibitisha, ikiwa **vulnerable to XSS**. Payload inay posible kujaribu:
Katika utekelezaji wa OAuth, matumizi mabaya au kukosekana kwa **`state` parameter** kunaweza kuongeza hatari ya mashambulizi ya **Cross-Site Request Forgery (CSRF)** kwa kiasi kikubwa. Uthibitisho huu unatokea wakati **`state` parameter** haijatumiwa, imetumiwa kama thamani ya kudumu, au haijathibitishwa ipasavyo, ikiruhusu washambuliaji kupita ulinzi wa CSRF.
Washambuliaji wanaweza kutumia hii kwa kukamata mchakato wa uthibitisho ili kuunganisha akaunti yao na akaunti ya mwathirika, na kusababisha uwezekano wa **account takeovers**. Hii ni muhimu hasa katika programu ambapo OAuth inatumika kwa **authentication purposes**.
Mifano halisi ya udhaifu huu imeandikwa katika changamoto mbalimbali za **CTF** na **hacking platforms**, ikionyesha athari zake za vitendo. Tatizo hili pia linapanuka kwa ushirikiano na huduma za upande wa tatu kama **Slack**, **Stripe**, na **PayPal**, ambapo washambuliaji wanaweza kuelekeza arifa au malipo kwa akaunti zao.
1.**Bila Uthibitisho wa Barua Pepe kwenye Uundaji wa Akaunti**: Washambuliaji wanaweza kuunda akaunti kabla kwa kutumia barua pepe ya mwathirika. Ikiwa mwathirika baadaye anatumia huduma ya upande wa tatu kuingia, programu inaweza bila kukusudia kuunganisha akaunti hii ya upande wa tatu na akaunti iliyoundwa na mshambuliaji, na kusababisha ufikiaji usioidhinishwa.
2.**Kutatiza Uthibitisho wa Barua Pepe wa OAuth**: Washambuliaji wanaweza kutumia huduma za OAuth ambazo hazithibitishi barua pepe kwa kujiandikisha na huduma yao na kisha kubadilisha barua pepe ya akaunti kuwa ya mwathirika. Njia hii pia ina hatari ya ufikiaji usioidhinishwa wa akaunti, sawa na hali ya kwanza lakini kupitia njia tofauti ya shambulio.
Kutambua na kulinda vigezo vya siri vya OAuth ni muhimu. Ingawa **`client_id`** inaweza kufichuliwa kwa usalama, kufichua **`client_secret`** kuna hatari kubwa. Ikiwa **`client_secret`** itakabiliwa, washambuliaji wanaweza kutumia utambulisho na imani ya programu ili **kuiba `access_tokens` za mtumiaji** na taarifa binafsi.
Udhaifu wa kawaida unatokea wakati programu zinashughulikia kwa makosa kubadilishana `code` ya uthibitisho kwa `access_token` upande wa mteja badala ya upande wa seva. Makosa haya yanapelekea kufichuliwa kwa **`client_secret`**, ikiruhusu washambuliaji kuunda `access_tokens` chini ya kivuli cha programu. Zaidi ya hayo, kupitia uhandisi wa kijamii, washambuliaji wanaweza kuongeza mamlaka kwa kuongeza maeneo mengine kwenye uthibitisho wa OAuth, wakitumia zaidi hadhi ya kuaminika ya programu.
[**Check this 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)
Katika ripoti hii ya bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) unaweza kuona kwamba **token** ambayo **AWS Cognito** inarudisha kwa mtumiaji inaweza kuwa na **idhini za kutosha kubadilisha data za mtumiaji**. Hivyo, ikiwa unaweza **kubadilisha barua pepe ya mtumiaji kwa barua pepe tofauti ya mtumiaji**, unaweza kuwa na uwezo wa **kuchukua** akaunti za wengine.
Kama [**ilivyotajwa katika andiko hili**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), mchakato wa OAuth unaotarajia kupokea **token** (na si nambari) unaweza kuwa na hatari ikiwa hauhakiki kwamba token inamhusu programu.
Hii ni kwa sababu **mshambuliaji** anaweza kuunda **programu inayounga mkono OAuth na kuingia na Facebook** (kwa mfano) katika programu yake mwenyewe. Kisha, mara tu mwathirika anapoingia na Facebook katika **programu ya mshambuliaji**, mshambuliaji anaweza kupata **OAuth token ya mtumiaji iliyotolewa kwa programu yake, na kuitumia kuingia katika programu ya OAuth ya mwathirika kwa kutumia token ya mtumiaji wa mwathirika**.
Hivyo, ikiwa mshambuliaji atafanikiwa kumfanya mtumiaji aingie katika programu yake ya OAuth, ataweza kuchukua akaunti ya mwathirika katika programu zinazotarajia token na hazihakiki kama token ilitolewa kwa ID yao ya programu.
Kulingana na [**andiko hili**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), ilikuwa inawezekana kumfanya mwathirika afungue ukurasa wenye **returnUrl** unaoelekeza kwenye mwenyeji wa mshambuliaji. Taarifa hii ingekuwa **imehifadhiwa katika cookie (RU)** na katika **hatua ya baadaye****prompt** itakuwa **inauliza****mtumiaji** kama anataka kutoa ufikiaji kwa mwenyeji wa mshambuliaji.
Ili kupita prompt hii, ilikuwa inawezekana kufungua tab ili kuanzisha **Oauth flow** ambayo ingeiweka cookie hii ya RU kwa kutumia **returnUrl**, kufunga tab kabla ya prompt kuonyeshwa, na kufungua tab mpya bila thamani hiyo. Kisha, **prompt haitatoa taarifa kuhusu mwenyeji wa mshambuliaji**, lakini cookie itakuwa imewekwa kwake, hivyo **token itatumwa kwa mwenyeji wa mshambuliaji** katika uelekezaji.
Kama ilivyoelezwa katika [**video hii**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), baadhi ya utekelezaji wa OAuth huruhusu kuashiria **`prompt`** GET parameter kama None (**`&prompt=none`**) ili **kuzuia watumiaji kuulizwa kuthibitisha** ufikiaji uliopewa katika prompt kwenye wavuti ikiwa tayari wameingia kwenye jukwaa.
Kama [**ilivyoelezwa katika video hii**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), inaweza kuwa inawezekana kuashiria parameter **`response_mode`** kuonyesha unataka nambari ipatikane wapi katika URL ya mwisho:
Usajili wa Wateja wa Kijadi katika OAuth unatumika kama njia isiyo wazi lakini muhimu kwa udhaifu wa usalama, haswa kwa mashambulizi ya **Server-Side Request Forgery (SSRF)**. Kituo hiki kinawaruhusu seva za OAuth kupokea maelezo kuhusu programu za wateja, ikiwa ni pamoja na URLs nyeti ambazo zinaweza kutumika vibaya.
* **Usajili wa Wateja wa Kijadi** mara nyingi unahusishwa na `/register` na unakubali maelezo kama `client_name`, `client_secret`, `redirect_uris`, na URLs za nembo au Sets za JSON Web Key (JWKs) kupitia maombi ya POST.
* Kipengele hiki kinazingatia viwango vilivyowekwa katika **RFC7591** na **OpenID Connect Registration 1.0**, ambavyo vinajumuisha parameters zinazoweza kuwa na hatari kwa SSRF.
* Mchakato wa usajili unaweza bila kukusudia kufichua seva kwa SSRF kwa njia kadhaa:
* **`logo_uri`**: URL ya nembo ya programu ya mteja ambayo inaweza kupatikana na seva, ikisababisha SSRF au kupelekea XSS ikiwa URL itashughulikiwa vibaya.
* **`jwks_uri`**: URL ya hati ya JWK ya mteja, ambayo ikiwa imeundwa kwa njia mbaya, inaweza kusababisha seva kufanya maombi ya nje kwa seva inayodhibitiwa na mshambuliaji.
* **`sector_identifier_uri`**: Inarejelea orodha ya JSON ya `redirect_uris`, ambayo seva inaweza kufikia, ikileta fursa ya SSRF.
* **`request_uris`**: Inataja URIs za maombi zinazoruhusiwa kwa mteja, ambazo zinaweza kutumika vibaya ikiwa seva itapata URIs hizi mwanzoni mwa mchakato waidhinishaji.
* SSRF inaweza kuanzishwa kwa kujiandikisha mteja mpya na URLs mbaya katika parameters kama `logo_uri`, `jwks_uri`, au `sector_identifier_uri`.
* Ingawa matumizi ya moja kwa moja kupitia `request_uris` yanaweza kupunguziliwa mbali na udhibiti wa orodha ya ruhusa, kutoa `request_uri` iliyosajiliwa awali, inayodhibitiwa na mshambuliaji kunaweza kuwezesha SSRF wakati wa hatua ya uthibitishaji.
Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
