<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
OAuth bied verskeie weergawes, met fundamentele insigte beskikbaar by [OAuth 2.0-dokumentasie](https://oauth.net/2/). Hierdie bespreking fokus hoofsaaklik op die wyd gebruikte [OAuth 2.0-oorspronklike toestemmingstipe](https://oauth.net/2/grant-types/authorization-code/), wat 'n **toestemmingsraamwerk bied wat 'n aansoek in staat stel om toegang te verkry tot of aksies uit te voer op 'n gebruiker se rekening in 'n ander aansoek** (die toestemmingsdiens).
Beskou 'n hipotetiese webwerf _**https://voorbeeld.com**_, ontwerp om **al jou sosiale media plasings ten toon te stel**, insluitend privaat een. Om dit te bereik, word OAuth 2.0 gebruik. _https://voorbeeld.com_ sal jou toestemming vra om **toegang tot jou sosiale media plasings** te verkry. Gevolglik sal 'n toestemmingskerm op _https://sosialemedia.com_ verskyn wat die **toestemmings wat versoek word en die ontwikkelaar wat die versoek maak** uiteensit. Na jou toestemming kry _https://voorbeeld.com_ die vermoë om **namens jou toegang tot jou plasings te verkry**.
Dit is noodsaaklik om die volgende komponente binne die OAuth 2.0-raamwerk te verstaan:
- **hulpbron-eienaar**: Jy, as die **gebruiker/entiteit**, gee toestemming vir toegang tot jou hulpbron, soos jou sosiale media-rekeningplasings.
- **hulpbronbediener**: Die **bediener wat geauthentiseerde versoek stuur** nadat die aansoek 'n `toegangstoken` namens die `hulpbron-eienaar` verkry het, bv. **https://sosialemedia.com**.
- **kliëntaansoek**: Die **aansoek wat toestemming soek** van die `hulpbron-eienaar`, soos **https://voorbeeld.com**.
- **toestemmingsdiens**: Die **bediener wat `toegangstokens` uitreik** aan die `kliëntaansoek` na die suksesvolle outentifisering van die `hulpbron-eienaar` en die verkryging van toestemming, bv. **https://sosialemedia.com**.
- **kliënt\_id**: 'n Openbare, unieke identifiseerder vir die aansoek.
- **kliëntgeheim:** 'n vertroulike sleutel, slegs bekend aan die aansoek en die toestemmingsdiens, wat gebruik word vir die genereer van `toegangstokens`.
- **response\_type**: 'n waarde wat **die tipe token wat versoek word, spesifiseer**, soos `code`.
- **scope**: Die **vlak van toegang** wat die `kliëntaansoek` van die `hulpbron-eienaar` versoek.
- **redirect\_uri**: Die **URL waarna die gebruiker na toestemming omgelei word**. Dit moet tipies ooreenstem met die vooraf geregistreerde omleidings-URL.
- **state**: 'n parameter om **data oor die gebruiker se omleiding na en van die toestemmingsdiens te behou**. Sy uniekheid is krities vir die diens as 'n **CSRF-beskermingsmeganisme**.
- **grant\_type**: 'n parameter wat **die toestemmingstipe en die tipe token wat teruggegee moet word, aandui**.
- **code**: Die toestemmingskode van die `toestemmingsdiens`, wat saam met `kliënt_id` en `kliëntgeheim` deur die kliëntaansoek gebruik word om 'n `toegangstoken` te bekom.
- **toegangstoken**: Die **token wat die kliëntaansoek gebruik vir API-versoeke** namens die `hulpbron-eienaar`.
- **ververs\_token**: Maak dit vir die aansoek moontlik om 'n nuwe `toegangstoken` te **verkry sonder om die gebruiker weer te versoek**.
1. Jy navigeer na [https://voorbeeld.com](https://voorbeeld.com) en kies die "Integreer met Sosiale Media" knoppie.
2. Die webwerf stuur dan 'n versoek na [https://sosialemedia.com](https://sosialemedia.com) om jou toestemming te vra om https://voorbeeld.com se aansoek toegang tot jou plasings te gee. Die versoek is gestruktureer as:
5. https://example.com maak gebruik van hierdie `code`, saam met sy `client_id` en `client_secret`, om 'n serverkant versoek te maak om 'n `access_token` namens jou te verkry, wat toegang gee tot die toestemmings wat jy ingestem het:
Die `redirect_uri` is noodsaaklik vir sekuriteit in OAuth en OpenID-implementasies, aangesien dit aandui waar sensetiewe data, soos magtigingskodes, na magtiging gestuur word. Indien verkeerd gekonfigureer, kan dit aanvallers moontlik maak om hierdie versoek na skadelike bedieners om te lei, wat rekening-oorneem moontlik maak.
Uitbuitingstegnieke wissel gebaseer op die valideringslogika van die magtigingbediener. Dit kan wissel van streng pad-passing tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Gewone uitbuitingsmetodes sluit oop omleidings, padtraversering, die uitbuiting van swak regexe, en HTML-inspuiting vir token-diefstal in.
Benewens `redirect_uri` is ander OAuth- en OpenID-parameters soos `client_uri`, `policy_uri`, `tos_uri`, en `initiate_login_uri` ook vatbaar vir omleidingsaanvalle. Hierdie parameters is opsioneel en hul ondersteuning wissel tussen bedieners.
Vir diegene wat 'n OpenID-bediener teiken, lys die ontdekkings-eindpunt (`**.well-known/openid-configuration**`) dikwels waardevolle konfigurasiebesonderhede soos `registration_endpoint`, `request_uri_parameter_supported`, en "`require_request_uri_registration`. Hierdie besonderhede kan help om die registrasie-eindpunt en ander konfigurasiespesifieke van die bediener te identifiseer.
Soos genoem in hierdie foutvindingsverslag [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) is dit moontlik dat die omleidings-URL in die respons van die bediener na die gebruiker se verifikasie **weerspieël word**, wat **vatbaar vir XSS** is. Moontlike lading om te toets:
In OAuth-implementasies kan die misbruik of weglaat van die **`state` parameter** die risiko van **Cross-Site Request Forgery (CSRF)**-aanvalle aansienlik verhoog. Hierdie kwesbaarheid ontstaan wanneer die `state` parameter óf **nie gebruik word nie, as 'n statiese waarde gebruik word, of nie behoorlik gevalideer word nie**, wat aanvallers in staat stel om CSRF-beskerming te omseil.
Aanvallers kan hierdie kwesbaarheid uitbuit deur die magtigingsproses te onderskep om hul rekening met 'n slagoffer se rekening te skakel, wat kan lei tot potensiële **rekening-oorneemings**. Dit is veral krities in toepassings waar OAuth gebruik word vir **verifikasiedoeleindes**.
Regte-wêreld voorbeelde van hierdie kwesbaarheid is gedokumenteer in verskeie **CTF-uitdagings** en **hakplatforms**, wat die praktiese implikasies daarvan beklemtoon. Die probleem strek ook tot integrasies met derdeparty dienste soos **Slack**, **Stripe**, en **PayPal**, waar aanvallers kennisgewings of betalings na hul rekeninge kan omskakel.
1.**Sonner E-posverifikasie by Rekening Skepping**: Aanvallers kan voortydig 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derdepartydiens vir aanmelding gebruik, kan die aansoek per ongeluk hierdie derdeparty-rekening aan die aanvaller se voorgeskepte rekening koppel, wat tot ongemagtigde toegang kan lei.
2.**Uitbuiting van Laks OAuth E-posverifikasie**: Aanvallers kan OAuth-dienste uitbuit wat nie e-posse verifieer deur met hul diens te registreer en dan die rekening se e-pos na die slagoffer se e-pos te verander. Hierdie metode loop soortgelyk risiko van ongemagtigde rekeningtoegang, soortgelyk aan die eerste scenario, maar deur 'n ander aanvalvektor.
Die identifisering en beskerming van geheime OAuth parameters is noodsaaklik. Terwyl die **`client_id`** veilig bekendgemaak kan word, stel die bekendmaking van die **`client_secret`** aansienlike risiko's. As die `client_secret` gekompromitteer word, kan aanvallers die identiteit en vertroue van die aansoek uitbuit om gebruiker se `access_tokens` en privaat inligting te **steel**.
'n Algemene kwesbaarheid ontstaan wanneer aansoeke die uitruil van die magtigings `code` vir 'n `access_token` aan die kliëntkant hanteer in plaas van die bedienerkant. Hierdie fout lei tot die blootstelling van die `client_secret`, wat aanvallers in staat stel om `access_tokens` onder die skyn van die aansoek te genereer. Verder kan aanvallers deur sosiale manipulasie voorregte eskaleer deur addisionele omvang aan die OAuth-magtiging toe te voeg, wat die vertroude status van die aansoek verder uitbuit.
**[Kyk na hierdie pos](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)**
In hierdie foutvindingsverslag: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) kan jy sien dat die **teken** wat **AWS Cognito** aan die gebruiker teruggee, dalk **genoeg regte het om die gebruikersdata te oorskryf**. Daarom, as jy die **gebruiker se e-pos vir 'n ander gebruiker se e-pos kan verander**, kan jy dalk **ander rekeninge oorneem**.
Soos [**vermeld in hierdie uiteensetting**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), kan OAuth-vloeiwyses wat verwag om die **token** (en nie 'n kode) te ontvang, kwesbaar wees as hulle nie nagaan of die token aan die program behoort nie.
Dit is omdat 'n **aanvaller** 'n **toepassing wat OAuth ondersteun en met Facebook inlog** (byvoorbeeld) in sy eie toepassing kan skep. Dan, sodra 'n slagoffer met Facebook in die **aanvaller se toepassing** inlog, kan die aanvaller die **OAuth-token van die gebruiker wat aan sy toepassing gegee is, kry en dit gebruik om in te log in die slagoffer se OAuth-toepassing deur die slagoffer se gebruikerstoken**.
Daarom, as die aanvaller daarin slaag om die gebruiker sy eie OAuth-toepassing te laat gebruik, sal hy in staat wees om die slagoffer se rekening in toepassings oor te neem wat 'n token verwag en nie nagaan of die token aan hul program-ID toegeken is nie.
Volgens [**hierdie uiteensetting**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), was dit moontlik om 'n slagoffer 'n bladsy met 'n **returnUrl** wat na die aanvaller se gasheer wys, te laat oopmaak. Hierdie inligting sou in 'n koekie (RU) **gestoor word** en in 'n **later stap** sal die **prompt** die **gebruiker vra** of hy toegang wil gee aan daardie aanvaller se gasheer.
Om hierdie prompt te omseil, was dit moontlik om 'n lus te open om die **Oauth-vloei** te begin wat hierdie RU-koekie met die **returnUrl** sou instel, die lus te sluit voordat die prompt vertoon word, en 'n nuwe lus sonder daardie waarde te open. Dan sal die **prompt nie oor die aanvaller se gasheer inlig nie**, maar die koekie sal daaraan gestel word, sodat die **token na die aanvaller se gasheer gestuur sal word** in die omleiding.
Dinamiese Kliëntregistrasie in OAuth dien as 'n minder voor die hand liggende maar kritieke vektor vir sekuriteitskwessies, spesifiek vir **Server-Side Request Forgery (SSRF)**-aanvalle. Hierdie eindpunt laat OAuth-bedieners toe om besonderhede oor kliënttoepassings te ontvang, insluitend sensitiewe URL's wat uitgebuit kan word.
- **Dinamiese Kliëntregistrasie** word dikwels gekarteer na `/register` en aanvaar besonderhede soos `client_name`, `client_secret`, `redirect_uris`, en URL's vir logo's of JSON Web Key Sets (JWKs) via POST-versoeke.
- Hierdie kenmerk voldoen aan spesifikasies wat uiteengesit is in **RFC7591** en **OpenID Connect Registration 1.0**, wat parameters insluit wat potensieel vatbaar is vir SSRF.
- Die registrasieproses kan bedieners onbedoeld blootstel aan SSRF op verskeie maniere:
- **`logo_uri`**: 'n URL vir die kliënttoepassing se logo wat deur die bediener opgehaal kan word, wat SSRF kan veroorsaak of tot XSS kan lei as die URL verkeerd hanteer word.
- **`jwks_uri`**: 'n URL na die kliënt se JWK-dokument, wat indien booswillig saamgestel, die bediener kan dwing om uitgaande versoeke na 'n aanvallerbeheerde bediener te maak.
- **`sector_identifier_uri`**: Verwys na 'n JSON-reeks van `redirect_uris`, wat die bediener kan ophaal, wat 'n SSRF-geleentheid kan skep.
- **`request_uris`**: Lys toegelate versoek-URL's vir die kliënt, wat uitgebuit kan word as die bediener hierdie URL's aan die begin van die magtigingsproses ophaal.
- SSRF kan geaktiveer word deur 'n nuwe kliënt met booswillige URL's in parameters soos `logo_uri`, `jwks_uri`, of `sector_identifier_uri` te registreer.
- Terwyl direkte uitbuiting via `request_uris` gematig kan word deur witlysbeheer, kan die voorsiening van 'n voorafgeregistreerde, aanvallerbeheerde `request_uri` SSRF tydens die magtigingsfase fasiliteer.
<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
