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:
parent
328a949626
commit
f0c60ddd53
@ -3,17 +3,13 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
Sasa kwamba tumeshajenga orodha ya mali za wigo wetu, ni wakati wa kutafuta matunda ya OSINT yaliyo rahisi kufikia.
|
||||
|
||||
### Majukwaa ambayo tayari yamefanya utafutaji wa leaks
|
||||
|
||||
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
|
||||
|
||||
### Mvuwa ya api keys katika github
|
||||
### Zana za kutafuta siri katika git repos na mfumo wa faili
|
||||
|
||||
- [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)
|
||||
|
||||
@ -4,33 +4,33 @@
|
||||
|
||||
## Basic Information <a href="#d4a8" id="d4a8"></a>
|
||||
|
||||
OAuth inatoa matoleo 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 idhini unaowezesha programu kufikia au kufanya vitendo kwenye akaunti ya mtumiaji katika programu nyingine** (seva ya idhini).
|
||||
OAuth inatoa matoleo 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 kufikirika _**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**.
|
||||
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**.
|
||||
|
||||
Ni muhimu kuelewa vipengele vifuatavyo ndani ya mfumo wa OAuth 2.0:
|
||||
|
||||
- **resource owner**: Wewe, kama **mtumiaji/kitengo**, unaruhusu ufikiaji wa rasilimali yako, kama vile machapisho ya akaunti yako ya mitandao ya kijamii.
|
||||
- **resource owner**: Wewe, kama **mtumiaji/kiungo**, unaruhusu ufikiaji wa rasilimali yako, kama vile machapisho ya akaunti yako ya mitandao ya kijamii.
|
||||
- **resource server**: **seva inayosimamia maombi yaliyothibitishwa** baada ya programu kupata `access token` kwa niaba ya `resource owner`, mfano, **https://socialmedia.com**.
|
||||
- **client application**: **programu inayotafuta idhini** kutoka kwa `resource owner`, kama vile **https://example.com**.
|
||||
- **authorization server**: **seva inayotoa `access tokens`** kwa `client application` baada ya uthibitisho wa mafanikio wa `resource owner` na kupata idhini, mfano, **https://socialmedia.com**.
|
||||
- **client application**: **programu inayotafuta ruhusa** kutoka kwa `resource owner`, kama **https://example.com**.
|
||||
- **authorization server**: **seva inayotoa `access tokens`** kwa `client application` baada ya uthibitisho wa mafanikio wa `resource owner` na kupata ruhusa, mfano, **https://socialmedia.com**.
|
||||
- **client_id**: Kitambulisho cha umma, cha kipekee kwa programu.
|
||||
- **client_secret:** Funguo ya siri, inayojulikana pekee kwa programu na seva ya idhini, inayotumika kwa ajili ya kuzalisha `access_tokens`.
|
||||
- **client_secret:** Funguo ya siri, inayojulikana pekee 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 `client application` inahitaji kutoka kwa `resource owner`.
|
||||
- **redirect_uri**: **URL ambayo mtumiaji anarejeshwa baada ya idhini**. Hii kwa kawaida inapaswa kuendana na URL ya kuhamasisha iliyosajiliwa awali.
|
||||
- **state**: Kigezo cha **kuhifadhi data wakati wa kuelekea na kurudi kwa mtumiaji kwenye seva ya idhini**. Upekee wake ni muhimu kwa ajili ya kutumikia kama **mekanismu ya ulinzi wa CSRF**.
|
||||
- **grant_type**: Kigezo kinachoashiria **aina ya grant na aina ya token itakayorejeshwa**.
|
||||
- **code**: Kodu ya idhini kutoka kwa `authorization server`, inayotumika pamoja na `client_id` na `client_secret` na `client application` ili kupata `access_token`.
|
||||
- **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 kurudi 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 `authorization server`, inayotumika pamoja na `client_id` na `client_secret` na `client application` ili kupata `access_token`.
|
||||
- **access_token**: **token ambayo `client application` inatumia kwa maombi ya API** kwa niaba ya `resource owner`.
|
||||
- **refresh_token**: Inaruhusu programu **kupata `access_token` mpya bila kumlazimisha mtumiaji tena**.
|
||||
|
||||
### Flow
|
||||
|
||||
**mchakato halisi wa OAuth** unafanyika kama ifuatavyo:
|
||||
**mchakato halisi wa OAuth** unaendelea kama ifuatavyo:
|
||||
|
||||
1. Unatembelea [https://example.com](https://example.com) na kuchagua kitufe cha “Integrate with Social Media”.
|
||||
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:
|
||||
2. Tovuti hiyo kisha inatuma ombi kwa [https://socialmedia.com](https://socialmedia.com) ikitafuta ruhusa yako ili kuruhusu programu ya https://example.com kufikia machapisho yako. Ombi limeundwa kama:
|
||||
```
|
||||
https://socialmedia.com/auth
|
||||
?response_type=code
|
||||
@ -56,40 +56,40 @@ Host: socialmedia.com
|
||||
|
||||
### Open redirect_uri <a href="#cc36" id="cc36"></a>
|
||||
|
||||
`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 kuchukuliwa kwa akaunti.
|
||||
`redirect_uri` ni muhimu kwa usalama katika utekelezaji wa OAuth na OpenID, kwani inaelekeza mahali ambapo data nyeti, kama vile nambari za idhini, zinatumwa baada ya idhini. Ikiwa imewekwa vibaya, inaweza kuruhusu washambuliaji kuelekeza maombi haya kwa seva mbaya, na kuwezesha kuchukuliwa kwa 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 eneo lililotajwa au saraka ndogo. Mbinu za kawaida za unyakuzi ni pamoja na redirects wazi, kupita njia, kutumia regex dhaifu, na kuingiza HTML kwa wizi wa token.
|
||||
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 eneo lililotajwa au saraka ndogo. Mbinu za kawaida za unyakuzi ni pamoja na mwelekeo 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.
|
||||
Mbali na `redirect_uri`, vigezo vingine vya OAuth na OpenID kama `client_uri`, `policy_uri`, `tos_uri`, na `initiate_login_uri` pia vinahatarishwa kwa mashambulizi ya mwelekeo. 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 vile `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 ya seva.
|
||||
Kwa wale wanaolenga seva ya OpenID, mwisho wa ugunduzi (`**.well-known/openid-configuration**`) mara nyingi huorodhesha maelezo muhimu ya usanidi kama vile `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.
|
||||
|
||||
### XSS katika utekelezaji wa kuelekeza <a href="#bda5" id="bda5"></a>
|
||||
### XSS katika utekelezaji wa mwelekeo <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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 **inaweza kuathiriwa na XSS**. Payload inay posible kujaribu:
|
||||
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 mwelekeo inarudishwa katika jibu** la seva baada ya mtumiaji kuthibitisha, ikiwa **hatarini kwa XSS**. Payload inay posible kujaribu:
|
||||
```
|
||||
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
|
||||
```
|
||||
### CSRF - Usimamizi mbaya wa parameter ya hali <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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.
|
||||
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 au kuhusishwa na kikao cha watumiaji wakati wa kuingia, ikiruhusu washambuliaji kupita ulinzi wa CSRF.
|
||||
|
||||
Washambuliaji wanaweza kutumia hii kwa kukamata mchakato wa uthibitishaji ili kuunganisha akaunti yao na akaunti ya mwathirika, na kusababisha uwezekano wa **uchukuaji wa akaunti**. Hii ni muhimu hasa katika programu ambapo OAuth inatumika kwa **malengo ya uthibitishaji**.
|
||||
Washambuliaji wanaweza kutumia hii kwa kukamata mchakato wa uthibitisho ili kuunganisha akaunti yao na akaunti ya mwathirika, na kusababisha **uchukuaji wa akaunti** kwa kumfanya mtumiaji aingie na mchakato wa oauth ulio karibu kukamilika unaomilikiwa na mshambuliaji. Hii ni muhimu hasa katika programu ambapo OAuth inatumika kwa **malengo ya uthibitishaji**.
|
||||
|
||||
Mifano halisi ya udhaifu huu imeandikwa katika changamoto mbalimbali za **CTF** na **majukwaa ya udukuzi**, 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.
|
||||
Mifano halisi ya udhaifu huu imeandikwa katika changamoto mbalimbali za **CTF** na **majukwaa ya udukuzi**, ikionyesha athari zake za vitendo. Tatizo hili pia linapanuka kwa ushirikiano na huduma za tatu kama **Slack**, **Stripe**, na **PayPal**, ambapo washambuliaji wanaweza kuelekeza arifa au malipo kwa akaunti zao.
|
||||
|
||||
Usimamizi na uthibitisho sahihi wa **`state` parameter** ni muhimu kwa kulinda dhidi ya CSRF na kuhakikisha mchakato wa OAuth unakuwa salama.
|
||||
Usimamizi na uthibitisho sahihi wa **`state` parameter** ni muhimu kwa kulinda dhidi ya CSRF na kuhakikisha mchakato wa OAuth.
|
||||
|
||||
### Kabla ya Uchukuaji wa Akaunti <a href="#ebe4" id="ebe4"></a>
|
||||
|
||||
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.
|
||||
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 tatu kuingia, programu inaweza bila kukusudia kuunganisha akaunti hii ya tatu na akaunti iliyoundwa na mshambuliaji, na kusababisha ufikiaji usioidhinishwa.
|
||||
2. **Kutatua 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.
|
||||
|
||||
### Ufunuo wa Siri <a href="#e177" id="e177"></a>
|
||||
|
||||
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.
|
||||
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` itavunjwa, 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.
|
||||
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.
|
||||
|
||||
### Bruteforce ya Siri ya Mteja
|
||||
|
||||
@ -143,7 +143,7 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
|
||||
]
|
||||
}
|
||||
```
|
||||
Kwa maelezo ya kina zaidi kuhusu jinsi ya kutumia AWS cognito angalia:
|
||||
Kwa maelezo ya kina zaidi kuhusu jinsi ya kutumia AWS cognito, angalia:
|
||||
|
||||
{{#ref}}
|
||||
https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html
|
||||
@ -151,55 +151,55 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
|
||||
|
||||
### Kutumia token za Apps nyingine <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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 msimbo) unaweza kuwa na hatari ikiwa hauhakiki kwamba token inamhusu app.
|
||||
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 mtumiaji wa 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 **token ya OAuth ya mtumiaji iliyotolewa kwa programu yake, na kuitumia kuingia katika programu ya OAuth ya mwathirika kwa kutumia token ya mtumiaji wa mwathirika**.
|
||||
Hii ni kwa sababu **mshambuliaji** anaweza kuunda **programu inayounga mkono OAuth na kuingia kwa Facebook** (kwa mfano) katika programu yake mwenyewe. Kisha, mara tu mwathirika anapoingia kwa Facebook katika **programu ya mshambuliaji**, mshambuliaji anaweza kupata **token ya OAuth ya mtumiaji iliyotolewa kwa programu yake, na kuitumia kuingia katika programu ya OAuth ya mwathirika kwa kutumia token ya mtumiaji wa mwathirika**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Hivyo, ikiwa mshambuliaji atafanikiwa kumfanya mtumiaji aingie katika programu yake ya OAuth, atakuwa na uwezo wa kuchukua akaunti ya mwathirika katika programu zinazotarajia token na hazikaguzi kama token ilitolewa kwa ID ya programu yao.
|
||||
> Hivyo, ikiwa mshambuliaji atafanikiwa kumfanya mtumiaji aingie katika programu yake ya OAuth, atakuwa na uwezo wa kuchukua akaunti ya mwathirika katika programu zinazotarajia token na hazikaguzi kama token hiyo ilitolewa kwa ID ya programu yao.
|
||||
|
||||
### Viungo viwili & cookie <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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. Habari hii ingekuwa **imehifadhiwa katika cookie (RU)** na katika **hatua ya baadaye** **prompt** itakuwa **inauliza** **mtumiaji** kama anataka kutoa ufaccess kwa mwenyeji wa mshambuliaji.
|
||||
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 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.
|
||||
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.
|
||||
|
||||
### Kupita Mwingiliano wa Prompt <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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** ufaccess 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), 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.
|
||||
|
||||
### response_mode
|
||||
|
||||
Kama [**ilivyoelezwa katika video hii**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), inaweza kuwa inawezekana kuashiria parameter **`response_mode`** kuonyesha unataka msimbo utolewe wapi katika URL ya mwisho:
|
||||
Kama [**ilivyoelezwa katika video hii**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), inaweza kuwa inawezekana kuashiria parameter **`response_mode`** ili kuashiria unataka nambari ipatikane wapi katika URL ya mwisho:
|
||||
|
||||
- `response_mode=query` -> Msimbo unapatikana ndani ya parameter ya GET: `?code=2397rf3gu93f`
|
||||
- `response_mode=fragment` -> Msimbo unapatikana ndani ya parameter ya URL fragment `#code=2397rf3gu93f`
|
||||
- `response_mode=form_post` -> Msimbo unapatikana ndani ya fomu ya POST yenye input inayoitwa `code` na thamani
|
||||
- `response_mode=web_message` -> Msimbo unatumwa katika ujumbe wa posta: `window.opener.postMessage({"code": "asdasdasd...`
|
||||
- `response_mode=query` -> Nambari inapatikana ndani ya parameter ya GET: `?code=2397rf3gu93f`
|
||||
- `response_mode=fragment` -> Nambari inapatikana ndani ya parameter ya fragment ya URL `#code=2397rf3gu93f`
|
||||
- `response_mode=form_post` -> Nambari inapatikana ndani ya fomu ya POST yenye input inayoitwa `code` na thamani
|
||||
- `response_mode=web_message` -> Nambari inatumwa katika ujumbe wa posta: `window.opener.postMessage({"code": "asdasdasd...`
|
||||
|
||||
### OAuth ROPC flow - 2 FA bypass <a href="#b440" id="b440"></a>
|
||||
### Mchakato wa OAuth ROPC - kupita 2 FA <a href="#b440" id="b440"></a>
|
||||
|
||||
Kulingana na [**andiko hili la blog**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), huu ni mchakato wa OAuth unaoruhusu kuingia katika OAuth kupitia **jina la mtumiaji** na **nenosiri**. Ikiwa wakati wa mchakato huu rahisi **token** yenye ufaccess kwa vitendo vyote ambavyo mtumiaji anaweza kufanya inarudishwa basi inawezekana kupita 2FA kwa kutumia token hiyo.
|
||||
Kulingana na [**andiko hili**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), huu ni mchakato wa OAuth unaoruhusu kuingia katika OAuth kupitia **jina la mtumiaji** na **nenosiri**. Ikiwa wakati wa mchakato huu rahisi **token** yenye ufikiaji wa vitendo vyote ambavyo mtumiaji anaweza kufanya inarudishwa, basi inawezekana kupita 2FA kwa kutumia token hiyo.
|
||||
|
||||
### ATO kwenye ukurasa wa wavuti unaoelekeza kulingana na uelekezaji wazi kwa referrer <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Hii [**blogpost**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) inaelezea jinsi ilivyowezekana kutumia **uongozi wazi** kwa thamani kutoka kwa **referrer** kutumia OAuth kwa ATO. Shambulio lilikuwa:
|
||||
Huu [**blogpost**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) unazungumzia jinsi ilivyowezekana kutumia **upelelezi wazi** kwa thamani kutoka kwa **referrer** ili kutumia OAuth kwa ATO. Shambulio lilikuwa:
|
||||
|
||||
1. Mwathirika anafikia ukurasa wa wavuti wa mshambuliaji
|
||||
2. Mwathirika anafungua kiungo kibaya na opener inaanzisha mchakato wa Google OAuth na `response_type=id_token,code&prompt=none` kama vigezo vya ziada kwa kutumia kama **referrer tovuti ya mshambuliaji**.
|
||||
3. Katika opener, baada ya mtoa huduma kumruhusu mwathirika, inawapelekea nyuma kwa thamani ya parameter ya `redirect_uri` (wavuti ya mwathirika) kwa msimbo wa 30X ambao bado unashikilia tovuti ya mshambuliaji katika referrer.
|
||||
4. Tovuti ya mwathirika **inasababisha uelekezaji wazi kulingana na referrer** ikielekeza mtumiaji wa mwathirika kwenye tovuti ya mshambuliaji, kwani **`respose_type`** ilikuwa **`id_token,code`**, msimbo utarudishwa kwa mshambuliaji katika **fragment** ya URL ikimruhusu kuchukua akaunti ya mtumiaji kupitia Google kwenye tovuti ya mwathirika.
|
||||
3. Katika opener, baada ya mtoa huduma kumruhusu mwathirika, inawapelekea nyuma kwa thamani ya parameter ya `redirect_uri` (wavuti ya mwathirika) kwa nambari ya 30X ambayo bado inashikilia tovuti ya mshambuliaji katika referrer.
|
||||
4. Tovuti ya mwathirika **inasababisha uelekezaji wazi kulingana na referrer** ikielekeza mtumiaji wa mwathirika kwenye tovuti ya mshambuliaji, kwani **`respose_type`** ilikuwa **`id_token,code`**, nambari itarudishwa kwa mshambuliaji katika **fragment** ya URL ikimruhusu kuchukua akaunti ya mtumiaji kupitia Google kwenye tovuti ya mwathirika.
|
||||
|
||||
### SSRFs parameters <a href="#bda5" id="bda5"></a>
|
||||
|
||||
[**Angalia utafiti huu**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Kwa maelezo zaidi ya mbinu hii.**
|
||||
|
||||
Usajili wa Wateja wa Kijani katika OAuth unatumika kama njia isiyo wazi lakini muhimu kwa udhaifu wa usalama, haswa kwa mashambulizi ya **Server-Side Request Forgery (SSRF)**. Endpoint hii inaruhusu seva za OAuth kupokea maelezo kuhusu programu za wateja, ikiwa ni pamoja na URLs nyeti ambazo zinaweza kutumika vibaya.
|
||||
Usajili wa Wateja wa Kijadi katika OAuth unatumika kama vector isiyo wazi lakini muhimu kwa udhaifu wa usalama, haswa kwa mashambulizi ya **Server-Side Request Forgery (SSRF)**. Endpoint hii inaruhusu seva za OAuth kupokea maelezo kuhusu programu za wateja, ikiwa ni pamoja na URLs nyeti ambazo zinaweza kutumika vibaya.
|
||||
|
||||
**Mambo Muhimu:**
|
||||
|
||||
- **Usajili wa Wateja wa Kijani** mara nyingi unahusishwa na `/register` na unakubali maelezo kama `client_name`, `client_secret`, `redirect_uris`, na URLs za alama au JSON Web Key Sets (JWKs) kupitia maombi ya POST.
|
||||
- Kipengele hiki kinatii viwango vilivyowekwa katika **RFC7591** na **OpenID Connect Registration 1.0**, ambavyo vinajumuisha vigezo ambavyo vinaweza kuwa na hatari kwa SSRF.
|
||||
- **Usajili wa Wateja wa Kijadi** mara nyingi unahusishwa na `/register` na unakubali maelezo kama `client_name`, `client_secret`, `redirect_uris`, na URLs za alama au JSON Web Key Sets (JWKs) kupitia maombi ya POST.
|
||||
- Kipengele hiki kinazingatia vipimo vilivyowekwa katika **RFC7591** na **OpenID Connect Registration 1.0**, ambavyo vinajumuisha vigezo ambavyo vinaweza kuwa na hatari kwa SSRF.
|
||||
- Mchakato wa usajili unaweza bila kukusudia kufichua seva kwa SSRF kwa njia kadhaa:
|
||||
- **`logo_uri`**: URL ya alama 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.
|
||||
@ -208,16 +208,38 @@ Usajili wa Wateja wa Kijani katika OAuth unatumika kama njia isiyo wazi lakini m
|
||||
|
||||
**Mkakati wa Kutumia:**
|
||||
|
||||
- SSRF inaweza kusababisha usajili wa mteja mpya na URLs mbaya katika vigezo kama `logo_uri`, `jwks_uri`, au `sector_identifier_uri`.
|
||||
- SSRF inaweza kuanzishwa kwa kujiandikisha mteja mpya na URLs mbaya katika vigezo 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.
|
||||
|
||||
## Mipangilio ya Watoa huduma wa OAuth
|
||||
## Masharti ya Mshindani wa OAuth
|
||||
|
||||
Ikiwa jukwaa unalojaribu ni mtoa huduma wa OAuth [**soma hii ili kujaribu uwezekano wa Mipangilio ya Mbio**](race-condition.md).
|
||||
Ikiwa jukwaa unalojaribu ni mtoa huduma wa OAuth [**soma hii ili kujaribu uwezekano wa Masharti ya Mshindani**](race-condition.md).
|
||||
|
||||
## Shambulio la Mutable Claims
|
||||
|
||||
Katika OAuth, uwanja wa sub unamfanya mtumiaji kuwa wa kipekee, lakini muundo wake hutofautiana na Seva ya Uidhinishaji. Ili kuimarisha utambulisho wa mtumiaji, baadhi ya wateja hutumia barua pepe au vitambulisho vya mtumiaji. Hata hivyo, hii ni hatari kwa sababu:
|
||||
|
||||
- Baadhi ya Seva za Uidhinishaji hazihakikishi kwamba mali hizi (kama barua pepe) zinabaki kuwa zisizobadilika.
|
||||
- Katika utekelezaji fulani—kama **"Ingia na Microsoft"**—mteja anategemea uwanja wa barua pepe, ambao ni **unaodhibitiwa na mtumiaji katika Entra ID** na hauhakikishwi.
|
||||
- Mshambuliaji anaweza kutumia hii kwa kuunda shirika lake la Azure AD (kwa mfano, doyensectestorg) na kulitumika kufanya kuingia kwa Microsoft.
|
||||
- Ingawa Kitambulisho cha Kitu (kilichohifadhiwa katika sub) ni kisichobadilika na salama, kutegemea uwanja wa barua pepe unaoweza kubadilika kunaweza kuwezesha kuchukuliwa kwa akaunti (kwa mfano, kuiba akaunti kama victim@gmail.com).
|
||||
|
||||
## Shambulio la Kichanganyiko cha Mteja
|
||||
|
||||
Katika **Shambulio la Kichanganyiko cha Mteja**, programu inayotumia Mchakato wa OAuth Implicit inashindwa kuthibitisha kwamba token ya mwisho ya ufikiaji imeundwa mahsusi kwa ID yake ya Mteja. Mshambuliaji anaunda tovuti ya umma inayotumia Mchakato wa OAuth Implicit wa Google, akiwadanganya maelfu ya watumiaji kuingia na hivyo kukusanya token za ufikiaji zilizokusudiwa kwa tovuti ya mshambuliaji. Ikiwa watumiaji hawa pia wana akaunti kwenye tovuti nyingine iliyo hatarini ambayo haithibitishi ID ya token, mshambuliaji anaweza kutumia tena token zilizokusanywa ili kujifanya kuwa waathirika na kuchukua akaunti zao.
|
||||
|
||||
## Shambulio la Kuongeza Mipaka
|
||||
|
||||
Aina ya **Authorization Code Grant** inahusisha mawasiliano salama ya seva kwa seva kwa kuhamasisha data ya mtumiaji. Hata hivyo, ikiwa **Seva ya Uidhinishaji** inategemea kwa siri parameter ya mipaka katika Maombi ya Token ya Ufikiaji (parameter ambayo haijafafanuliwa katika RFC), programu mbaya inaweza kuongeza mamlaka ya nambari ya uidhinishaji kwa kuomba mipaka ya juu. Baada ya **Token ya Ufikiaji** kuundwa, **Seva ya Rasilimali** inapaswa kuithibitisha: kwa token za JWT, hii inahusisha kuangalia saini ya JWT na kutoa data kama client_id na scope, wakati kwa token za mfuatano wa nasibu, seva inapaswa kuuliza Seva ya Uidhinishaji ili kupata maelezo ya token.
|
||||
|
||||
## Hijacking ya Mpango wa Uelekezaji
|
||||
|
||||
Katika utekelezaji wa OAuth wa simu, programu hutumia **mifumo ya URI maalum** kupokea uelekezaji wenye Nambari za Uidhinishaji. Hata hivyo, kwa sababu programu nyingi zinaweza kujiandikisha mfumo sawa kwenye kifaa, dhana kwamba mteja halali pekee ndiye anayekontrola URI ya uelekezaji inavunjwa. Kwenye Android, kwa mfano, URI ya Intent kama `com.example.app://` oauth inakamatwa kulingana na mfumo na filters za hiari zilizofafanuliwa katika intent-filter ya programu. Kwa kuwa ufumbuzi wa nia ya Android unaweza kuwa mpana—hasa ikiwa tu mfumo umeainishwa—mshambuliaji anaweza kujiandikisha programu mbaya yenye filter ya nia iliyoundwa kwa uangalifu ili kuiba nambari ya uidhinishaji. Hii inaweza **kuwezesha kuchukuliwa kwa akaunti** ama kupitia mwingiliano wa mtumiaji (wakati programu nyingi zinastahili kushughulikia nia hiyo) au kupitia mbinu za kupita zinazotumia filters zisizo sahihi, kama ilivyoelezwa na mchoro wa tathmini wa Ostorlab.
|
||||
|
||||
## Marejeleo
|
||||
|
||||
- [**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 @@ Kulingana na jinsi back-end/front-end inavyofanya kazi wakati in **pata wahusika
|
||||
|
||||
Unicode normalization inatokea wakati **wahusika wa unicode wanapohaririwa kuwa wahusika wa ascii**.
|
||||
|
||||
Moja ya hali ya kawaida ya aina hii ya udhaifu inatokea wakati mfumo unafanya **mabadiliko** kwa namna fulani kwenye **ingizo** la mtumiaji **baada ya kulikagua**. Kwa mfano, katika lugha zingine, simu rahisi ya kufanya **ingizo kuwa kubwa au dogo** inaweza kuhariri ingizo lililotolewa na **unicode litabadilishwa kuwa ASCII** na kuunda wahusika wapya.\
|
||||
Moja ya hali ya kawaida ya aina hii ya udhaifu inatokea wakati mfumo unavyokuwa **ukibadilisha** kwa namna fulani **ingizo** la mtumiaji **baada ya kulikagua**. Kwa mfano, katika lugha zingine, simu rahisi ya kufanya **ingizo kuwa kubwa au dogo** inaweza kuhariri ingizo lililotolewa na **unicode litabadilishwa kuwa ASCII** na kuunda wahusika wapya.\
|
||||
Kwa maelezo zaidi angalia:
|
||||
|
||||
{{#ref}}
|
||||
@ -19,18 +19,18 @@ unicode-normalization.md
|
||||
|
||||
## `\u` to `%`
|
||||
|
||||
Wahusika wa unicode kwa kawaida huwakilishwa na **`\u` prefix**. Kwa mfano, wahusika `㱋` ni `\u3c4b`([angalia hapa](https://unicode-explorer.com/c/3c4B)). Ikiwa back-end **inabadilisha** prefix **`\u` kuwa `%`**, string inayotokana itakuwa `%3c4b`, ambayo URL decoded ni: **`<4b`**. Na, kama unavyoona, wahusika **`<` umeingizwa**.\
|
||||
Wahusika wa unicode kawaida huwakilishwa na **`\u` prefix**. Kwa mfano, wahusika `㱋` ni `\u3c4b`([angalia hapa](https://unicode-explorer.com/c/3c4B)). Ikiwa back-end **inabadilisha** prefix **`\u` kuwa `%`**, string inayotokana itakuwa `%3c4b`, ambayo ikitafsiriwa URL ni: **`<4b`**. Na, kama unavyoona, wahusika **`<` umeingizwa**.\
|
||||
Unaweza kutumia mbinu hii ku **ingiza aina yoyote ya wahusika** ikiwa back-end ina udhaifu.\
|
||||
Angalia [https://unicode-explorer.com/](https://unicode-explorer.com/) kupata wahusika unahitaji.
|
||||
|
||||
Udhaifu huu kwa kweli unatokana na udhaifu ambao mtafiti alipata, kwa maelezo ya kina angalia [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
|
||||
Udhaifu huu kwa kweli unatokana na udhaifu ambao mtafiti alipata, kwa maelezo zaidi angalia [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
|
||||
|
||||
## Emoji Injection
|
||||
|
||||
Back-ends fulani zinafanya kazi kwa njia ya ajabu wanap **pata emojis**. Hivyo ndivyo ilivyotokea katika [**hii andiko**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) ambapo mtafiti alifanikiwa kupata XSS kwa payload kama: `💋img src=x onerror=alert(document.domain)//💛`
|
||||
Back-ends fulani zinafanya kazi kwa njia ya ajabu wanap **pata emojis**. Hivyo ndivyo ilivyotokea katika [**hii andiko**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) ambapo mtafiti alifanikiwa kufikia XSS kwa payload kama: `💋img src=x onerror=alert(document.domain)//💛`
|
||||
|
||||
Katika kesi hii, kosa lilikuwa kwamba seva baada ya kuondoa wahusika wabaya **ilibadilisha string ya UTF-8 kutoka Windows-1252 hadi UTF-8** (kimsingi uandishi wa ingizo na kubadilisha kutoka uandishi vilikuwa tofauti). Kisha hii haisababishi < sahihi bali unicode ya ajabu: `‹`\
|
||||
``Hivyo walichukua matokeo haya na **wakabadilisha tena sasa kutoka UTF-8 hadi ASCII**. Hii **ilihariri** `‹` kuwa `<` hii ndiyo jinsi exploit ilivyoweza kufanya kazi kwenye mfumo huo.\
|
||||
Katika kesi hii, kosa lilikuwa kwamba seva baada ya kuondoa wahusika hatari **ilibadilisha string ya UTF-8 kutoka Windows-1252 hadi UTF-8** (kimsingi uandishi wa ingizo na kubadilisha kutoka uandishi vilikuwa tofauti). Kisha hii haisababishi < sahihi bali unicode ya ajabu: `‹`\
|
||||
``Hivyo walichukua matokeo haya na **kubadilisha tena sasa kutoka UTF-8 hadi ASCII**. Hii **ilihariri** `‹` kuwa ` <` hivi ndivyo exploit ilivyoweza kufanya kazi kwenye mfumo huo.\
|
||||
Hii ndiyo ilivyotokea:
|
||||
```php
|
||||
<?php
|
||||
@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
|
||||
|
||||
echo "String: " . $str;
|
||||
```
|
||||
Orodha za Emoji:
|
||||
Emoji orodha:
|
||||
|
||||
- [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 Best-Fit/Worst-fit
|
||||
|
||||
Kama ilivyoelezwa katika **[hiki kipande kizuri](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, Windows ina kipengele kinachoitwa **Best-Fit** ambacho kita **badilisha wahusika wa unicode** ambao hawawezi kuonyeshwa katika hali ya ASCII na wahusika wanaofanana. Hii inaweza kusababisha **tabia isiyotarajiwa** wakati backend inatarajia **wahusika maalum** lakini inapata mwingine tofauti.
|
||||
|
||||
Inawezekana kupata wahusika bora katika **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
|
||||
|
||||
Kama Windows kawaida hubadilisha nyuzi za unicode kuwa nyuzi za ascii kama sehemu ya mwisho ya utekelezaji (kawaida ikitoka kwenye API yenye kiambishi "W" hadi API yenye kiambishi "A" kama `GetEnvironmentVariableA` na `GetEnvironmentVariableW`) hii itawawezesha washambuliaji kupita ulinzi kwa kutuma wahusika wa unicode ambao watabadilishwa mwisho kuwa wahusika wa ASCII ambao wangeweza kufanya vitendo visivyotarajiwa.
|
||||
|
||||
Katika chapisho la blogu kuna mbinu zilizopendekezwa za kupita udhaifu zilizorekebishwa kwa kutumia **orodha ya wahusika wa mblacklist**, kutumia **path traversals** kwa kutumia [wahusika waliotengwa kwa “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) na [wahusika waliotengwa kwa “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) au hata kupita ulinzi wa shell escape kama vile `escapeshellarg` ya PHP au `subprocess.run` ya Python kwa kutumia orodha, hii ilifanywa kwa mfano kwa kutumia **fullwidth double quotes (U+FF02)** badala ya double quotes hivyo mwishowe kile kilichokuwa kama hoja 1 kiligeuzwa kuwa hoja 2.
|
||||
|
||||
**Kumbuka kwamba ili programu iwe na udhaifu inahitaji kutumia "W" Windows APIs lakini mwishowe inaita API ya "A" ya Windows ili "Best-fit" ya nyuzi za unicode iundwe.**
|
||||
|
||||
**Udhaifu kadhaa zilizogunduliwa hazitarekebishwa kwani watu hawakubaliani ni nani anayeweza kutatua tatizo hili.**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user