<summary><strong>Jifunze kuhusu kudukua AWS kutoka mwanzo hadi kuwa bingwa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikionekana kwenye HackTricks** au **kupakua HackTricks kwa muundo wa PDF** Angalia [**MPANGO WA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Pata [**swag rasmi ya PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**The PEASS Family**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) za kipekee
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au [**kikundi cha telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwenye** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
Mfumo wa Kugawana Rasilmali kati ya Asili Tofauti (CORS) **inaruhusu seva kuamua ni nani anaweza kupata mali zao** na **njia za ombi za HTTP zinazoruhusiwa** kutoka vyanzo vya nje.
Sera ya **asili sawa** inahitaji kwamba **seva inayotaka** rasilimali na seva inayohifadhi **rasilimali** washiriki itifaki sawa (k.m., `http://`), jina la kikoa (k.m., `internal-web.com`), na **bandari** (k.m., 80). Chini ya sera hii, kurasa za wavuti kutoka kikoa na bandari sawa tu ndizo zinaruhusiwa kupata rasilimali.
Kichwa hiki kinaweza kuruhusu **asili nyingi**, thamani ya **`null`**, au alama ya nanga **`*`**. Walakini, **kivinjari chochote hakiruhusu asili nyingi**, na matumizi ya alama ya nanga `*` yanategemea **mipaka**. (Alama ya nanga lazima itumiwe pekee yake, na matumizi yake pamoja na `Access-Control-Allow-Credentials: true` hayaruhusiwi.)
Kichwa hiki kinatolewa na **seva** kujibu ombi la rasilimali kati ya uwanja wa msalaba lililoanzishwa na wavuti, na kivinjari kikiongeza kiotomatiki kichwa cha `Origin`.
Kwa **chaguo-msingi**, maombi ya asili tofauti hufanywa bila vitambulisho kama vidakuzi au kichwa cha Uthibitishaji. Walakini, seva ya uwanja wa msalaba inaweza kuruhusu kusoma majibu wakati vitambulisho vinatumwa kwa kuweka kichwa cha `Access-Control-Allow-Credentials` kuwa **`true`**.
Wakati wa kuanzisha ombi la kuvuka-domain chini ya hali maalum, kama kutumia **njia ya HTTP isiyo ya kawaida** (kitu kingine chochote isipokuwa HEAD, GET, POST), kuongeza **vichwa vya habari** vipya, au kutumia thamani maalum ya **kichwa cha Maudhui (Content-Type)**, inaweza kuhitajika ombi la awali. Ombi hili la awali, likitumia njia ya **`OPTIONS`**, linatumika kuwajulisha seva nia ya ombi la kuvuka-mwanzo linalokuja, ikiwa ni pamoja na njia za HTTP na vichwa vya habari itakavyotumia.
Itifaki ya **Kugawana Rasilmali kati ya Mwanzo Mbalimbali (CORS)** inahitaji ukaguzi huu wa awali ili kubaini uwezekano wa operesheni ya kuvuka-mwanzo iliyohitajika kwa kuthibitisha njia na vichwa vya habari vinavyoruhusiwa, na uaminifu wa asili. Ili kuelewa kwa undani hali ambazo zinapuuza haja ya ombi la awali, tazama mwongozo kamili uliotolewa na [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).
Ni muhimu kuzingatia kwamba **ukosefu wa ombi la awali hauondoi hitaji la majibu kuwa na vichwa vya idhini**. Bila vichwa hivi, kivinjari kinashindwa kusindika majibu kutoka kwa ombi la kuvuka-mwanzo.
Kama jibu, server inaweza kurudisha vichwa vya habari vinavyoonyesha njia zilizokubalika, asili iliyoruhusiwa, na maelezo mengine ya sera ya CORS, kama inavyoonyeshwa hapa chini:
- **`Access-Control-Allow-Headers`**: Kichwa hiki kinaeleza ni vichwa vipi vinaweza kutumika wakati wa ombi halisi. Kinasetwa na seva ili kuonyesha vichwa vilivyoidhinishwa katika maombi kutoka kwa mteja.
- **`Access-Control-Expose-Headers`**: Kupitia kichwa hiki, seva inaarifu mteja ni vichwa vipi vinaweza kuonyeshwa kama sehemu ya jibu mbali na vichwa vya jibu rahisi.
- **`Access-Control-Max-Age`**: Kichwa hiki kinaonyesha muda gani matokeo ya ombi la awali yanaweza kuhifadhiwa katika cache. Seva inaweka muda wa kikomo, kwa sekunde, ambapo habari iliyorudishwa na ombi la awali inaweza kutumika tena.
- **`Access-Control-Request-Headers`**: Kinatumika katika maombi ya awali, kichwa hiki kinasetwa na mteja ili kuarifu seva ni vichwa vipi vya HTTP mteja anataka kutumia katika ombi halisi.
- **`Access-Control-Request-Method`**: Kichwa hiki, kinachotumika pia katika maombi ya awali, kinasetwa na mteja ili kuonyesha ni njia gani ya HTTP itatumika katika ombi halisi.
- **`Origin`**: Kichwa hiki kinawekwa moja kwa moja na kivinjari na kinaonyesha asili ya ombi la msingi. Kinatumika na seva ili kufanya tathmini ikiwa ombi linalokuja linapaswa kuruhusiwa au kukataliwa kulingana na sera ya CORS.
Tafadhali kumbuka kuwa kwa kawaida (kulingana na aina ya yaliyomo na vichwa vilivyowekwa) katika ombi la **GET/POST hakuna ombi la awali linalotumwa** (ombi linatumwa **moja kwa moja**), lakini ikiwa unataka kupata **vichwa/mwili wa jibu**, lazima iwe na kichwa cha _Access-Control-Allow-Origin_ kinachoruhusu hilo.\
**Kwa hivyo, CORS haiwalindi dhidi ya CSRF (lakini inaweza kuwa na manufaa).**
1.**`Access-Control-Request-Local-Network`**: Kichwa hiki kinaongezwa katika ombi la mteja ili kuonyesha kuwa ombi linahusiana na rasilimali ya mtandao wa ndani. Kinatumika kama alama ya kuonyesha seva kuwa ombi linatoka ndani ya mtandao wa ndani.
2.**`Access-Control-Allow-Local-Network`**: Kama jibu, seva hutumia kichwa hiki kuwasiliana kuwa rasilimali iliyoombwa inaruhusiwa kushirikiwa na vyombo nje ya mtandao wa ndani. Kinatoa idhini ya kushiriki rasilimali kwenye mipaka tofauti ya mtandao, ikihakikisha ufikiaji uliodhibitiwa wakati wa kudumisha itifaki za usalama.
Tafadhali kumbuka kuwa anwani ya IP ya linux **0.0.0.0** inafanya kazi ya **kuzunguka** mahitaji haya ili kupata ufikiaji wa localhost kwa sababu anwani hiyo ya IP haihesabiwi kuwa "ya ndani".
Pia ni rahisi **kuzunguka mahitaji ya Mtandao wa Ndani** ikiwa unatumia **anwani ya IP ya umma ya kifaa cha ndani** (kama vile anwani ya IP ya umma ya router). Kwa sababu katika hali kadhaa, hata ikiwa anwani ya **IP ya umma** inafikiwa, ikiwa ni **kutoka kwenye mtandao wa ndani**, ufikiaji utaruhusiwa.
Imeonekana kuwa kuweka `Access-Control-Allow-Credentials` kuwa **`kweli`** ni sharti la msingi kwa mashambulizi mengi ya kweli. Mazingira haya huruhusu kivinjari kutuma vitambulisho na kusoma majibu, kuongeza ufanisi wa shambulio. Bila hii, faida ya kufanya ombi kupitia kivinjari badala ya kufanya ombi mwenyewe inapungua, kwani kutumia vidakuzi vya mtumiaji kunakuwa sio rahisi.
Kuna ubaya ambapo mahali pa mtandao wa mwathirika unafanya kazi kama aina fulani ya uthibitisho. Hii inaruhusu kivinjari cha mwathirika kutumiwa kama proksi, kuzunguka uthibitisho unaotegemea anwani ya IP ili kupata ufikiaji wa programu za ndani za mtandao. Njia hii ina fanana na DNS rebinding lakini ni rahisi zaidi kudukua.
Hali halisi ambapo thamani ya kichwa cha `Origin` inarejelezwa katika `Access-Control-Allow-Origin` ni nadra kwa nadharia kutokana na vizuizi vya kuunganisha vichwa hivi. Walakini, watengenezaji wanaotaka kuwezesha CORS kwa URL nyingi wanaweza kuzalisha kichwa cha `Access-Control-Allow-Origin` kwa kuchukua thamani ya kichwa cha `Origin`. Njia hii inaweza kuleta udhaifu, haswa wakati mshambuliaji anatumia kikoa chenye jina linalofanana na halisi, hivyo kudanganya mantiki ya ukaguzi.
Chanzo cha `null`, kilichotajwa kwa hali kama vile maelekezo au faili za HTML za ndani, kinashikilia nafasi ya pekee. Baadhi ya programu huruhusu chanzo hiki kupitia orodha nyeupe ili kuwezesha maendeleo ya ndani, bila kukusudia kuruhusu tovuti yoyote kuiga chanzo cha `null` kupitia kisanduku cha iframe, hivyo kudukua vizuizi vya CORS.
Unapokutana na orodha nyeupe ya kikoa, ni muhimu kujaribu fursa za kupita kwenye, kama kuongeza kikoa cha muharibifu kwenye kikoa kilichoorodheshwa au kutumia udhaifu wa kuchukua udhibiti wa subdomain. Aidha, mifumo ya msimbo wa kawaida inayotumiwa kwa uhakiki wa kikoa inaweza kusahau maelezo madogo katika kanuni za uandishi wa majina ya kikoa, hivyo kutoa fursa zaidi za kupita kwenye.
Kawaida, mifumo ya msimbo wa kawaida inazingatia herufi na nambari, alama ya nukta (.), na alama ya mkato (-), huku ikisahau uwezekano mwingine. Kwa mfano, jina la kikoa lililoundwa kwa kujumuisha herufi zinazotafsiriwa tofauti na vivinjari na mifumo ya msimbo wa kawaida inaweza kupita kwenye ukaguzi wa usalama. Jinsi Safari, Chrome, na Firefox vinavyoshughulikia herufi za chini katika subdomain inaonyesha jinsi tofauti hizo zinaweza kutumika kuzunguka mantiki ya uhakiki wa kikoa.
**Kwa habari zaidi na mipangilio ya ukaguzi huu wa kupita kwenye:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **na** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
Watengenezaji mara nyingi hutekeleza njia za kinga ili kulinda dhidi ya uchexploitation wa CORS kwa kuorodhesha kikoa ambacho kinaruhusiwa kuomba habari. Licha ya tahadhari hizi, usalama wa mfumo si kamili. Kuwepo kwa hata subdomain moja yenye udhaifu ndani ya vikoa vilivyoorodheshwa kunaweza kufungua mlango wa uchexploitation wa CORS kupitia udhaifu mwingine, kama vile XSS (Cross-Site Scripting).
Kwa mfano, fikiria hali ambapo kikoa, `requester.com`, kimeorodheshwa kuwa na ruhusa ya kupata rasilimali kutoka kikoa kingine, `provider.com`. Mazingira ya upande wa seva yanaweza kuonekana kama ifuatavyo:
Katika mpangilio huu, subdomains zote za `requester.com` zinaruhusiwa kupata. Hata hivyo, ikiwa subdomain, kama vile `sub.requester.com`, inaathiriwa na udhaifu wa XSS, mshambuliaji anaweza kutumia udhaifu huu. Kwa mfano, mshambuliaji aliye na ufikiaji wa `sub.requester.com` anaweza kutumia udhaifu wa XSS kukiuka sera za CORS na kupata rasilimali kwa nia mbaya kwenye `provider.com`.
Inawezekana kwa kudanganya cache upande wa seva kupitia uingizaji wa kichwa cha HTTP, udhaifu wa Stored Cross-Site Scripting (XSS) unaweza kusababishwa. Hali hii inatokea wakati programu haijasafisha kichwa cha `Origin` kwa herufi haramu, na kuunda udhaifu hasa kwa watumiaji wa Internet Explorer na Edge. Vivinjari hivi vinachukulia `\r` (0x0d) kama mtemi wa kichwa halali cha HTTP, na hivyo kusababisha udhaifu wa uingizaji wa kichwa cha HTTP.
Wakati wa kudukua udhaifu huu moja kwa moja kwa kufanya kivinjari cha wavuti kutuma kichwa kilichoharibika sio rahisi, ombi lililoundwa linaweza kuundwa kwa mkono kwa kutumia zana kama Burp Suite. Njia hii inaweza kusababisha hifadhidata ya seva kuokoa jibu na kuisambaza kwa wengine kwa bahati mbaya. Malipo yaliyoundwa yanakusudia kubadilisha seti ya herufi ya ukurasa kuwa UTF-7, aina ya uandikishaji wa herufi mara nyingi inayohusishwa na udhaifu wa XSS kutokana na uwezo wake wa kuandika herufi kwa njia ambayo inaweza kutekelezwa kama skripti katika muktadha fulani.
**Note**: Udukuzi wa udhaifu wa kuingiza kichwa cha HTTP, haswa kupitia sumu ya hifadhidata ya seva, unasisitiza umuhimu mkubwa wa kuthibitisha na kusafisha data yote inayotolewa na mtumiaji, pamoja na vichwa vya HTTP. Tumia mfano thabiti wa usalama ambao unajumuisha uthibitishaji wa data ili kuzuia udhaifu kama huo.
Katika hali hii, kuna ukurasa wa wavuti unaorudisha maudhui ya kichwa cha HTTP cha desturi bila uandikishaji sahihi. Hasa, ukurasa wa wavuti unarudisha maudhui yaliyomo kwenye kichwa cha `X-User-id`, ambacho kinaweza kuwa na JavaScript mbaya, kama inavyodhihirishwa na mfano ambapo kichwa cha habari kina lebo ya picha ya SVG iliyoundwa kutekeleza msimbo wa JavaScript wakati wa kupakia.
Sera za Kugawana Rasmi za Rasmi (CORS) huruhusu kutuma vichwa vya desturi. Walakini, bila jibu kutolewa moja kwa moja na kivinjari kutokana na vizuizi vya CORS, matumizi ya sindano kama hiyo yanaweza kuonekana kuwa na kikomo. Hatua muhimu inatokea wakati wa kuzingatia tabia ya hifadhidata ya kivinjari. Ikiwa kichwa cha `Vary: Origin` hakijatajwa, inawezekana kwamba jibu la mbaya linaweza kuhifadhiwa katika hifadhidata ya kivinjari. Kwa kuongezea, jibu hili lililohifadhiwa linaweza kuonyeshwa moja kwa moja wakati wa kuvinjari kwenye URL, bila haja ya kuonyeshwa moja kwa moja wakati wa ombi la awali. Mfumo huu unaimarisha ufanisi wa shambulio kwa kutumia hifadhidata ya upande wa mteja.
Ili kuonyesha shambulio hili, mfano wa JavaScript umetolewa, ulioundwa kutekelezwa katika mazingira ya ukurasa wa wavuti, kama vile kupitia JSFiddle. Skripti hii inatekeleza hatua rahisi: inatuma ombi kwa URL iliyoainishwa na kichwa cha desturi kinachojumuisha JavaScript mbaya. Baada ya kukamilisha ombi kwa mafanikio, inajaribu kuvinjari kwenye URL ya lengo, na hivyo kusababisha utekelezaji wa skripti iliyosindikwa ikiwa jibu limehifadhiwa bila kushughulikia kichwa cha `Vary: Origin` kwa usahihi.
XSSI, inayojulikana pia kama Uingizaji wa Skripti kwa Njia ya Msalaba, ni aina ya udhaifu ambao unatumia ukweli kwamba Sera ya Chanzo Sawa (SOP) haitekelezwi wakati wa kuingiza rasilimali kwa kutumia lebo ya skripti. Hii ni kwa sababu skripti inahitaji kuweza kuingizwa kutoka kwenye uwanja tofauti. Udhaifu huu unaruhusu mtu mwenye nia mbaya kupata na kusoma yaliyomo yoyote yaliyokuwa yameingizwa kwa kutumia lebo ya skripti.
Udhaifu huu unakuwa muhimu hasa linapokuja suala la JavaScript ya kibinadamu au JSONP (JSON na Kupangwa), haswa wakati habari ya mamlaka ya mazingira kama vile vidakuzi vinatumika kwa uwakiki. Wakati unapoomba rasilimali kutoka kwenye mwenyeji tofauti, vidakuzi hujumuishwa, hivyo kuwafanya kupatikana kwa mtu mwenye nia mbaya.
Ili kuelewa vizuri na kupunguza udhaifu huu, unaweza kutumia programu-jalizi ya BurpSuite inayopatikana kwenye [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). Programu-jalizi hii inaweza kusaidia kutambua na kushughulikia udhaifu wa XSSI katika programu zako za wavuti.
Jaribu kuongeza **`callback`** **parameter** katika ombi. Labda ukurasa ulikuwa umetayarishwa kutuma data kama JSONP. Katika kesi hiyo, ukurasa utatuma data tena na `Content-Type: application/javascript` ambayo itapita sera ya CORS.
Njia moja ya kuepuka kizuizi cha `Access-Control-Allow-Origin` ni kwa kuomba programu ya wavuti ifanye ombi kwa niaba yako na kutuma jibu. Hata hivyo, katika hali hii, vitambulisho vya mwisho wa mwathirika havitatumwa kwani ombi linafanywa kwa uwanja tofauti.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Zana hii hutoa wakala ambao unapeleka ombi lako pamoja na vichwa vyake, wakati pia unajifanya kuwa ni kichwa cha Asili kinacholingana na uwanja ulioombwa. Hii inapita sera ya CORS. Hapa kuna mfano wa matumizi na XMLHttpRequest:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Zana hii inatoa njia mbadala ya kupeleka ombi. Badala ya kupeleka ombi lako kama ilivyo, seva inafanya ombi lake lenyewe na vigezo vilivyotajwa.
Unaweza **kuepuka ukaguzi wa CORS** kama vile `e.origin === window.origin` kwa **kuunda iframe** na **kutoka hapo kufungua dirisha jipya**. Taarifa zaidi zinapatikana kwenye ukurasa ufuatao:
1. Mtu mwenye nia mbaya anaunda ukurasa wa wavuti na kumfanya mwathirika aufikie.
2. Mtu mwenye nia mbaya kisha anabadilisha DNS (IP) ya kikoa chake ili ielekeze kwenye ukurasa wa wavuti wa mwathirika.
3. Kivinjari cha mwathirika kinahifadhi jibu la DNS, ambalo linaweza kuwa na thamani ya TTL (Muda wa Kuishi) inayoonyesha muda gani rekodi ya DNS inapaswa kuchukuliwa kuwa halali.
4. Wakati TTL inapomalizika, kivinjari cha mwathirika kinafanya ombi jipya la DNS, kuruhusu mtu mwenye nia mbaya kutekeleza msimbo wa JavaScript kwenye ukurasa wa mwathirika.
5. Kwa kuendelea kudhibiti IP ya mwathirika, mtu mwenye nia mbaya anaweza kukusanya habari kutoka kwa mwathirika bila kutuma vidakuzi kwa seva ya mwathirika.
Ni muhimu kuzingatia kuwa vivinjari vina taratibu za kuhifadhi cache ambazo zinaweza kuzuia matumizi ya moja kwa moja ya mbinu hii, hata na thamani ndogo za TTL.
DNS rebinding inaweza kuwa na manufaa kwa kuepuka ukaguzi wazi wa IP uliofanywa na mwathirika au kwa hali ambapo mtumiaji au boti anabaki kwenye ukurasa huo kwa muda mrefu, kuruhusu muda wa kumalizika kwa cache.
Ikiwa unahitaji njia ya haraka ya kutumia DNS rebinding, unaweza kutumia huduma kama [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html).
Ili kuendesha seva yako ya DNS rebinding, unaweza kutumia zana kama **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Hii inahusisha kufichua bandari yako ya ndani ya 53/udp, kuunda rekodi ya A inayoelekeza kwake (kwa mfano, ns.example.com), na kuunda rekodi ya NS inayoelekeza kwa subdomain ya A iliyoanzishwa hapo awali (kwa mfano, ns.example.com). Kwa njia hii, kila subdomain ya subdomain ya ns.example.com itatatuliwa na mwenyeji wako.
Pia unaweza kuchunguza seva inayofanya kazi kwa umma kwenye [http://rebind.it/singularity.html](http://rebind.it/singularity.html) ili kuelewa na kufanya majaribio zaidi.
DNS rebinding kupitia kufurika kwa cache ya DNS ni mbinu nyingine inayotumiwa kuepuka utaratibu wa kuhifadhi cache ya vivinjari na kulazimisha ombi la pili la DNS. Hapa ndivyo inavyofanya kazi:
1. Awali, wakati mwathirika anafanya ombi la DNS, anajibiwa na anwani ya IP ya mtu mwenye nia mbaya.
2. Ili kuepuka ulinzi wa kuhifadhi cache, mtu mwenye nia mbaya anatumia mfanyakazi wa huduma. Mfanyakazi wa huduma hufurika kwenye cache ya DNS, ambayo kimsingi inafuta jina la seva ya mtu mwenye nia mbaya lililohifadhiwa kwenye cache.
3. Wakati kivinjari cha mwathirika kinapofanya ombi la pili la DNS, sasa linajibiwa na anwani ya IP 127.0.0.1, ambayo kwa kawaida inahusu localhost.
Kwa kufurika cache ya DNS na mfanyakazi wa huduma, mtu mwenye nia mbaya anaweza kudhibiti mchakato wa ufafanuzi wa DNS na kulazimisha kivinjari cha mwathirika kufanya ombi la pili, wakati huu likielekezwa kwa anwani ya IP inayotakiwa na mtu mwenye nia mbaya.
Njia nyingine ya kuepuka ulinzi wa kuhifadhi cache ni kwa kutumia anwani za IP nyingi kwa subdomain ile ile katika mtoa huduma wa DNS. Hapa ndivyo inavyofanya kazi:
Unaweza kupata habari zaidi kuhusu mbinu za kuvuka zilizotangulia na jinsi ya kutumia zana ifuatayo katika mazungumzo [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ).
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) ni zana ya kutekeleza mashambulizi ya [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding). Inajumuisha sehemu muhimu za kurekebisha anwani ya IP ya jina la DNS la seva ya shambulizi hadi anwani ya IP ya mashine ya lengo na kutumikia mzigo wa shambulizi ili kudukua programu zenye udhaifu kwenye mashine ya lengo.
* Tuma ombi la uwakiki ili kupata ufikiaji wa data
* Thibitisha kichwa cha mwenyeji
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Pendekezo la kutuma ombi la awali wakati seva za umma zinataka kupata seva za ndani
<summary><strong>Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa muundo wa PDF** Angalia [**MPANGO WA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Pata [**swag rasmi wa PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**The PEASS Family**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) za kipekee
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au **kikundi cha telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Shiriki mbinu zako za kudukua kwa kuwasilisha PR kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
