<summary><strong>Jifunze AWS hacking kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikionekana kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA USAJILI**](https://github.com/sponsors/carlospolop)!
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa kipekee wa [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Shiriki mbinu zako za udukuzi kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
OAuth inatoa toleo mbalimbali, na ufahamu wa msingi unapatikana kwenye [hati ya OAuth 2.0](https://oauth.net/2/). Mjadala huu unazingatia sana [aina ya idhini ya nambari ya utoaji wa OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), ikitoa **mtaala wa idhini unaowezesha programu kupata au kutekeleza vitendo kwenye akaunti ya mtumiaji kwenye programu nyingine** (seva ya idhini).
Fikiria tovuti ya dhana _**https://mfano.com**_, iliyoundwa kuonyesha **machapisho yako ya mitandao ya kijamii**, pamoja na yale ya faragha. Ili kufanikisha hili, OAuth 2.0 inatumika. _https://mfano.com_ itaomba idhini yako ya **kupata machapisho yako ya mitandao ya kijamii**. Kwa hivyo, skrini ya idhini itaonekana kwenye _https://mitandaojamii.com_, ikielezea **idhini inayotakiwa na mwandishi wa ombi**. Baada ya idhini yako, _https://mfano.com_ inapata uwezo wa **kupata machapisho yako kwa niaba yako**.
- **mmiliki wa rasilimali**: Wewe, kama **mtumiaji/kitu**, unaidhinisha upatikanaji wa rasilimali yako, kama machapisho ya akaunti yako ya mitandao ya kijamii.
- **seva ya rasilimali**: **Seva inayosimamia maombi yaliyothibitishwa** baada ya programu kupata `access token` kwa niaba ya `mmiliki wa rasilimali`, k.m., **https://mitandaojamii.com**.
- **programu ya mteja**: **Programu inayotafuta idhini** kutoka kwa `mmiliki wa rasilimali`, kama vile **https://mfano.com**.
- **seva ya idhini**: **Seva inayotoa `access token`** kwa `programu ya mteja` baada ya uthibitishaji mafanikio wa `mmiliki wa rasilimali` na kupata idhini, k.m., **https://mitandaojamii.com**.
- **client\_id**: Kitambulisho cha umma, cha kipekee kwa programu.
- **client\_secret:** Neno la siri, linalojulikana tu kwa programu na seva ya idhini, hutumiwa kuzalisha `access_tokens`.
- **response\_type**: Thamani inayoeleza **aina ya token inayotakiwa**, kama `code`.
- **redirect\_uri**: **URL ambayo mtumiaji anaelekezwa baada ya idhini**. Kawaida hii lazima ifanane na URL ya kuhamisha iliyosajiliwa mapema.
- **state**: Parameta ya **kuhifadhi data wakati wa kuhamisha mtumiaji kwenye na kutoka kwa seva ya idhini**. Upekee wake ni muhimu kama **muhimili wa ulinzi wa CSRF**.
- **code**: Nambari ya idhini kutoka kwa `seva ya idhini`, hutumiwa pamoja na `client_id` na `client_secret` na programu ya mteja kupata `access_token`.
1. Nenda kwenye [https://mfano.com](https://mfano.com) na chagua kitufe cha "Integrate with Social Media".
2. Tovuti hiyo kisha itatuma ombi kwa [https://mitandaojamii.com](https://mitandaojamii.com) kuomba idhini yako kuruhusu programu ya https://mfano.com kupata machapisho yako. Ombi hilo limeundwa kama:
5. https://example.com inatumia hii `code`, pamoja na `client_id` na `client_secret` yake, kufanya ombi upande wa server kupata `access_token` kwa niaba yako, kuruhusu ufikiaji wa ruhusa ulizoidhinisha:
`redirect_uri` ni muhimu kwa usalama katika OAuth na utekelezaji wa OpenID, kwani inaelekeza wapi data nyeti, kama nambari za idhini, zinatumwa baada ya idhini. Ikiwa imepangwa vibaya, inaweza kuruhusu wachawi kuuelekeza maombi haya kwa seva zenye nia mbaya, kuruhusu utekaji wa akaunti.
Mbinu za kutumia zinatofautiana kulingana na mantiki ya uthibitishaji wa seva ya idhini. Wanaweza kutofautiana kutoka kwa kulinganisha njia kwa umakini hadi kukubali URL yoyote ndani ya kikoa au folda iliyotajwa. Mbinu za kawaida za kutumia ni pamoja na uelekezaji wazi, upitishaji wa njia, kutumia regex dhaifu, na kuingiza HTML kwa wizi wa alama.
Mbali na `redirect_uri`, vigezo vingine vya OAuth na OpenID kama `client_uri`, `policy_uri`, `tos_uri`, na `initiate_login_uri` pia wanaweza kuwa hatarini kwa mashambulizi ya uelekezaji. Vigezo hivi sio lazima na msaada wao hutofautiana kati ya seva.
Kwa wale wanaolenga seva ya OpenID, kipande cha ugunduzi (`**.well-known/openid-configuration**`) mara nyingi hupata maelezo muhimu ya usanidi kama vile `registration_endpoint`, `request_uri_parameter_supported`, na "`require_request_uri_registration`. Maelezo haya yanaweza kusaidia katika kutambua kipande cha usajili na maelezo mengine ya usanidi wa seva.
Kama ilivyotajwa katika ripoti hii ya tuzo ya mdudu [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 uelekezaji inaonyeshwa katika majibu** ya seva baada ya mtumiaji kujithibitisha, ikiwa **inavuliwa kwa XSS**. Payload inayowezekana kwa majaribio:
Katika utekelezaji wa OAuth, matumizi mabaya au kutokuwepo kwa **parameter ya `state`** inaweza kuongeza hatari kubwa ya mashambulizi ya **Cross-Site Request Forgery (CSRF)**. Udhaifu huu unatokea wakati parameter ya `state` inatumika **kwa njia isiyo sahihi, kutumika kama thamani ya statiki, au kutokuwa na uthibitisho sahihi**, kuruhusu wachawi kupita kinga za CSRF.
Wachawi wanaweza kutumia hili kwa kuingilia mchakato wa idhini ili kuunganisha akaunti yao na akaunti ya muathiriwa, ikisababisha **uchukuzi wa akaunti**. Hii ni muhimu sana katika programu ambapo OAuth inatumika kwa **madhumuni ya uthibitisho**.
Mifano halisi ya udhaifu huu imerekodiwa katika changamoto mbalimbali za **CTF** na **majukwaa ya udukuzi**, ikionyesha athari zake za vitendo. Tatizo hili pia linahusiana na uingizaji wa huduma za tatu kama **Slack**, **Stripe**, na **PayPal**, ambapo wachawi wanaweza kuelekeza arifa au malipo kwa akaunti zao.
1.**Bila Uthibitishaji wa Barua pepe Wakati wa Uundaji wa Akaunti**: Wachawi wanaweza kuunda akaunti kwa kujitayarisha kwa kutumia barua pepe ya muathiriwa. Ikiwa muathiriwa baadaye anatumia huduma ya tatu kwa kuingia, programu inaweza kwa bahati mbaya kuunganisha akaunti hii ya tatu ya muathiriwa na akaunti iliyoundwa mapema ya mshambuliaji, ikisababisha ufikiaji usioidhinishwa.
2.**Kutumia Uthibitishaji wa Barua pepe wa Lax OAuth**: Wachawi wanaweza kutumia huduma za OAuth ambazo hazithibitishi barua pepe kwa kusajili na huduma yao na kisha kubadilisha barua pepe ya akaunti kuwa ya muathiriwa. Mbinu hii ina hatari sawa ya ufikiaji usioidhinishwa wa akaunti, kama kwenye kisa cha kwanza lakini kupitia vector tofauti wa shambulizi.
Kutambua na kulinda paramita za siri za OAuth ni muhimu. Ingawa **`client_id`** inaweza kufichuliwa salama, kufunua **`client_secret`** kunaweza kuleta hatari kubwa. Ikiwa `client_secret` itafichuliwa, wachawi wanaweza kutumia kitambulisho na imani ya programu kuiba **`access_tokens`** za watumiaji na habari za kibinafsi.
Udhaifu wa kawaida unatokea wakati programu zinashughulikia kwa makosa kubadilishana `code` ya idhini kwa `access_token` upande wa mteja badala ya upande wa seva. Kosa hili husababisha kufichuliwa kwa `client_secret`, kuruhusu wachawi kuzalisha `access_tokens` chini ya kivuli cha programu. Zaidi ya hayo, kupitia uhandisi wa kijamii, wachawi wanaweza kuongeza mamlaka kwa kuongeza skopesi zaidi kwa idhini ya OAuth, wakiendelea kutumia hadhi ya kuaminika ya programu.
Katika ripoti ya tuzo ya mdudu huyu: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) unaweza kuona kwamba **msimbo** ambao **AWS Cognito** inamrudishia mtumiaji huenda ukawa na **idhini za kutosha za kubadilisha data ya mtumiaji**. Kwa hivyo, ikiwa unaweza **kubadilisha barua pepe ya mtumiaji kwa barua pepe tofauti ya mtumiaji**, unaweza **kuchukua** akaunti za wengine.
Kama ilivyotajwa katika [**makala hii**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), Mifumo ya OAuth ambayo inatarajia kupokea **vibali** (na sio nambari) inaweza kuwa hatarini ikiwa haitathibitisha kuwa kibali kinamilikiwa na programu.
Hii ni kwa sababu **mshambuliaji** anaweza kuunda **programu inayounga mkono OAuth na kuingia kwa kutumia Facebook** (kwa mfano) katika programu yake mwenyewe. Kisha, mara tu muathiriwa anapoingia kwa kutumia Facebook katika **programu ya mshambuliaji**, mshambuliaji anaweza kupata **vibali vya OAuth vya mtumiaji vilivyotolewa kwa programu yake, na kuvitumia kuingia katika programu ya OAuth ya muathiriwa kwa kutumia kibali cha mtumiaji wa muathiriwa**.
Hivyo, ikiwa mshambuliaji anafanikiwa kupata mtumiaji kumruhusu kutumia programu yake ya OAuth, ataweza kuchukua udhibiti wa akaunti za waathiriwa katika programu ambazo zinatarajia kibali na hazithibitishi ikiwa kibali kilipewa kitambulisho cha programu yao.
Kulingana na [**makala hii**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), ilikuwa inawezekana kufanya muathiriwa afungue ukurasa na **returnUrl** inayoashiria kwenye mwenyeji wa mshambuliaji. Taarifa hii ingehifadhiwa katika kuki (RU) na katika **hatua inayofuata****prompt** itauliza **mtumiaji** ikiwa anataka kutoa ruhusa kwa mwenyeji huyo wa mshambuliaji.
Ili kuepuka prompt hii, ilikuwa inawezekana kufungua kichupo kuanzisha **mtiririko wa Oauth** ambao ungehakikisha kuki hii ya RU kwa kutumia **returnUrl**, kufunga kichupo kabla ya prompt kuonyeshwa, na kufungua kichupo kipya bila thamani hiyo. Kisha, **prompt haitaonyesha kuhusu mwenyeji wa mshambuliaji**, lakini kuki itahifadhiwa kwake, hivyo **kibali kitatumwa kwa mwenyeji wa mshambuliaji** katika uendeshaji.
Usajili wa Mteja wa Kudumu katika OAuth unatumika kama vector ya usalama usio wazi lakini muhimu kwa ajili ya udhaifu wa usalama, hasa kwa mashambulizi ya **Server-Side Request Forgery (SSRF)**. Kipengele hiki huruhusu seva za OAuth kupokea maelezo kuhusu programu za wateja, ikiwa ni pamoja na URL nyeti ambazo zinaweza kutumiwa vibaya.
- **Usajili wa Mteja wa Kudumu** mara nyingi unahusishwa na `/register` na hukubali maelezo kama vile `client_name`, `client_secret`, `redirect_uris`, na URLs kwa ajili ya nembo au Seti za Kijeti za JSON (JWKs) kupitia maombi ya POST.
- Kipengele hiki kinazingatia maelekezo yaliyowekwa katika **RFC7591** na **Usajili wa OpenID Connect 1.0**, ambayo ni pamoja na vigezo vinavyoweza kuwa hatarini kwa SSRF.
- Mchakato wa usajili unaweza kwa bahati mbaya kufunua seva kwa SSRF kwa njia kadhaa:
- **`logo_uri`**: URL kwa nembo ya programu ya mteja ambayo inaweza kupakuliwa na seva, ikichochea SSRF au kusababisha XSS ikiwa URL itashughulikiwa vibaya.
- **`jwks_uri`**: URL kwa hati ya JWK ya mteja, ambayo ikipangwa kwa udanganyifu, inaweza kusababisha seva kufanya maombi ya kutoka kwa seva inayodhibitiwa na mshambuliaji.
- **`request_uris`**: Inaorodhesha URIs zilizoruhusiwa za ombi kwa mteja, ambazo zinaweza kutumiwa vibaya ikiwa seva itapakua URIs hizi mwanzoni mwa mchakato wa idhini.
- Ingawa utekelezaji wa moja kwa moja kupitia `request_uris` unaweza kupunguzwa na udhibiti wa orodha nyeupe, kutoa `request_uri` iliyosajiliwa mapema, inayodhibitiwa na mshambuliaji, inaweza kurahisisha SSRF wakati wa hatua ya idhini.
<summary><strong>Jifunze kuhusu udukuzi wa AWS kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Pata [**bidhaa rasmi za PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) za kipekee
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Shiriki mbinu zako za udukuzi kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
