CORS - Misconfigurations & Bypass
Last updated
Last updated
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Msimbo wa Kushiriki Rasilimali za Mikoa Mbalimbali (CORS) unawawezesha seva kufafanua ni nani anaweza kufikia mali zao na ni njia zipi za ombi la HTTP zinazoruhusiwa kutoka vyanzo vya nje.
Sera ya same-origin inahitaji kwamba seva inayohitaji rasilimali na seva inayohifadhi rasilimali zishiriki itifaki sawa (mfano, http://), jina la kikoa (mfano, internal-web.com), na bandari (mfano, 80). Chini ya sera hii, ni kurasa za wavuti kutoka kikoa na bandari sawa pekee ndizo zinazoruhusiwa kufikia rasilimali hizo.
Matumizi ya sera ya same-origin katika muktadha wa http://normal-website.com/example/example.html yanaonyeshwa kama ifuatavyo:
| URL iliyofikiwa | Ufikiaji unaruhusiwa? |
|---|---|
| Ndio: Mpango, kikoa, na bandari sawa |
| Ndio: Mpango, kikoa, na bandari sawa |
| Hapana: Mpango na bandari tofauti |
| Hapana: Kikoa tofauti |
| Hapana: Kikoa tofauti |
| Hapana: Bandari tofauti* |
*Internet Explorer inapuuzilia mbali nambari ya bandari katika kutekeleza sera ya same-origin, hivyo kuruhusu ufikiaji huu.
Access-Control-Allow-Origin HeaderHeader hii inaweza kuruhusu mikoa mingi, thamani ya null, au wildcard *. Hata hivyo, hakuna kivinjari kinachounga mkono mikoa mingi, na matumizi ya wildcard * yanategemea mipaka. (Wildcard lazima itumike peke yake, na matumizi yake pamoja na Access-Control-Allow-Credentials: true hayaruhusiwi.)
Header hii inatolewa na seva kama jibu la ombi la rasilimali ya mikoa tofauti lililoanzishwa na tovuti, huku kivinjari kikiongeza kiotomatiki header ya Origin.
Access-Control-Allow-Credentials HeaderKwa kawaida, maombi ya mikoa tofauti yanafanywa bila akidi kama vile vidakuzi au header ya Uidhinishaji. Hata hivyo, seva ya mikoa tofauti inaweza kuruhusu kusoma jibu wakati akidi zinatumwa kwa kuweka header ya Access-Control-Allow-Credentials kuwa true.
Ikiwa imewekwa kuwa true, kivinjari kitaweza kutuma akidi (vidakuzi, vichwa vya uidhinishaji, au vyeti vya mteja wa TLS).
Wakati wa kuanzisha ombi la kuvuka eneo chini ya hali maalum, kama vile kutumia mbinu isiyo ya kawaida ya HTTP (chochote isipokuwa HEAD, GET, POST), kuanzisha vichwa vipya, au kutumia thamani maalum ya kichwa cha Content-Type, ombi la awali linaweza kuhitajika. Ombi hili la awali, linalotumia mbinu ya OPTIONS, linatumika kuarifu seva kuhusu nia za ombi la kuvuka eneo linalokuja, ikiwa ni pamoja na mbinu za HTTP na vichwa inavyokusudia kutumia.
Itifaki ya Cross-Origin Resource Sharing (CORS) inahitaji ukaguzi huu wa awali ili kubaini uwezekano wa operesheni ya kuvuka eneo iliyohitajika kwa kuthibitisha mbinu, vichwa, na uaminifu wa chanzo. Kwa ufahamu wa kina wa hali zipi zinazoepusha hitaji la ombi la awali, rejelea mwongozo wa kina ulioandikwa na Mozilla Developer Network (MDN).
Ni muhimu kutambua kwamba ukosefu wa ombi la awali hauondoi hitaji la jibu kubeba vichwa vya idhini. Bila vichwa hivi, kivinjari hakiwezi kushughulikia jibu kutoka kwa ombi la kuvuka eneo.
Fikiria mfano ufuatao wa ombi la awali lililokusudia kutumia mbinu ya PUT pamoja na kichwa maalum kinachoitwa Special-Request-Header:
Katika majibu, seva inaweza kurudisha vichwa vinavyoashiria mbinu zilizokubaliwa, asili iliyoruhusiwa, na maelezo mengine ya sera ya CORS, kama inavyoonyeshwa hapa chini:
Access-Control-Allow-Headers: Kichwa hiki kinaeleza ni vichwa gani vinaweza kutumika wakati wa ombi halisi. Kimewekwa na seva kuashiria vichwa vinavyoruhusiwa katika maombi kutoka kwa mteja.
Access-Control-Expose-Headers: Kupitia kichwa hiki, seva inamjulisha mteja ni vichwa gani vinaweza kufichuliwa kama sehemu ya jibu mbali na vichwa vya jibu rahisi.
Access-Control-Max-Age: Kichwa hiki kinaonyesha ni kwa muda gani matokeo ya ombi la awali yanaweza kuhifadhiwa. Seva inaweka muda wa juu, kwa sekunde, ambao taarifa iliyorejeshwa na ombi la awali inaweza kutumika tena.
Access-Control-Request-Headers: Inayotumika katika maombi ya awali, kichwa hiki kimewekwa na mteja kuijulisha seva ni vichwa gani vya HTTP ambavyo mteja anataka kutumia katika ombi halisi.
Access-Control-Request-Method: Kichwa hiki, pia kinachotumika katika maombi ya awali, kimewekwa na mteja kuashiria ni njia gani ya HTTP itakayokuwa ikitumika katika ombi halisi.
Origin: Kichwa hiki kimewekwa kiotomatiki na kivinjari na kinaonyesha asili ya ombi la kuvuka mipaka. Kinatumika na seva kutathmini ikiwa ombi linalokuja linapaswa kuruhusiwa au kukataliwa kulingana na sera ya CORS.
Kumbuka kwamba kawaida (kutegemea aina ya maudhui na vichwa vilivyowekwa) katika ombio la GET/POST hakuna ombi la awali linalotumwa (ombio linatumwa moja kwa moja), lakini ikiwa unataka kufikia vichwa/mwili wa jibu, lazima iwe na kichwa Access-Control-Allow-Origin kinachoruhusu. Hivyo, CORS hailindi dhidi ya CSRF (lakini inaweza kuwa na msaada).
Access-Control-Request-Local-Network: Kichwa hiki kimejumuishwa katika ombi la mteja kuashiria kwamba uchunguzi unalenga rasilimali ya mtandao wa ndani. Kinatumika kama alama kuijulisha seva kwamba ombi linatoka ndani ya mtandao wa ndani.
Access-Control-Allow-Local-Network: Katika majibu, seva zinatumia kichwa hiki kuwasiliana kwamba rasilimali iliyohitajika inaruhusiwa kushirikiwa na vyombo vya nje ya mtandao wa ndani. Kinatumika kama mwanga wa kijani kwa kushiriki rasilimali kati ya mipaka tofauti ya mtandao, kuhakikisha ufikiaji ulio na udhibiti huku ukihifadhi itifaki za usalama.
Jibu halali linaloruhusu ombi la mtandao wa ndani linahitaji kuwa na pia katika jibu kichwa Access-Controls-Allow-Local_network: true :
Kumbuka kwamba IP ya linux 0.0.0.0 inafanya kazi ili kuepuka mahitaji haya ya kufikia localhost kwani anwani hiyo ya IP haichukuliwi kama "ya ndani".
Pia inawezekana kuepuka mahitaji ya Mtandao wa Ndani ikiwa utatumia anwani ya IP ya umma ya mwisho wa ndani (kama anwani ya IP ya umma ya router). Kwa sababu katika matukio kadhaa, hata kama IP ya umma inafikiwa, ikiwa ni kutoka kwenye mtandao wa ndani, ufikiaji utawezesha.
Kumbuka kwamba hata kama usanidi ufuatao unaweza kuonekana kuwa na ruhusa nyingi:
This is not allowed by browsers and therefore credentials won't be sent with the request allowed by this.
Imekuwa ikionekana kwamba kuweka Access-Control-Allow-Credentials kuwa true ni sharti la awali kwa mashambulizi mengi halisi. Kuweka hii kunaruhusu kivinjari kutuma akidi na kusoma jibu, kuimarisha ufanisi wa shambulizi. Bila hii, faida ya kufanya kivinjari kutoa ombi badala ya kufanya hivyo mwenyewe inapungua, kwani kutumia vidakuzi vya mtumiaji inakuwa vigumu.
Kuna ubaguzi ambapo eneo la mtandao la mwathirika linatumika kama aina ya uthibitisho. Hii inaruhusu kivinjari cha mwathirika kutumika kama proxy, kupita uthibitisho wa IP ili kufikia programu za intranet. Njia hii ina kufanana katika athari na DNS rebinding lakini ni rahisi zaidi kutekeleza.
Origin in Access-Control-Allow-OriginHali halisi ambapo thamani ya kichwa cha Origin inarejelewa katika Access-Control-Allow-Origin ni ya nadharia isiyowezekana kutokana na vizuizi vya kuunganisha vichwa hivi. Hata hivyo, wabunifu wanaotafuta kuwezesha CORS kwa URL nyingi wanaweza kuunda kichwa cha Access-Control-Allow-Origin kwa njia ya kidinamikia kwa kunakili thamani ya kichwa cha Origin. Njia hii inaweza kuleta udhaifu, hasa wakati mshambuliaji anatumia domain yenye jina lililoundwa kuonekana halali, hivyo kudanganya mantiki ya uthibitishaji.
null Originnull origin, iliyoainishwa kwa hali kama vile redirects au faili za HTML za ndani, ina nafasi ya kipekee. Programu zingine zinaweka orodha ya ruhusa kwa null origin ili kuwezesha maendeleo ya ndani, bila kukusudia ikiruhusu tovuti yoyote kuiga null origin kupitia iframe iliyo sanduku, hivyo kupita vizuizi vya CORS.
Wakati wa kukutana na orodha ya maeneo yaliyoruhusiwa, ni muhimu kujaribu fursa za kupita, kama kuongeza eneo la mshambuliaji kwenye eneo lililoruhusiwa au kutumia udhaifu wa kuchukua subdomain. Zaidi ya hayo, matumizi ya mifumo ya kawaida ya kuangalia maeneo yanaweza kupuuzilia mbali tofauti katika kanuni za kutaja maeneo, na kutoa fursa zaidi za kupita.
Mifumo ya Regex kawaida inazingatia wahusika wa alphanumeric, nukta (.), na alama za kuunganisha (-), ikipuuza uwezekano mwingine. Kwa mfano, jina la eneo lililotengenezwa ili kujumuisha wahusika wanaotafsiriwa tofauti na vivinjari na mifumo ya regex linaweza kupita ukaguzi wa usalama. Ushughulikiaji wa wahusika wa alama ya chini katika subdomains na Safari, Chrome, na Firefox unaonyesha jinsi tofauti hizo zinaweza kutumika ili kupita mantiki ya kuangalia maeneo.
Kwa maelezo zaidi na mipangilio ya ukaguzi huu wa kupita: https://www.corben.io/advanced-cors-techniques/ na https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397
Wakuu wa programu mara nyingi wanaweka mifumo ya kujihami ili kulinda dhidi ya matumizi mabaya ya CORS kwa kuorodhesha maeneo ambayo yanaruhusiwa kuomba taarifa. Licha ya tahadhari hizi, usalama wa mfumo si wa kuaminika kabisa. Uwepo wa subdomain moja tu yenye udhaifu ndani ya maeneo yaliyoruhusiwa unaweza kufungua mlango wa matumizi mabaya ya CORS kupitia udhaifu mwingine, kama XSS (Cross-Site Scripting).
Ili kuonyesha, fikiria hali ambapo eneo, requester.com, limeorodheshwa ili kufikia rasilimali kutoka eneo lingine, provider.com. Mipangilio ya upande wa seva inaweza kuonekana kama ifuatavyo:
Katika mpangilio huu, subdomain zote za requester.com zinaruhusiwa kupata. Hata hivyo, ikiwa subdomain, sema sub.requester.com, imeathiriwa na udhaifu wa XSS, mshambuliaji anaweza kutumia udhaifu huu. Kwa mfano, mshambuliaji mwenye ufikiaji wa sub.requester.com anaweza kutumia udhaifu wa XSS ili kupita sera za CORS na kwa uovu kufikia rasilimali kwenye provider.com.
PortSwigger’s URL validation bypass cheat sheet iligundua kuwa baadhi ya vivinjari vinasaidia wahusika wa ajabu ndani ya majina ya kikoa.
Chrome na Firefox vinasaidia viwango vya chini _ ambavyo vinaweza kupita regexes zilizotekelezwa kuthibitisha kichwa cha Origin:
Safari ni mwepesi zaidi kukubali wahusika maalum katika jina la kikoa:
Inawezekana kwamba kwa kutumia uchafuzi wa cache upande wa seva kupitia sindano ya kichwa cha HTTP, udhaifu wa Cross-Site Scripting (XSS) unaweza kuanzishwa. Hali hii inatokea wakati programu inashindwa kusafisha kichwa cha Origin kwa wahusika haramu, ikisababisha udhaifu hasa kwa watumiaji wa Internet Explorer na Edge. Mablua haya yanachukulia (0x0d) kama mkataba halali wa kichwa cha HTTP, na kusababisha udhaifu wa sindano ya kichwa cha HTTP.
Fikiria ombi lifuatalo ambapo kichwa cha Origin kinamanipulika:
Internet Explorer na Edge zinatafsiri jibu kama:
While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page's character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.
For further reading on stored XSS vulnerabilities, see PortSwigger.
Note: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.
Katika hali hii, mfano wa ukurasa wa wavuti unaonyesha maudhui ya kichwa cha HTTP cha kawaida bila uandishi sahihi unakabiliwa. Kwa haswa, ukurasa wa wavuti unarejelea maudhui yaliyojumuishwa katika kichwa cha X-User-id, ambacho kinaweza kujumuisha JavaScript mbaya, kama inavyoonyeshwa na mfano ambapo kichwa kina tag ya picha ya SVG iliyoundwa kutekeleza msimbo wa JavaScript wakati wa kupakia.
Sera za Cross-Origin Resource Sharing (CORS) zinaruhusu kutumwa kwa vichwa vya kawaida. Hata hivyo, bila jibu kutolewa moja kwa moja na kivinjari kutokana na vizuizi vya CORS, matumizi ya sindano kama hiyo yanaweza kuonekana kuwa na mipaka. Kitu muhimu kinatokea wakati wa kuzingatia tabia ya cache ya kivinjari. Ikiwa kichwa cha Vary: Origin hakijabainishwa, inakuwa inawezekana kwa jibu mbaya kuhifadhiwa na kivinjari. Baadaye, jibu hili lililohifadhiwa linaweza kuonyeshwa moja kwa moja wakati wa kuhamasisha URL, kupita hitaji la uwasilishaji wa moja kwa moja wakati wa ombi la awali. Mekanism hii inaboresha uaminifu wa shambulio kwa kutumia caching upande wa mteja.
Ili kuonyesha shambulio hili, mfano wa JavaScript unapatikana, ulioandaliwa kutekelezwa katika mazingira ya ukurasa wa wavuti, kama kupitia JSFiddle. Skripti hii inafanya kitendo rahisi: inatuma ombi kwa URL maalum yenye kichwa cha kawaida kinachojumuisha JavaScript mbaya. Baada ya kukamilika kwa ombi kwa mafanikio, inajaribu kuhamasisha URL ya lengo, huenda ikasababisha utekelezaji wa skripti iliyosambazwa ikiwa jibu limehifadhiwa bila kushughulikia ipasavyo kichwa cha Vary: Origin.
Here's a summarized breakdown of the JavaScript used to execute this attack:
XSSI, pia inajulikana kama Cross-Site Script Inclusion, ni aina ya udhaifu inayotumia ukweli kwamba Sera ya Asili Moja (SOP) haitumiki unapojumuisha rasilimali kwa kutumia lebo ya script. Hii ni kwa sababu scripts zinahitaji kuweza kujumuishwa kutoka kwa maeneo tofauti. Udhaifu huu unaruhusu mshambuliaji kufikia na kusoma maudhui yoyote ambayo yalijumuishwa kwa kutumia lebo ya script.
Udhaifu huu unakuwa muhimu hasa inapohusiana na JavaScript ya dinamik au JSONP (JSON na Padding), hasa wakati taarifa za mamlaka ya mazingira kama vile vidakuzi zinapotumika kwa uthibitishaji. Wakati wa kuomba rasilimali kutoka kwa mwenyeji tofauti, vidakuzi vinajumuishwa, na kuwafanya waweze kupatikana kwa mshambuliaji.
Ili kuelewa na kupunguza udhaifu huu, unaweza kutumia plugin ya BurpSuite inayopatikana kwenye https://github.com/kapytein/jsonp. Plugin hii inaweza kusaidia kubaini na kushughulikia udhaifu wa XSSI katika programu zako za wavuti.
Soma zaidi kuhusu aina tofauti za XSSI na jinsi ya kuzitumia hapa.
Jaribu kuongeza callback parameter katika ombi. Huenda ukurasa ulikuwa umeandaliwa kutuma data kama JSONP. Katika kesi hiyo, ukurasa utarudisha data na Content-Type: application/javascript ambayo itapita sera ya CORS.
Njia moja ya kupita kizuizi cha Access-Control-Allow-Origin ni kwa kuomba programu ya wavuti kufanya ombi kwa niaba yako na kutuma jibu nyuma. Hata hivyo, katika hali hii, akidi za mwathirika wa mwisho hazitapelekwa kwani ombi linafanywa kwa eneo tofauti.
CORS-escape: Chombo hiki kinatoa proxy inayosambaza ombi lako pamoja na vichwa vyake, huku pia ikidanganya kichwa cha Asili ili kufanana na eneo lililoombwa. Hii kwa ufanisi inapita sera ya CORS. Hapa kuna mfano wa matumizi na XMLHttpRequest:
simple-cors-escape: Chombo hiki kinatoa njia mbadala ya kupitisha maombi. Badala ya kupitisha ombi lako kama lilivyo, seva inafanya ombi lake mwenyewe kwa vigezo vilivyotolewa.
Unaweza kupita ukaguzi wa CORS kama e.origin === window.origin kwa kuunda iframe na kutoka kwake kufungua dirisha jipya. Maelezo zaidi katika ukurasa ufuatao:
DNS rebinding kupitia TTL ni mbinu inayotumika kupita hatua fulani za usalama kwa kubadilisha rekodi za DNS. Hapa kuna jinsi inavyofanya kazi:
Mshambuliaji anaunda ukurasa wa wavuti na kumfanya mwathirika aupate.
Mshambuliaji kisha anabadilisha DNS (IP) ya eneo lake mwenyewe ili kuelekeza kwenye ukurasa wa wavuti wa mwathirika.
Kivinjari cha mwathirika kinahifadhi jibu la DNS, ambalo linaweza kuwa na thamani ya TTL (Muda wa Kuishi) ikionyesha ni muda gani rekodi ya DNS inapaswa kuzingatiwa kuwa halali.
Wakati TTL inapoisha, kivinjari cha mwathirika kinafanya ombi jipya la DNS, na kumruhusu mshambuliaji kutekeleza msimbo wa JavaScript kwenye ukurasa wa mwathirika.
Kwa kudumisha udhibiti juu ya IP ya mwathirika, mshambuliaji anaweza kukusanya taarifa kutoka kwa mwathirika bila kutuma vidakuzi vyovyote kwa seva ya mwathirika.
Ni muhimu kutambua kwamba vivinjari vina mifumo ya kuhifadhi ambayo inaweza kuzuia matumizi ya haraka ya mbinu hii, hata na thamani za chini za TTL.
DNS rebinding inaweza kuwa na manufaa kwa kupita ukaguzi wa IP wazi unaofanywa na mwathirika au kwa hali ambapo mtumiaji au bot inabaki kwenye ukurasa mmoja kwa muda mrefu, ikiruhusu cache kuisha.
Ikiwa unahitaji njia ya haraka ya kutumia DNS rebinding, unaweza kutumia huduma kama https://lock.cmpxchg8b.com/rebinder.html.
Ili kuendesha seva yako ya DNS rebinding, unaweza kutumia zana kama DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Hii inahusisha kufichua bandari yako ya ndani 53/udp, kuunda rekodi ya A inayoelekeza kwake (mfano, ns.example.com), na kuunda rekodi ya NS inayoelekeza kwenye subdomain ya A iliyoundwa hapo awali (mfano, ns.example.com). Subdomain yoyote ya subdomain ya ns.example.com itatatuliwa na mwenyeji wako.
Unaweza pia kuchunguza seva inayofanya kazi hadharani kwenye http://rebind.it/singularity.html kwa ufahamu zaidi na majaribio.
DNS rebinding kupitia kufurika kwa cache ya DNS ni mbinu nyingine inayotumika kupita mfumo wa kuhifadhi wa vivinjari na kulazimisha ombi la pili la DNS. Hapa kuna jinsi inavyofanya kazi:
Kwanza, wakati mwathirika anafanya ombi la DNS, linajibiwa kwa anwani ya IP ya mshambuliaji.
Ili kupita ulinzi wa kuhifadhi, mshambuliaji anatumia mfanyakazi wa huduma. Mfanyakazi wa huduma unafurika cache ya DNS, ambayo kwa ufanisi inafuta jina la seva ya mshambuliaji lililohifadhiwa.
Wakati kivinjari cha mwathirika kinapofanya ombi la pili la DNS, sasa kinajibiwa kwa anwani ya IP 127.0.0.1, ambayo kwa kawaida inarejelea localhost.
Kwa kufurika cache ya DNS na mfanyakazi wa huduma, mshambuliaji anaweza kubadilisha mchakato wa kutatua DNS na kulazimisha kivinjari cha mwathirika kufanya ombi la pili, wakati huu likitatuliwa kwa anwani ya IP inayotakiwa na mshambuliaji.
Njia nyingine ya kupita ulinzi wa kuhifadhi ni kwa kutumia anwani nyingi za IP kwa subdomain moja katika mtoa huduma wa DNS. Hapa kuna jinsi inavyofanya kazi:
Mshambuliaji anaunda rekodi mbili za A (au rekodi moja ya A yenye IP mbili) kwa subdomain moja katika mtoa huduma wa DNS.
Wakati kivinjari kinapokagua rekodi hizi, kinapata anwani zote mbili za IP.
Ikiwa kivinjari kitachagua kutumia anwani ya IP ya mshambuliaji kwanza, mshambuliaji anaweza kutoa payload inayofanya maombi ya HTTP kwa eneo hilo hilo.
Hata hivyo, mara mshambuliaji anapopata anwani ya IP ya mwathirika, wanakoma kujibu kivinjari cha mwathirika.
Kivinjari cha mwathirika, kinapogundua kwamba eneo halijibu, kinahamia kutumia anwani ya pili ya IP iliyotolewa.
Kwa kufikia anwani ya pili ya IP, kivinjari kinapita Sera ya Asili Moja (SOP), ikiruhusu mshambuliaji kutumia hii na kukusanya na kuhamasisha taarifa.
Mbinu hii inatumia tabia ya vivinjari wakati anwani nyingi za IP zinatolewa kwa eneo. Kwa kudhibiti kwa makusudi majibu na kubadilisha uchaguzi wa anwani ya IP wa kivinjari, mshambuliaji anaweza kutumia SOP na kufikia taarifa kutoka kwa mwathirika.
Kumbuka kwamba ili kufikia localhost unapaswa kujaribu kuunganisha 127.0.0.1 katika Windows na 0.0.0.0 katika linux. Watoa huduma kama godaddy au cloudflare hawakuniruhusu kutumia ip 0.0.0.0, lakini AWS route53 iliniruhusu kuunda rekodi moja ya A yenye IP 2, moja ikiwa "0.0.0.0"
Kwa maelezo zaidi unaweza kuangalia https://unit42.paloaltonetworks.com/dns-rebinding/
Ikiwa IP za ndani haziruhusiwi, wanaweza kusahau kuzuia 0.0.0.0 (inafanya kazi kwenye Linux na Mac)
Ikiwa IP za ndani haziruhusiwi, jibu na CNAME kwa localhost (inafanya kazi kwenye Linux na Mac)
Ikiwa IP za ndani haziruhusiwi kama majibu ya DNS, unaweza kujibu CNAMEs kwa huduma za ndani kama www.corporate.internal.
Unaweza kupata maelezo zaidi kuhusu mbinu za kupita zilizotajwa hapo awali na jinsi ya kutumia chombo kinachofuata katika mazungumzo Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.
Singularity of Origin ni chombo cha kufanya DNS rebinding mashambulizi. Inajumuisha vipengele muhimu vya kuunganisha anwani ya IP ya jina la seva ya shambulio na anwani ya IP ya mashine lengwa na kutoa payload za shambulio ili kutumia programu dhaifu kwenye mashine lengwa.
Tumia TLS katika huduma za ndani
Omba uthibitisho ili kufikia data
Thibitisha kichwa cha Host
https://wicg.github.io/private-network-access/: Pendekezo la kutuma ombi la awali kila wakati wakati seva za umma zinataka kufikia seva za ndani
Fuzz possible misconfigurations in CORS policies
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
