<summary><strong>Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA USAJILI**](https://github.com/sponsors/carlospolop)!
* Pata [**bidhaa rasmi za PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) ya 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 kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
Mkataba wa **Kushiriki Rasilmali kati ya Mipaka (CORS)** unaruhusu **watumishi kuamua ni nani anaweza kupata mali zao** na **njia za ombi za HTTP zipi zinaruhusiwa** kutoka vyanzo vya nje.
Sera ya **asili sawa** inahitaji kwamba **mtumishi anayeomba** rasilimali na mtumishi anayehifadhi **rasilimali** washiriki itifaki sawa (k.m., `http://`), jina la uwanja (k.m., `internal-web.com`), na **bandari** (k.m., 80). Chini ya sera hii, kurasa za wavuti kutoka kwa uwanja na bandari sawa tu ndio zinaruhusiwa kupata rasilimali.
Kichwa hiki kinaweza kuruhusu **asili nyingi**, thamani ya **`null`**, au alama ya mwitikio wa **`*`**. Walakini, **kivinjari hakisaidii asili nyingi**, na matumizi ya alama ya mwitikio `*` yanategemea **vizuizi**. (Alama ya mwitikio inapaswa kutumika peke yake, na matumizi yake pamoja na `Access-Control-Allow-Credentials: true` hayaruhusiwi.)
Kichwa hiki **hutolewa na mtumishi** kujibu ombi la rasilimali kati ya mipaka lililoanzishwa na wavuti, na kivinjari kiotomatiki huongeza kichwa cha `Origin`.
Kwa **chaguo-msingi**, maombi ya mipaka ya asili hufanywa bila sifa kama vidakuzi au kichwa cha Uthibitishaji. Walakini, mtumishi wa mipaka ya asili anaweza kuruhusu kusoma kwa jibu wakati sifa zinatumwa kwa kuweka kichwa cha `Access-Control-Allow-Credentials` kuwa **`kweli`**.
Unapoanzisha ombi la mikoa tofauti chini ya hali maalum, kama kutumia **njia ya HTTP isiyo ya kawaida** (chochote kisichokuwa HEAD, GET, POST), kuingiza **vichwa vipya**, au kutumia thamani maalum ya **kichwa cha Aina ya Yaliyomo**, inaweza kuhitajika ombi la kabla ya safari. Ombi hili la awali, likitumia njia ya **`OPTIONS`**, hutumika kumjulisha mtandao wa seva kuhusu nia ya ombi la baadaye la mikoa tofauti, ikiwa ni pamoja na njia za HTTP na vichwa itakavyotumia.
Itifaki ya **Kugawana Rasilmali kwa Vyanzo vya Mijini (CORS)** inahitaji ukaguzi huu wa kabla ya safari ili kubaini uwezekano wa operesheni ya mikoa tofauti inayotakiwa kwa kuthibitisha njia zilizoruhusiwa, vichwa, na uaminifu wa asili. Kwa uelewa wa kina wa hali zipi zinazopuuza haja ya ombi la kabla ya safari, tazama mwongozo kamili uliotolewa na [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests).
Ni muhimu kutambua kwamba **ukosefu wa ombi la kabla ya safari haimaanishi kutokuwepo kwa hitaji la majibu kubeba vichwa vya idhini**. Bila vichwa hivi, kivinjari kimelemazwa katika uwezo wake wa kusindika jibu kutoka kwa ombi la mikoa tofauti.
Katika majibu, server inaweza kurudisha vichwa vinavyoonyesha njia zilizokubalika, asili iliyoruhusiwa, na maelezo mengine ya sera ya CORS, kama inavyoonyeshwa hapa chini:
* **`Access-Control-Allow-Headers`**: Kichwa hiki hufafanua ni vichwa vipi vinaweza kutumika wakati wa ombi halisi. Kinasanidiwa na seva kuonyesha vichwa vilivyoidhinishwa katika maombi kutoka kwa mteja.
* **`Access-Control-Expose-Headers`**: Kupitia kichwa hiki, seva inaarifu mteja ni vichwa vipi vinaweza kuwekwa wazi kama sehemu ya majibu isipokuwa vichwa vya majibu ya kawaida.
* **`Access-Control-Max-Age`**: Kichwa hiki kinaonyesha muda gani matokeo ya ombi la awali yanaweza kuhifadhiwa. Seva inaweka wakati wa kikomo, kwa sekunde, ambapo habari iliyorudishwa na ombi la awali inaweza kutumiwa tena.
* **`Access-Control-Request-Headers`**: Kutumika katika maombi ya awali, kichwa hiki kinasanidiwa na mteja kuarifu seva ni vichwa vya HTTP mteja anataka kutumia katika ombi halisi.
* **`Access-Control-Request-Method`**: Kichwa hiki, pia kutumika katika maombi ya awali, kinasanidiwa na mteja kuonyesha ni njia ipi ya HTTP itatumika katika ombi halisi.
* **`Origin`**: Kichwa hiki kinasanidiwa moja kwa moja na kivinjari na kuonyesha asili ya ombi la msingi wa msingi. Hutumiwa na seva kutathmini ikiwa ombi linalokuja linapaswa kuruhusiwa au kukataliwa kulingana na sera ya CORS.
Tafadhali kumbuka kwamba kawaida (kulingana na aina ya yaliyomo na vichwa vilivyosanidiwa) katika ombi la **GET/POST hakuna ombi la awali linalotumwa** (ombi linatumiwa **moja kwa moja**), lakini ikiwa unataka kupata **vichwa/mwili wa majibu**, lazima iwe na kichwa cha _Access-Control-Allow-Origin_ kuruhusu hilo.\
1.**`Access-Control-Request-Local-Network`**: Kichwa hiki kinaingizwa katika ombi ya mteja kumaanisha kuwa uchunguzi unalenga rasilimali ya mtandao wa ndani. Hutumika kama ishara kuarifu seva kuwa ombi linatoka ndani ya mtandao wa ndani.
2.**`Access-Control-Allow-Local-Network`**: Kama jibu, seva hutumia kichwa hiki kuwasiliana kwamba rasilimali iliyotakiwa inaruhusiwa kushirikishwa na vyama nje ya mtandao wa ndani. Hufanya kama taa ya kijani kwa kushirikisha rasilimali kati ya mipaka tofauti ya mtandao, ikidumisha ufikiaji uliodhibitiwa wakati wa kudumisha itifaki za usalama.
Tafadhali kumbuka kuwa IP ya linux **0.0.0.0** inafanya kazi kwa **kupita** mahitaji haya ya kufikia localhost kwa sababu anwani hiyo ya IP haichukuliwi "ya ndani".
Pia ni pamoja na **kupita mahitaji ya Mtandao wa Ndani** ikiwa unatumia **anwani ya IP ya umma ya mwisho wa ndani** (kama vile anwani ya IP ya umma ya router). Kwa sababu katika matukio kadhaa, hata kama **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 halisi** mengi. Mipangilio hii inaruhusu kivinjari kutuma vitambulisho na kusoma majibu, ikiboresha ufanisi wa shambulio. Bila hii, faida ya kufanya kivinjari kutuma ombi badala ya kufanya mwenyewe hupungua, kwani kutumia vidakuzi vya mtumiaji kunakuwa sio jambo la kufanyika.
Kuna ubaya ambapo eneo la mtandao la muathiriwa linatumiwa kama aina fulani ya uthibitishaji. Hii inaruhusu kivinjari cha muathiriwa kutumiwa kama proksi, kuzunguka uthibitishaji unaotegemea IP kufikia programu za mtandao wa kampuni. Mbinu hii ina fanana na DNS rebinding lakini ni rahisi zaidi kudukua.
Hali halisi ambapo thamani ya kichwa cha `Origin` inatafakariwa katika `Access-Control-Allow-Origin` ni nadra kwa nadharia kutokana na vizuizi vya kuunganisha vichwa hivi. Hata hivyo, watengenezaji wanaotaka kuwezesha CORS kwa URL nyingi wanaweza kuzalisha kichwa cha `Access-Control-Allow-Origin` kwa kuchukua thamani ya kichwa cha `Origin`. Mbinu hii inaweza kuleta mapungufu, hasa wakati muhalifu anatumia kikoa chenye jina lililoundwa kuonekana halali, hivyo kuwapotosha mantiki ya uthibitishaji.
Asili ya `null`, iliyotajwa kwa hali kama vile migeuko au faili za HTML za ndani, inashikilia nafasi ya kipekee. Baadhi ya programu huruhusu asili hii kwa ajili ya maendeleo ya ndani, kwa kubahatisha kuruhusu tovuti yoyote kufanana na asili ya `null` kupitia kipengele cha iframe kilichowekwa kwenye sanduku, hivyo kukiuka vizuizi vya CORS.
Uponapoana orodha ya kikoa, ni muhimu kupima fursa za kupuuza, kama vile kuongeza kikoa cha mshambuliaji kwa kikoa kilichoorodheshwa au kutumia udhaifu wa kuchukua udhibiti wa subdomain. Aidha, mifumo ya kawaida inayotumika kwa uthibitishaji wa kikoa inaweza kusahau nyuso katika mikataba ya uteuzi wa majina ya kikoa, ikionyesha fursa zaidi za kupuuza.
Mifumo ya Regex kawaida inazingatia herufi za alfa-namba, dot (.), na vichwa (-), ikisahau uwezekano mwingine. Kwa mfano, jina la kikoa lililoundwa kuingiza herufi zinazotafsiriwa tofauti na vivinjari na mifumo ya Regex inaweza kupuuza ukaguzi wa usalama. Jinsi Safari, Chrome, na Firefox vinavyoshughulikia herufi za chini katika subdomains inaonyesha jinsi tofauti kama hizo zinaweza kutumika kuzunguka mantiki ya uthibitishaji wa kikoa.
**Kwa habari zaidi na mipangilio ya ukaguzi huu wa kupuuza:** [**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 mifumo ya ulinzi kulinda dhidi ya unyanyasaji wa CORS kwa kuorodhesha kikoa kinachoruhusiwa kuomba habari. Licha ya tahadhari hizi, usalama wa mfumo si wa uhakika. Kuwepo hata wa subdomain moja yenye udhaifu ndani ya vikoa vilivyoorodheshwa kunaweza kufungua mlango wa unyanyasaji wa CORS kupitia udhaifu mwingine, kama vile XSS (Udukuzi wa Tovuti za Msalaba).
Kwa mfano, fikiria hali ambapo kikoa, `requester.com`, kimeorodheshwa kufikia rasilimali kutoka kikoa kingine, `provider.com`. Mipangilio ya upande wa seva inaweza kuonekana kama hii:
Katika hali hii, subdomains zote za `requester.com` zinaruhusiwa kupata upatikanaji. Hata hivyo, ikiwa subdomain, sema `sub.requester.com`, inashambuliwa na udhaifu wa XSS, mshambuliaji anaweza kutumia udhaifu huu. Kwa mfano, mshambuliaji mwenye upatikanaji wa `sub.requester.com` anaweza kutumia udhaifu wa XSS kukiuka sera za CORS na kupata vifaa kwa uovu kwenye `provider.com`.
Kuna uwezekano wa kudanganya cache upande wa seva kupitia kuingiza kichwa cha HTTP, udhaifu wa Stored Cross-Site Scripting (XSS) unaweza kusababishwa. Hali hii inatokea wakati programu inashindwa kusafisha kichwa cha `Origin` kwa herufi haramu, ikiumba udhaifu hasa kwa watumiaji wa Internet Explorer na Edge. Vivinjari hivi vinachukulia (0x0d) kama kikomo halali cha kichwa cha HTTP, ikisababisha udhaifu wa kuingiza kichwa cha HTTP.
Wakati wa kudukua moja kwa moja udhaifu huu kwa kufanya kivinjari cha wavuti kutuma kichwa kilichoharibika sio jambo linalowezekana, ombi lililoundwa kwa makini linaweza kuzalishwa kwa mkono kwa kutumia zana kama Burp Suite. Njia hii inaweza kusababisha cache ya upande wa seva kuokoa jibu na kulisambaza kwa wengine kwa bahati mbaya. Mzigo ulioandaliwa unalenga kubadilisha seti ya herufi ya ukurasa kuwa UTF-7, nambari ya herufi mara nyingi inayohusishwa na udhaifu wa XSS kutokana na uwezo wake wa kuweka herufi kwa njia ambayo inaweza kutekelezwa kama script katika muktadha fulani.
**Angalizo**: Kutumia vibaya udhaifu wa kuingiza kichwa cha HTTP, hasa kupitia sumu ya cache ya upande wa seva, inathibitisha umuhimu mkubwa wa kuthibitisha na kusafisha kila kuingiza cha mtumiaji, ikiwa ni pamoja na vichwa vya HTTP. Tumia mfano thabiti wa usalama ambao unajumuisha uthibitishaji wa kuingiza ili kuzuia udhaifu kama huo.
Katika hali hii, kipengele cha ukurasa wa wavuti kinachoonyesha maudhui ya kichwa cha HTTP cha desturi bila usimbaji sahihi kinaonekana. Kwa usahihi, ukurasa wa wavuti unarudisha nyuma maudhui yaliyomo kwenye kichwa cha `X-User-id`, ambacho kinaweza kuwa na JavaScript mbaya, kama inavyodhihirishwa na mfano ambapo kichwa kinajumuisha lebo ya picha ya SVG iliyoundwa kutekeleza msimbo wa JavaScript unapopakia.
Sera za Kugawiza Rasilmali za Asili (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 cache ya kivinjari. Ikiwa kichwa cha `Vary: Origin` hakijatajwa, inawezekana kwa jibu la uovu kuhifadhiwa na kivinjari. Baadaye, jibu hili lililohifadhiwa linaweza kuonyeshwa moja kwa moja wakati wa kutembelea URL, ikipuuza haja ya kuonyesha moja kwa moja wakati wa ombi la awali. Mfumo huu unaimarisha uaminifu wa shambulio kwa kutumia cache ya upande wa mteja.
Ili kufafanua shambulio hili, mfano wa JavaScript unatolewa, ulioundwa kutekelezwa katika mazingira ya ukurasa wa wavuti, kama vile kupitia JSFiddle. Skripti hii inatekeleza hatua rahisi: inatuma ombi kwa URL iliyospecifikwa na kichwa cha desturi kinachojumuisha JavaScript mbaya. Baada ya kukamilisha ombi kwa mafanikio, inajaribu kutembelea URL ya lengo, ikisababisha utekelezaji wa script iliyosindikwa ikiwa jibu limehifadhiwa bila kushughulikiwa kwa kichwa cha `Vary: Origin`.
XSSI, inayojulikana pia kama Unganuzi wa Skripti wa Tovuti, ni aina ya udhaifu ambao unatumia ukweli kwamba Sera ya Asili Sawa (SOP) haitekelezwi wakati wa kuingiza rasilimali kwa kutumia lebo ya skripti. Hii ni kwa sababu skripti inahitaji kuweza kuingizwa kutoka uwanja tofauti. Udhaifu huu huruhusu mshambuliaji kupata na kusoma yaliyomo yoyote yaliyokuwa yamejumuishwa kwa kutumia lebo ya skripti.
Udhaifu huu unakuwa muhimu hasa linapokuja suala la JavaScript ya kudumu au JSONP (JSON na Padding), hasa wakati habari za mamlaka ya mazingira kama vidakuzi hutumiwa kwa uthibitishaji. Wakati unapoomba rasilimali kutoka kwenye mwenyeji tofauti, vidakuzi huwa ni pamoja, hivyo kufanya yaweze kupatikana na mshambuliaji.
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 maombi yako ya wavuti.
Jaribu kuongeza **`callback`** **parameter** katika ombi. Labda ukurasa ulikuwa umewekwa tayari kutuma data kama JSONP. Katika kesi hiyo, ukurasa utatuma data nyuma na `Content-Type: application/javascript` ambayo itapita sera ya CORS.
Njia moja ya kupita kizuizi cha `Access-Control-Allow-Origin` ni kwa kuomba maombi ya wavuti kufanya ombi kwa niaba yako na kutuma jibu. Hata hivyo, katika hali hii, vyeti vya mwisho waathiriwa havitatumwa kwani ombi linatolewa kwa uwanja tofauti.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Zana hii hutoa proksi ambayo inapeleka ombi lako pamoja na vichwa vyake, wakati pia inadanganya kichwa cha Asili ili kulingana na uwanja ulioombwa. Hii inapita kwa ufanisi sera ya CORS. Hapa kuna matumizi ya mfano na XMLHttpRequest:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Zana hii inatoa njia mbadala ya kufanya proksi ya maombi. Badala ya kupitisha ombi lako kama lilivyo, seva inafanya ombi lake lenyewe na vigezo vilivyowekwa.
Unaweza **kupita ukaguzi wa CORS** kama `e.origin === window.origin` kwa **kuunda iframe** na **kufungua dirisha jipya** kutoka kwake. Taarifa zaidi katika ukurasa ufuatao:
3. Kivinjari cha mwathiriwa kache 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 mwathiriwa hufanya ombi jipya la DNS, kuruhusu mshambuliaji kutekeleza msimbo wa JavaScript kwenye ukurasa wa mwathiriwa.
5. Kwa kudumisha udhibiti juu ya IP ya mwathiriwa, mshambuliaji anaweza kukusanya habari kutoka kwa mwathiriwa bila kutuma vidakuzi kwa seva ya mwathiriwa.
Ni muhimu kutambua kwamba vivinjari vina mifumo ya kuhifadhi akiba ambayo inaweza kuzuia unyanyasaji wa haraka wa mbinu hii, hata na thamani za TTL za chini.
DNS rebinding inaweza kuwa na manufaa kwa kupita ukaguzi wa IP uliofanywa na mwathiriwa au kwa hali ambapo mtumiaji au boti anabaki kwenye ukurasa huo kwa muda mrefu, kuruhusu akiba kumalizika.
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 mwenyewe ya DNS rebinding, unaweza kutumia zana kama **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Hii inahusisha kufunua bandari yako ya ndani 53/udp, kuunda rekodi ya A inayoashiria hiyo (k.m., ns.example.com), na kuunda rekodi ya NS inayoashiria kwa subdomain ya A iliyoundwa hapo awali (k.m., ns.example.com). Kila subdomain ya subdomain ya ns.example.com basi itatatuliwa na mwenyeji wako.
Unaweza pia kuchunguza seva inayofanya kazi hadharani kwa [http://rebind.it/singularity.html](http://rebind.it/singularity.html) kwa uelewa na majaribio zaidi.
DNS rebinding kupitia kufurika kwa akiba ya DNS ni mbinu nyingine inayotumika kupita mifumo ya kuhifadhi akiba ya vivinjari na kulazimisha ombi la pili la DNS. Hivi ndivyo inavyofanya kazi:
1. Kwanza, wakati mwathiriwa anafanya ombi la DNS, jibu linajibiwa na anwani ya IP ya mshambuliaji.
2. Ili kupita ulinzi wa kuhifadhi akiba, mshambuliaji anatumia mfanyakazi wa huduma. Mfanyakazi wa huduma hufurika akiba ya DNS, ambayo kimsingi inafuta jina la mwenyeji wa mshambuliaji lililohifadhiwa.
3. Wakati kivinjari cha mwathiriwa kinapofanya ombi la pili la DNS, sasa jibu linajibiwa na anwani ya IP 127.0.0.1, ambayo kwa kawaida inahusu localhost.
Kwa kufurika akiba ya DNS na mfanyakazi wa huduma, mshambuliaji anaweza kudhibiti mchakato wa ufumbuzi wa DNS na kulazimisha kivinjari cha mwathiriwa kufanya ombi la pili, wakati huu likitatuliwa kwa anwani ya IP inayotakiwa na mshambuliaji.
Njia nyingine ya kupita ulinzi wa kuhifadhi akiba ni kwa kutumia anwani za IP nyingi kwa subdomain moja katika mtoa huduma wa DNS. Hivi ndivyo inavyofanya kazi:
3. Ikiwa kivinjari kinaamua kutumia anwani ya IP ya mshambuliaji kwanza, mshambuliaji anaweza kutumikia mzigo wa data ambao unafanya maombi ya HTTP kwa uwanja huo huo.
4. Hata hivyo, mara tu mshambuliaji anapopata anwani ya IP ya mwathiriwa, wanakoma kujibu kivinjari cha mwathiriwa.
5. Kivinjari cha mwathiriwa, baada ya kugundua kuwa uwanja haipatikani, huendelea kutumia anwani ya pili iliyotolewa ya IP.
6. Kwa kufikia anwani ya pili ya IP, kivinjari kinapita Sera ya Asili Sawa (SOP), kuruhusu mshambuliaji kutumia hii na kukusanya na kusafirisha habari.
Mbinu hii inatumia tabia ya vivinjari wakati anwani za IP nyingi zinapotolewa kwa uwanja. Kwa kudhibiti majibu na kudanganya chaguo la anwani ya IP ya kivinjari, mshambuliaji anaweza kutumia SOP na kupata habari kutoka kwa mwathiriwa.
Tafadhali kumbuka kwamba ili kufikia localhost unapaswa kujaribu kurekebisha **127.0.0.1** kwenye Windows na **0.0.0.0** kwenye linux.\
Watoa huduma kama godaddy au cloudflare hawakuniruhusu kutumia anwani ya IP 0.0.0.0, lakini AWS route53 iliniruhusu kuunda rekodi moja ya A na IP 2 ikiwa mojawapo ni "0.0.0.0"
Unaweza kupata habari zaidi kuhusu mbinu za kuvuka zilizopita na jinsi ya kutumia zana ifuatayo kwenye mazungumzo [Gerald Doussot - Hali ya Mashambulizi ya DNS Rebinding & Umoja wa Asili - Mkutano wa DEF CON 27](https://www.youtube.com/watch?v=y9-0lICNjOQ).
[**`Umoja wa Asili`**](https://github.com/nccgroup/singularity) ni zana ya kufanya mashambulizi ya [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding). Inajumuisha vipengele muhimu vya kurejesha anwani ya IP ya jina la DNS la seva ya shambulizi kwa anwani ya IP ya mashine ya lengo na kutumikia mzigo wa mashambulizi kwa kutumia programu dhaifu kwenye mashine ya lengo.
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Pendekezo la kutuma ombi la awali daima wakati seva za umma zinataka kupata seva za ndani
<summary><strong>Jifunze kuhusu kuvamia AWS kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Pata [**bidhaa rasmi za PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) ya 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)**.**
