mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
Translator
parent
d26b576b10
commit
429de45cac
@ -2,16 +2,14 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Nou dat ons die lys van bates van ons omvang gebou het, is dit tyd om te soek na 'n paar OSINT laaghangende vrugte.
|
||||
|
||||
### Platforms wat reeds na leaks gesoek het
|
||||
|
||||
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
|
||||
|
||||
### Api sleutels leaks in github
|
||||
### Gereedskap om geheime in git repos en lêerstelsels te vind
|
||||
|
||||
- [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
|
||||
- [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
|
||||
- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
|
||||
- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
|
||||
- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
|
||||
- [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
|
||||
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# OAuth na Rekening oorname
|
||||
# OAuth na Rekening oorneem
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
OAuth bied verskeie weergawes, met fundamentele insigte beskikbaar by [OAuth 2.0 dokumentasie](https://oauth.net/2/). Hierdie bespreking fokus hoofsaaklik op die algemeen gebruikte [OAuth 2.0 magtigingskode toekennings tipe](https://oauth.net/2/grant-types/authorization-code/), wat 'n **magtigingsraamwerk bied wat 'n toepassing in staat stel om toegang te verkry of aksies op 'n gebruiker se rekening in 'n ander toepassing uit te voer** (die magtigingsbediener).
|
||||
|
||||
Dink aan 'n hipotetiese webwerf _**https://example.com**_, ontwerp om **al jou sosiale media plasings te vertoon**, insluitend privaat ones. Om dit te bereik, word OAuth 2.0 gebruik. _https://example.com_ sal jou toestemming vra om **toegang tot jou sosiale media plasings** te verkry. Gevolglik sal 'n toestemming skerm verskyn op _https://socialmedia.com_, wat die **toestemmings wat aangevra word en die ontwikkelaar wat die aanvraag doen** uiteensit. Na jou magtiging, verkry _https://example.com_ die vermoë om **jou plasings namens jou te benader**.
|
||||
Dink aan 'n hipotetiese webwerf _**https://example.com**_, ontwerp om **al jou sosiale media plasings te vertoon**, insluitend privaat ones. Om dit te bereik, word OAuth 2.0 gebruik. _https://example.com_ sal jou toestemming vra om **toegang tot jou sosiale media plasings** te verkry. Gevolglik sal 'n toestemming skerm verskyn op _https://socialmedia.com_, wat die **toestemmings wat aangevra word en die ontwikkelaar wat die versoek doen** uiteensit. Na jou magtiging, verkry _https://example.com_ die vermoë om **toegang tot jou plasings namens jou** te verkry.
|
||||
|
||||
Dit is noodsaaklik om die volgende komponente binne die OAuth 2.0 raamwerk te verstaan:
|
||||
|
||||
@ -30,7 +30,7 @@ Dit is noodsaaklik om die volgende komponente binne die OAuth 2.0 raamwerk te ve
|
||||
Die **werklike OAuth stroom** verloop soos volg:
|
||||
|
||||
1. Jy navigeer na [https://example.com](https://example.com) en kies die “Integreer met Sosiale Media” knoppie.
|
||||
2. Die webwerf stuur dan 'n versoek na [https://socialmedia.com](https://socialmedia.com) om jou magtiging te vra om die toepassing van https://example.com toegang tot jou plasings te gee. Die versoek is gestruktureer as:
|
||||
2. Die webwerf stuur dan 'n versoek na [https://socialmedia.com](https://socialmedia.com) om jou magtiging te vra om https://example.com se toepassing toegang tot jou plasings te gee. Die versoek is gestruktureer as:
|
||||
```
|
||||
https://socialmedia.com/auth
|
||||
?response_type=code
|
||||
@ -39,8 +39,8 @@ https://socialmedia.com/auth
|
||||
&scope=readPosts
|
||||
&state=randomString123
|
||||
```
|
||||
3. Jy word dan met 'n toestemmingsbladsy voorgelê.
|
||||
4. Na jou goedkeuring, stuur Sosiale Media 'n antwoord na die `redirect_uri` met die `code` en `state` parameters:
|
||||
3. Jy word dan met 'n toestemmingsbladsy voorgestel.
|
||||
4. Na jou goedkeuring, stuur Social Media 'n antwoord na die `redirect_uri` met die `code` en `state` parameters:
|
||||
```
|
||||
https://example.com?code=uniqueCode123&state=randomString123
|
||||
```
|
||||
@ -58,38 +58,38 @@ Host: socialmedia.com
|
||||
|
||||
Die `redirect_uri` is van kardinale belang vir sekuriteit in OAuth en OpenID implementasies, aangesien dit aandui waar sensitiewe data, soos magtigingskode, gestuur word na magtiging. As dit verkeerd geconfigureer is, kan dit aanvallers toelaat om hierdie versoeke na kwaadwillige bedieners te herlei, wat rekening oorname moontlik maak.
|
||||
|
||||
Eksploitasiemetodes verskil op grond van die magtigingsbediener se valideringslogika. Dit kan wissel van streng pad ooreenstemming tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Algemene eksploitasiemetodes sluit open redirects, pad traversering, die benutting van swak regexes, en HTML-inspuiting vir token-diefstal in.
|
||||
Eksploitasiemetodes verskil op grond van die validasielogika van die magtigingsbediener. Dit kan wissel van streng pad ooreenstemming tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Algemene eksploitasie metodes sluit open redirects, pad traversering, die benutting van swak regexes, 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 kwesbaar vir herleidingaanvalle. Hierdie parameters is opsioneel en hul ondersteuning verskil oor bedieners.
|
||||
Benewens `redirect_uri`, is ander OAuth en OpenID parameters soos `client_uri`, `policy_uri`, `tos_uri`, en `initiate_login_uri` ook kwesbaar vir herleiding aanvalle. Hierdie parameters is opsioneel en hul ondersteuning verskil oor bedieners.
|
||||
|
||||
Vir diegene wat 'n OpenID-bediener teiken, lys die ontdekking eindpunt (`**.well-known/openid-configuration**`) dikwels waardevolle konfigurasiedetails 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.
|
||||
Vir diegene wat 'n OpenID-bediener teiken, lys die ontdekking eindpunt (`**.well-known/openid-configuration**`) dikwels waardevolle konfigurasiedetails 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.
|
||||
|
||||
### XSS in redirect implementasie <a href="#bda5" id="bda5"></a>
|
||||
### XSS in herleiding implementasie <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Soos genoem in hierdie bug bounty verslag [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) mag dit moontlik wees dat die redirect **URL in die antwoord** van die bediener na die gebruiker se outentisering **reflekteer**, wat **kwesbaar is vir XSS**. Moglike payload om te toets:
|
||||
Soos genoem in hierdie bug bounty verslag [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) mag dit moontlik wees dat die herleiding **URL in die antwoord** van die bediener weerspieël word nadat die gebruiker geverifieer is, wat **kwesbaar is vir XSS**. Moglike payload om te toets:
|
||||
```
|
||||
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
|
||||
```
|
||||
### CSRF - Onbehoorlike hantering van die staat parameter <a href="#bda5" id="bda5"></a>
|
||||
|
||||
In OAuth implementasies kan die misbruik of omissie van die **`state` parameter** die risiko van **Cross-Site Request Forgery (CSRF)** aanvalle aansienlik verhoog. Hierdie kwesbaarheid ontstaan wanneer die `state` parameter **nie gebruik, as 'n statiese waarde gebruik, of nie behoorlik geverifieer** word nie, wat dit aanvallers moontlik maak om CSRF beskerming te omseil.
|
||||
In OAuth implementasies kan die misbruik of omissie van die **`state` parameter** die risiko van **Cross-Site Request Forgery (CSRF)** aanvalle aansienlik verhoog. Hierdie kwesbaarheid ontstaan wanneer die `state` parameter **nie gebruik word, as 'n statiese waarde gebruik word, of nie behoorlik geverifieer of geassosieer word met die gebruikersessie** tydens aanmelding nie, wat dit aanvallers moontlik maak om CSRF beskerming te omseil.
|
||||
|
||||
Aanvallers kan dit benut deur die magtiging proses te onderskep om hul rekening met 'n slagoffer se rekening te koppel, wat kan lei tot potensiële **rekening oorname**. Dit is veral krities in toepassings waar OAuth vir **authentikasie doeleindes** gebruik word.
|
||||
Aanvallers kan dit benut deur die magtiging proses te onderskep om hul rekening met 'n slagoffer se rekening te koppel, wat kan lei tot potensiële **rekening oorname** deur 'n gebruiker te laat aanmeld met 'n byna voltooide oauth vloei wat aan die aanvaller behoort. Dit is veral krities in toepassings waar OAuth gebruik word vir **authentikasie doeleindes**.
|
||||
|
||||
Werklike voorbeelde van hierdie kwesbaarheid is gedokumenteer in verskeie **CTF uitdagings** en **hacking platforms**, 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 herlei.
|
||||
Werklike voorbeelde van hierdie kwesbaarheid is gedokumenteer in verskeie **CTF uitdagings** en **hacking platforms**, wat die praktiese implikasies daarvan uitlig. Die probleem strek ook tot integrasies met derdeparty dienste soos **Slack**, **Stripe**, en **PayPal**, waar aanvallers kennisgewings of betalings na hul rekeninge kan herlei.
|
||||
|
||||
Behoorlike hantering en verifikasie van die **`state` parameter** is van kardinale belang om teen CSRF te beskerm en die OAuth vloei te beveilig.
|
||||
|
||||
### Voor Rekening Oorname <a href="#ebe4" id="ebe4"></a>
|
||||
|
||||
1. **Sonder E-pos Verifikasie by Rekening Skep**: Aanvallers kan proaktief 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derdeparty diens vir aanmelding gebruik, kan die toepassing per ongeluk hierdie derdeparty rekening aan die aanvaller se vooraf geskepte rekening koppel, wat lei tot ongeoorloofde toegang.
|
||||
1. **Sonder E-pos Verifikasie by Rekening Skep**: Aanvallers kan proaktief 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derdeparty diens vir aanmelding gebruik, kan die toepassing per ongeluk hierdie derdeparty rekening aan die aanvaller se vooraf geskepte rekening koppel, wat tot ongeoorloofde toegang lei.
|
||||
2. **Misbruik van Los OAuth E-pos Verifikasie**: Aanvallers kan OAuth dienste misbruik wat nie e-posse verifieer nie deur met hul diens te registreer en dan die rekening e-pos na die slagoffer s'n te verander. Hierdie metode hou soortgelyke risiko's van ongeoorloofde rekening toegang in, soortgelyk aan die eerste scenario, maar deur 'n ander aanvalsvector.
|
||||
|
||||
### Onthulling van Geheime <a href="#e177" id="e177"></a>
|
||||
|
||||
Identifisering en beskerming van geheime OAuth parameters is van kardinale belang. Terwyl die **`client_id`** veilig onthul kan word, hou die onthulling van die **`client_secret`** aansienlike risiko's in. As die `client_secret` gecompromitteer word, kan aanvallers die identiteit en vertroue van die toepassing benut om **gebruikers `access_tokens`** en private inligting te **steel**.
|
||||
Identifisering en beskerming van geheime OAuth parameters is van kardinale belang. Terwyl die **`client_id`** veilig bekend gemaak kan word, hou die onthulling van die **`client_secret`** aansienlike risiko's in. As die `client_secret` gecompromitteer word, kan aanvallers die identiteit en vertroue van die toepassing benut om **gebruikers `access_tokens`** en private inligting te **steel**.
|
||||
|
||||
'n Algemene kwesbaarheid ontstaan wanneer toepassings per ongeluk die uitruil van die magtiging `code` vir 'n `access_token` aan die kliëntkant hanteer eerder as die bedienerkant. Hierdie fout lei tot die blootstelling van die `client_secret`, wat dit aanvallers moontlik maak om `access_tokens` onder die dekmantel van die toepassing te genereer. Boonop, deur sosiale ingenieurswese, kan aanvallers voorregte verhoog deur addisionele skope aan die OAuth magtiging toe te voeg, wat die toepassing se vertroude status verder benut.
|
||||
'n Algemene kwesbaarheid ontstaan wanneer toepassings per ongeluk die uitruil van die magtiging `code` vir 'n `access_token` aan die kliëntkant hanteer eerder as aan die bedienerkant. Hierdie fout lei tot die blootstelling van die `client_secret`, wat dit aanvallers moontlik maak om `access_tokens` onder die dekmantel van die toepassing te genereer. Boonop, deur sosiale ingenieurswese, kan aanvallers voorregte verhoog deur addisionele skope aan die OAuth magtiging toe te voeg, wat die toepassing se vertroude status verder benut.
|
||||
|
||||
### Kliënt Geheim Bruteforce
|
||||
|
||||
@ -104,29 +104,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 lek Code + State
|
||||
### Referer Header lek kode + staat
|
||||
|
||||
Sodra die kliënt die **code en state** het, as dit **binne die Referer header weerspieël word** wanneer hy na 'n ander bladsy blaai, dan is dit kwesbaar.
|
||||
Sodra die kliënt die **kode en staat** het, as dit **binne die Referer-header weerspieël word** wanneer hy na 'n ander bladsy blaai, dan is dit kwesbaar.
|
||||
|
||||
### Toegangstoken gestoor in Bladsygeskiedenis
|
||||
### Toegangsteken gestoor in blaargeskiedenis
|
||||
|
||||
Gaan na die **bladsygeskiedenis en kyk of die toegangstoken daarin gestoor is**.
|
||||
Gaan na die **blaargeskiedenis en kyk of die toegangsteken daar gestoor is**.
|
||||
|
||||
### Ewige Outeurskode
|
||||
|
||||
Die **auteurskode moet net vir 'n kort tydjie bestaan om die tydsvenster te beperk waarbinne 'n aanvaller dit kan steel en gebruik**.
|
||||
Die **outerskode moet net vir 'n kort tydjie bestaan om die tydsvenster te beperk waarbinne 'n aanvaller dit kan steel en gebruik**.
|
||||
|
||||
### Outeurs-/Herlaai Token nie aan kliënt gebind nie
|
||||
### Outeurs-/Herlaai Teken nie aan kliënt gebind nie
|
||||
|
||||
As jy die **auteurskode kan kry en dit met 'n ander kliënt kan gebruik, kan jy ander rekeninge oorneem**.
|
||||
As jy die **outerskode kan kry en dit met 'n ander kliënt kan gebruik, dan kan jy ander rekeninge oorneem**.
|
||||
|
||||
### Gelukkige Paaie, XSS, Iframes & Post Berigte om kode & state waardes te lek
|
||||
### Gelukkige Paaie, XSS, Iframes & Post Berigte om kode & staat waardes te lek
|
||||
|
||||
[**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)
|
||||
|
||||
### AWS Cognito <a href="#bda5" id="bda5"></a>
|
||||
|
||||
In hierdie foutbounty verslag: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) kan jy sien dat die **token** wat **AWS Cognito** aan die gebruiker teruggee, **voldoende regte mag hê om die gebruikersdata te oorskryf**. Daarom, as jy die **gebruikers e-pos vir 'n ander gebruikers e-pos kan verander**, mag jy in staat wees om **ander** rekeninge oor te neem.
|
||||
In hierdie bug bounty verslag: [**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, **voldoende regte mag hê om die gebruikersdata te oorskryf**. Daarom, as jy die **gebruikers e-pos vir 'n ander gebruikers e-pos kan verander**, mag jy in staat wees om **ander** rekeninge oor te neem.
|
||||
```bash
|
||||
# Read info of the user
|
||||
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
|
||||
@ -143,52 +143,52 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
|
||||
]
|
||||
}
|
||||
```
|
||||
Vir meer gedetailleerde inligting oor hoe om AWS cognito te misbruik, kyk:
|
||||
For more detailed info about how to abuse AWS cognito check:
|
||||
|
||||
{{#ref}}
|
||||
https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html
|
||||
{{#endref}}
|
||||
|
||||
### Misbruik van ander Apps tokens <a href="#bda5" id="bda5"></a>
|
||||
### Abusing other Apps tokens <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Soos [**genoem in hierdie skrywe**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth vloei wat verwag om die **token** (en nie 'n kode nie) te ontvang, kan kwesbaar wees as hulle nie nagaan dat die token aan die app behoort nie.
|
||||
|
||||
Dit is omdat 'n **aanvaller** 'n **aansoek wat OAuth ondersteun en met Facebook aanmeld** (byvoorbeeld) in sy eie aansoek kan skep. Dan, sodra 'n slagoffer met Facebook in die **aanvaller se aansoek** aanmeld, kan die aanvaller die **OAuth token van die gebruiker wat aan sy aansoek gegee is, verkry en dit gebruik om in die slagoffer se OAuth aansoek aan te meld met die slagoffer se gebruikers token**.
|
||||
Dit is omdat 'n **aanvaller** 'n **aansoek kan skep wat OAuth ondersteun en met Facebook kan aanmeld** (byvoorbeeld) in sy eie aansoek. Dan, sodra 'n slagoffer met Facebook in die **aanvaller se aansoek** aanmeld, kan die aanvaller die **OAuth token van die gebruiker wat aan sy aansoek gegee is, kry en dit gebruik om in die slagoffer se OAuth aansoek aan te meld met die slagoffer se gebruikers token**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Daarom, as die aanvaller daarin slaag om die gebruiker toegang te gee tot sy eie OAuth aansoek, sal hy in staat wees om die slagoffer se rekening in aansoeke wat 'n token verwag en nie nagaan of die token aan hul app ID toegeken is nie, oor te neem.
|
||||
> Daarom, as die aanvaller daarin slaag om die gebruiker toegang tot sy eie OAuth aansoek te gee, sal hy in staat wees om die slagoffer se rekening in aansoeke wat 'n token verwag en nie nagaan of die token aan hul app ID toegeken is nie, oor te neem.
|
||||
|
||||
### Twee skakels & koekie <a href="#bda5" id="bda5"></a>
|
||||
### Two links & cookie <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Volgens [**hierdie skrywe**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), was dit moontlik om 'n slagoffer 'n bladsy te laat oopmaak met 'n **returnUrl** wat na die aanvaller se gasheer wys. Hierdie inligting sou **in 'n koekie (RU)** gestoor word en in 'n **latere stap** sal die **prompt** die **gebruiker** vra of hy toegang wil gee tot daardie aanvaller se gasheer.
|
||||
Volgens [**hierdie skrywe**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), was dit moontlik om 'n slagoffer 'n bladsy te laat oopmaak met 'n **returnUrl** wat na die aanvaller se gasheer wys. Hierdie inligting sou **in 'n koekie (RU)** gestoor word en in 'n **latere stap** sal die **prompt** die **gebruiker** vra of hy toegang tot daardie aanvaller se gasheer wil gee.
|
||||
|
||||
Om hierdie prompt te omseil, was dit moontlik om 'n tab te open om die **Oauth vloei** te begin wat hierdie RU koekie met die **returnUrl** sou stel, die tab te sluit voordat die prompt vertoon word, en 'n nuwe tab te open sonder daardie waarde. Dan, die **prompt sal nie oor die aanvaller se gasheer inligting gee nie**, maar die koekie sal aan dit toegeken word, sodat die **token na die aanvaller se gasheer gestuur sal word** in die herleiding.
|
||||
Om hierdie prompt te omseil, was dit moontlik om 'n oortjie te open om die **Oauth vloei** te begin wat hierdie RU koekie met die **returnUrl** sou stel, die oortjie te sluit voordat die prompt vertoon word, en 'n nuwe oortjie te open sonder daardie waarde. Dan, die **prompt sal nie oor die aanvaller se gasheer inligting gee nie**, maar die koekie sou daartoe gestel word, sodat die **token na die aanvaller se gasheer gestuur sal word** in die herleiding.
|
||||
|
||||
### Prompt Interaksie Omseiling <a href="#bda5" id="bda5"></a>
|
||||
### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Soos verduidelik in [**hierdie video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), laat sommige OAuth implementasies toe om die **`prompt`** GET parameter as None (**`&prompt=none`**) aan te dui om **te voorkom dat gebruikers gevra word om die gegewe toegang in 'n prompt op die web te bevestig as hulle reeds in die platform aangemeld is**.
|
||||
Soos verduidelik in [**hierdie video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), laat sommige OAuth implementasies toe om die **`prompt`** GET parameter as None (**`&prompt=none`**) aan te dui om **te voorkom dat gebruikers gevra word om die gegewe toegang in 'n prompt op die web te bevestig as hulle reeds op die platform aangemeld is**.
|
||||
|
||||
### response_mode
|
||||
|
||||
Soos [**verduidelik in hierdie video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), mag dit moontlik wees om die parameter **`response_mode`** aan te dui om aan te dui waar jy wil hê die kode in die finale URL verskaf moet word:
|
||||
|
||||
- `response_mode=query` -> Die kode word binne 'n GET parameter verskaf: `?code=2397rf3gu93f`
|
||||
- `response_mode=fragment` -> Die kode word binne die URL fragment parameter `#code=2397rf3gu93f` verskaf
|
||||
- `response_mode=fragment` -> Die kode word binne die URL fragment parameter verskaf `#code=2397rf3gu93f`
|
||||
- `response_mode=form_post` -> Die kode word binne 'n POST vorm met 'n invoer genaamd `code` en die waarde verskaf
|
||||
- `response_mode=web_message` -> Die kode word in 'n pos boodskap gestuur: `window.opener.postMessage({"code": "asdasdasd...`
|
||||
|
||||
### OAuth ROPC vloei - 2 FA omseiling <a href="#b440" id="b440"></a>
|
||||
### OAuth ROPC flow - 2 FA bypass <a href="#b440" id="b440"></a>
|
||||
|
||||
Volgens [**hierdie blogpos**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), is dit 'n OAuth vloei wat toelaat om in OAuth aan te meld via **gebruikersnaam** en **wagwoord**. As 'n **token** met toegang tot al die aksies wat die gebruiker kan uitvoer tydens hierdie eenvoudige vloei teruggestuur word, dan is dit moontlik om 2FA met daardie token te omseil.
|
||||
|
||||
### ATO op webblad wat herlei op grond van oop herleiding na verwysing <a href="#bda5" id="bda5"></a>
|
||||
### ATO on web page redirecting based on open redirect to referrer <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Hierdie [**blogpos**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) bespreek hoe dit moontlik was om 'n **oop herleiding** na die waarde van die **verwysing** te misbruik om OAuth te misbruik vir ATO. Die aanval was:
|
||||
Hierdie [**blogpos**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) bespreek hoe dit moontlik was om 'n **open redirect** na die waarde van die **referrer** te misbruik om OAuth te misbruik vir ATO. Die aanval was:
|
||||
|
||||
1. Slagoffer toegang tot die aanvaller se webblad
|
||||
2. Die slagoffer open die kwaadwillige skakel en 'n opener begin die Google OAuth vloei met `response_type=id_token,code&prompt=none` as bykomende parameters met die **verwysing die aanvaller se webwerf**.
|
||||
3. In die opener, nadat die verskaffer die slagoffer goedgekeur het, stuur dit hulle terug na die waarde van die `redirect_uri` parameter (slagoffer web) met 30X kode wat steeds die aanvaller se webwerf in die verwysing hou.
|
||||
4. Die slagoffer **webwerf aktiveer die oop herleiding gebaseer op die verwysing** wat die slagoffer gebruiker na die aanvaller se webwerf herlei, aangesien die **`respose_type`** **`id_token,code`** was, sal die kode aan die aanvaller in die **fragment** van die URL gestuur word, wat hom in staat stel om die rekening van die gebruiker via Google op die slagoffer se webwerf oor te neem.
|
||||
2. Die slagoffer open die kwaadwillige skakel en 'n opener begin die Google OAuth vloei met `response_type=id_token,code&prompt=none` as addisionele parameters met die **referrer die aanvaller se webwerf**.
|
||||
3. In die opener, nadat die verskaffer die slagoffer goedgekeur het, stuur dit hulle terug na die waarde van die `redirect_uri` parameter (slagoffer web) met 'n 30X kode wat steeds die aanvaller se webwerf in die referer hou.
|
||||
4. Die slagoffer **webwerf aktiveer die open redirect gebaseer op die referrer** wat die slagoffer gebruiker na die aanvaller se webwerf herlei, aangesien die **`respose_type`** **`id_token,code`** was, sal die kode teruggestuur word na die aanvaller in die **fragment** van die URL wat hom in staat stel om die rekening van die gebruiker via Google op die slagoffer se webwerf oor te neem.
|
||||
|
||||
### SSRFs parameters <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -198,26 +198,48 @@ Dinamiese Kliënt Registrasie in OAuth dien as 'n minder voor die hand liggende
|
||||
|
||||
**Belangrike Punten:**
|
||||
|
||||
- **Dinamiese Kliënt Registrasie** word dikwels aan `/register` gekarteer 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.
|
||||
- **Dinamiese Kliënt Registrasie** word dikwels aan `/register` gekoppel 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 funksie voldoen aan spesifikasies uiteengesit in **RFC7591** en **OpenID Connect Registrasie 1.0**, wat parameters insluit wat moontlik kwesbaar is vir SSRF.
|
||||
- Die registrasieproses kan onbedoeld bedieners aan SSRF blootstel op verskeie maniere:
|
||||
- Die registrasieproses kan per ongeluk bedieners aan SSRF blootstel op verskeie maniere:
|
||||
- **`logo_uri`**: 'n URL vir die kliënt aansoek se logo wat deur die bediener opgevraag kan word, wat SSRF kan aktiveer of kan lei tot XSS as die URL verkeerd hanteer word.
|
||||
- **`jwks_uri`**: 'n URL na die kliënt se JWK dokument, wat, as dit kwaadwillig saamgestel is, die bediener kan dwing om uitgaande versoeke na 'n aanvaller-beheerde bediener te maak.
|
||||
- **`sector_identifier_uri`**: Verwys na 'n JSON-array van `redirect_uris`, wat die bediener mag opvra, wat 'n SSRF geleentheid skep.
|
||||
- **`request_uris`**: Lys toegelate versoek URI's vir die kliënt, wat misbruik kan word as die bediener hierdie URI's aan die begin van die outorisering proses opvra.
|
||||
|
||||
**Misbruik Strategie:**
|
||||
**Eksploitasiestategie:**
|
||||
|
||||
- SSRF kan geaktiveer word deur 'n nuwe kliënt met kwaadwillige URL's in parameters soos `logo_uri`, `jwks_uri`, of `sector_identifier_uri` te registreer.
|
||||
- Terwyl direkte misbruik via `request_uris` moontlik beperk kan word deur witlysbeheer, kan die verskaffing van 'n vooraf geregistreerde, aanvaller-beheerde `request_uri` SSRF gedurende die outorisering fase fasiliteer.
|
||||
- Terwyl direkte eksploitatie via `request_uris` moontlik beperk kan word deur witlysbeheer, kan die verskaffing van 'n vooraf geregistreerde, aanvaller-beheerde `request_uri` SSRF gedurende die outorisering fase fasiliteer.
|
||||
|
||||
## OAuth verskaffers Wedloop Toestande
|
||||
## OAuth providers Race Conditions
|
||||
|
||||
As die platform wat jy toets 'n OAuth verskaffer is [**lees dit om vir moontlike Wedloop Toestande te toets**](race-condition.md).
|
||||
As die platform wat jy toets 'n OAuth verskaffer is [**lees dit om vir moontlike Race Conditions te toets**](race-condition.md).
|
||||
|
||||
## Verwysings
|
||||
## Mutable Claims Attack
|
||||
|
||||
In OAuth identifiseer die sub veld 'n gebruiker uniek, maar sy formaat verskil volgens die Outorisering Bediener. Om gebruikersidentifikasie te standaardiseer, gebruik sommige kliënte e-pos of gebruikershandvatsels. Dit is egter riskant omdat:
|
||||
|
||||
- Sommige Outorisering Bedieners verseker nie dat hierdie eienskappe (soos e-pos) onveranderlik bly nie.
|
||||
- In sekere implementasies—soos **"Aanmeld met Microsoft"**—vertrou die kliënt op die e-pos veld, wat **deur die gebruiker in Entra ID beheer word** en nie geverifieer is nie.
|
||||
- 'n Aanvaller kan dit misbruik deur sy eie Azure AD-organisasie (bv. doyensectestorg) te skep en dit te gebruik om 'n Microsoft-aanmelding uit te voer.
|
||||
- Alhoewel die Object ID (gestoor in sub) onveranderlik en veilig is, kan die vertroue op 'n veranderlike e-pos veld 'n rekeningsoorname moontlik maak (byvoorbeeld, die oorname van 'n rekening soos victim@gmail.com).
|
||||
|
||||
## Client Confusion Attack
|
||||
|
||||
In 'n **Client Confusion Attack**, misluk 'n aansoek wat die OAuth Implicit Flow gebruik om te verifieer dat die finale toegangstoken spesifiek gegenereer is vir sy eie Kliënt ID. 'n Aanvaller stel 'n publieke webwerf op wat Google se OAuth Implicit Flow gebruik, en mislei duisende gebruikers om aan te meld en sodoende toegangstokens te versamel wat bedoel is vir die aanvaller se webwerf. As hierdie gebruikers ook rekeninge op 'n ander kwesbare webwerf het wat nie die token se Kliënt ID verifieer nie, kan die aanvaller die versamelde tokens hergebruik om die slagoffers na te doen en hul rekeninge oor te neem.
|
||||
|
||||
## Scope Upgrade Attack
|
||||
|
||||
Die **Authorization Code Grant** tipe behels veilige bediener-tot-bediener kommunikasie vir die oordrag van gebruikersdata. As die **Authorization Server** egter die scope parameter in die Toegangstoken Versoek (n parameter wat nie in die RFC gedefinieer is nie) implisiet vertrou, kan 'n kwaadwillige aansoek die bevoegdhede van 'n outorisering kode opgradeer deur 'n hoër scope aan te vra. Nadat die **Toegangstoken** gegenereer is, moet die **Hulpbronbediener** dit verifieer: vir JWT tokens behels dit die nagaan van die JWT handtekening en die onttrekking van data soos client_id en scope, terwyl vir random string tokens die bediener die Outorisering Bediener moet vra om die token se besonderhede te verkry.
|
||||
|
||||
## Redirect Scheme Hijacking
|
||||
|
||||
In mobiele OAuth implementasies gebruik aansoeke **custom URI schemes** om herleidings met Outorisering Kodes te ontvang. Omdat verskeie aansoeke dieselfde skema op 'n toestel kan registreer, word die aanname dat slegs die wettige kliënt die herleiding URI beheer, oortree. Op Android, byvoorbeeld, word 'n Intent URI soos `com.example.app://` oauth gevang op grond van die skema en opsionele filters wat in 'n aansoek se intent-filter gedefinieer is. Aangesien Android se intent resolusie breed kan wees—veral as slegs die skema gespesifiseer is—kan 'n aanvaller 'n kwaadwillige aansoek registreer met 'n sorgvuldig saamgestelde intent filter om die outorisering kode te kapen. Dit kan **'n rekeningsoorname moontlik maak** of deur gebruikersinteraksie (wanneer verskeie aansoeke in aanmerking kom om die intent te hanteer) of via omseil tegnieke wat oortollig spesifieke filters misbruik, soos uiteengesit deur Ostorlab se assesserings stroomdiagram.
|
||||
|
||||
## References
|
||||
|
||||
- [**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)
|
||||
- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -10,7 +10,7 @@ Afhangend van hoe die back-end/front-end optree wanneer dit **weird unicode kara
|
||||
|
||||
Unicode normalisering vind plaas wanneer **unicode karakters genormaliseer word na ascii karakters**.
|
||||
|
||||
Een algemene scenario van hierdie tipe kwesbaarheid gebeur wanneer die stelsel **die invoer** van die gebruiker **op 'n of ander manier aanpas** **nadat dit dit nagegaan het**. Byvoorbeeld, in sommige tale kan 'n eenvoudige oproep om die **invoer hoofletters of kleinletters te maak** die gegewe invoer normaliseer en die **unicode sal in ASCII omgeskakel word**, wat nuwe karakters genereer.\
|
||||
Een algemene scenario van hierdie tipe kwesbaarheid gebeur wanneer die stelsel **die invoer** van die gebruiker **op 'n of ander manier aanpas** **nadat dit nagegaan is**. Byvoorbeeld, in sommige tale kan 'n eenvoudige oproep om die **invoer hoofletters of kleinletters te maak** die gegewe invoer normaliseer en die **unicode sal in ASCII omgeskakel word**, wat nuwe karakters genereer.\
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
@ -20,7 +20,7 @@ unicode-normalization.md
|
||||
## `\u` na `%`
|
||||
|
||||
Unicode karakters word gewoonlik verteenwoordig met die **`\u` voorvoegsel**. Byvoorbeeld, die karakter `㱋` is `\u3c4b`([kyk dit hier](https://unicode-explorer.com/c/3c4B)). As 'n backend **die voorvoegsel** **`\u` in `%` omskakel**, sal die resulterende string `%3c4b` wees, wat URL-dekodeer is: **`<4b`**. En, soos jy kan sien, is 'n **`<` karakter ingespuit**.\
|
||||
Jy kan hierdie tegniek gebruik om **enige tipe karakter in te spuit** as die backend kwesbaar is.\
|
||||
Jy kan hierdie tegniek gebruik om **enige soort karakter in te spuit** as die backend kwesbaar is.\
|
||||
Kyk [https://unicode-explorer.com/](https://unicode-explorer.com/) om die karakters te vind wat jy nodig het.
|
||||
|
||||
Hierdie kwesbaarheid kom eintlik van 'n kwesbaarheid wat 'n navorser gevind het, vir 'n meer diepgaande verduideliking, kyk [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
|
||||
@ -29,7 +29,7 @@ Hierdie kwesbaarheid kom eintlik van 'n kwesbaarheid wat 'n navorser gevind het,
|
||||
|
||||
Back-ends gedra soms vreemd wanneer hulle **emojis ontvang**. Dit is wat gebeur het in [**hierdie skrywe**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) waar die navorser daarin geslaag het om 'n XSS te bereik met 'n payload soos: `💋img src=x onerror=alert(document.domain)//💛`
|
||||
|
||||
In hierdie geval was die fout dat die bediener, nadat dit die kwaadwillige karakters verwyder het, **die UTF-8 string van Windows-1252 na UTF-8 omgeskakel het** (basies het die invoer kodering en die omskakeling van kodering nie ooreengestem nie). Dan gee dit nie 'n behoorlike < nie, net 'n vreemde unicode een: `‹`\
|
||||
In hierdie geval was die fout dat die bediener, nadat dit die kwaadwillige karakters verwyder het, **die UTF-8 string van Windows-1252 na UTF-8 omgeskakel het** (basies het die invoer kodering en die omskakeling van kodering nie ooreengestem nie). Dit gee dan nie 'n behoorlike < nie, net 'n vreemde unicode een: `‹`\
|
||||
``So het hulle hierdie uitvoer geneem en **weer van UTF-8 na ASCII omgeskakel**. Dit het die `‹` na ` <` genormaliseer, dit is hoe die eksploit op daardie stelsel kon werk.\
|
||||
Dit is wat gebeur het:
|
||||
```php
|
||||
@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
|
||||
|
||||
echo "String: " . $str;
|
||||
```
|
||||
Emoji lys:
|
||||
Emoji-lists:
|
||||
|
||||
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
|
||||
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
|
||||
|
||||
## Windows Beste-Pas / Sleg-Pas
|
||||
|
||||
Soos verduidelik in **[hierdie wonderlike pos](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, het Windows 'n kenmerk genaamd **Beste-Pas** wat **unicode karakters** wat nie in ASCII-modus vertoon kan word nie, met 'n soortgelyke een sal vervang. Dit kan lei tot **onverwagte gedrag** wanneer die agterkant **'n spesifieke karakter** verwag, maar 'n ander een ontvang.
|
||||
|
||||
Dit is moontlik om beste-pas karakters te vind in **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
|
||||
|
||||
Aangesien Windows gewoonlik unicode strings na ascii strings omskakel as een van die laaste dele van die uitvoering (gewoonlik van 'n "W" agtervoegsel API na 'n "A" agtervoegsel API soos `GetEnvironmentVariableA` en `GetEnvironmentVariableW`), sal dit aanvallers in staat stel om beskermings te omseil deur unicode karakters te stuur wat laastens in ASCII karakters omgeskakel sal word wat onverwagte aksies sal uitvoer.
|
||||
|
||||
In die blogpos word voorgestelde metodes aangebied om kwesbaarhede te omseil wat reggestel is met 'n **swartlys van karakters**, om **pad traversals** te benut met [karakters wat na “/“ (0x2F) gekarteer is](https://worst.fit/mapping/#to%3A0x2f) en [karakters wat na “\“ (0x5C) gekarteer is](https://worst.fit/mapping/#to%3A0x5c) of selfs om shell escape beskermings soos PHP se `escapeshellarg` of Python se `subprocess.run` te omseil deur 'n lys te gebruik, dit is byvoorbeeld gedoen deur **volledige breedte dubbele aanhalings (U+FF02)** te gebruik in plaas van dubbele aanhalings, sodat wat aan die einde soos 1 argument gelyk het, in 2 argumente omgeskakel is.
|
||||
|
||||
**Let daarop dat vir 'n app kwesbaar te wees, dit "W" Windows APIs moet gebruik, maar uiteindelik 'n "A" Windows API moet aanroep sodat die "Beste-pas" van die unicode string geskep word.**
|
||||
|
||||
**Verskeie ontdekte kwesbaarhede sal nie reggestel word nie, aangesien mense nie saamstem wie hierdie probleem moet regstel nie.**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user