CSP style-src 'nonce-ABCDE', nonce in javascript gebruiken?

[Juup]

In een webapp hebben we een CSP header die er ongeveer zo uitziet:

code:

Content-Security-Policy: ... style-src 'self' 'nonce-YGftq1hZU5xgmA' ...

Nu willen we een javascript library gebruiken die aangeeft dat deze style nonce (niet script nonce!) bij het initialiseren van de lib meegegeven moet worden (bron: mui csp).

Daarvoor moet deze nonce dus op een of andere manier door de app aan de javascript context worden blootgesteld.

Dit voelt alsof je het hele nonce mechanisme verslaat, je kunt dan net zo goed 'unsafe-inline' aanzetten?

[Soultaker]

Als ik het goed lees, gaat die pagina specifiek over server-side rendering. Het is wel “javascript” maar die wordt dus op de server uitgevoerd, en de client krijgt de nonce nooit te zien.

[Juup]

Ah zou dat het zijn?
Dat zou het wel verklaren.
Maar ik kan me niet voorstellen dat die emotionCache (alleen) voor SSR wordt gebruikt, ik neem aan dat die ook naar de client gaat - en dus de nonce ook.

[Soultaker]

Ik ben niet heel bekend met dit framework, maar ik vermoed dat je gelijk hebt, en dat de nonce ook naar de client wordt gestuurd uiteindelijk (of tenminste in sommige gevallen). In dat geval is het inderdaad een verzwakking van het systeem, hoewel een aanvaller de nonce dan nog steeds niet kan uitlezen zonder javascript code te kunnen uitvoeren op de pagina, wat feitelijk een groter gevaar is dan alleen het kunnen toevoegen van stylesheets.

De conclusie uit de TS lijkt me dus te sterk:

Dit voelt alsof je het hele nonce mechanisme verslaat, je kunt dan net zo goed 'unsafe-inline' aanzetten?

De meeste aanvallen die mogelijk zijn met unsafe-inline worden verslagen door de nonce, ook als je 'm naar de client stuurt, namelijk alle aanvallen waarbij de aanvaller wel stylesheets kan plaatsen maar geen javascript code kan uitvoeren.

[frAmEd]

Voor iedere request is de nonce uniek. In dat opzicht is het niet erg dat de client de nonce krijgt, want bij een volgende request kun je deze nonce niet misbruiken voor een attack.

[Juup]

frAmEd schreef op zondag 3 augustus 2025 @ 08:48:
Voor iedere request is de nonce uniek. In dat opzicht is het niet erg dat de client de nonce krijgt, want bij een volgende request kun je deze nonce niet misbruiken voor een attack.

Behalve als de aanvaller (zoals Soultaker al zei) js code kan uitvoeren.
Dan kan er mbv de style-nonce ook styling gezet worden (bv om een bank-inlog site perfect na te maken of om CSS parser bugs te misbruiken).

[frAmEd]

Juup schreef op zondag 3 augustus 2025 @ 10:28:
[...]

Behalve als de aanvaller (zoals Soultaker al zei) js code kan uitvoeren.
Dan kan er mbv de style-nonce ook styling gezet worden (bv om een bank-inlog site perfect na te maken of om CSS parser bugs te misbruiken).

CSP werkt dan ook alleen echt goed als je niet willekeurig scripts toelaat. Je gebruikt dus ook nonces voor de scripts die je toelaat.

[Juup]

frAmEd schreef op zondag 3 augustus 2025 @ 10:51:
CSP werkt dan ook alleen echt goed als je niet willekeurig scripts toelaat. Je gebruikt dus ook nonces voor de scripts die je toelaat.

Klopt, maar dat is het punt niet.
Als je (onverhoopt) een XSS bug hebt (even een (slecht) voorbeeld: omdat je iets uit de URL klakkeloos in de DOM zet met .innerHTML) dan is het fijn als de aanvaller geen/weinig styling kan gebruiken.

[Spiral]

De server stuurt de toegestane CSP header naar de cliënt. Daarin staan de valide nonces en acties. (regels). Bij elk request genereert de server nieuwe nonces.

De HTML wordt "continu" gevalideerd door de browser met de CSP regels in de header. Als er dynamisch nog js of styles worden ingeladen, dan moeten deze nog steeds voldoen aan de CSP.

Een comment met XSS kan dan bijvoorbeeld niet leiden tot het injecteren van js en/of styles. Want deze moeten wel in de whitelist staan in de CSP header van de browser.

Doordat de server bij elk request nieuwe nonces genereert kan de aanvaller niet op de huidige nonce anticiperen.

Het is een security feature van de browser en niet van de server.

[Juup]

Spiral schreef op woensdag 6 augustus 2025 @ 08:57:
Een comment met XSS kan dan bijvoorbeeld niet leiden tot het injecteren van js en/of styles.

Dat kan dus juist wel als je unsafe-inline in de CSP gebruikt of (en daar gaat de discussie over) als de style-nonce in JS beschikbaar is.

[Spiral]

Juup schreef op woensdag 6 augustus 2025 @ 13:01:
[...]

Dat kan dus juist wel als je unsafe-inline in de CSP gebruikt of (en daar gaat de discussie over) als de style-nonce in JS beschikbaar is.

Dit voelt alsof je het hele nonce mechanisme verslaat, je kunt dan net zo goed 'unsafe-inline' aanzetten?

Ik lees dat niet zo. Unsafe-inline moet je inderdaad niet gebruiken, maar dat hoeft toch ook niet? Op welke wijze wordt nu het mechanisme volgens jou verslagen?

[Juup]

Om mezelf te quoten:

Juup schreef op zondag 3 augustus 2025 @ 10:28:
Behalve als de aanvaller (zoals Soultaker al zei) js code kan uitvoeren.
Dan kan er mbv de style-nonce ook styling gezet worden (bv om een bank-inlog site perfect na te maken of om CSS parser bugs te misbruiken).

[Spiral]

Ik mis even het gedeelte hoe een aanvaller js kan injecteren op de html pagina in de browser als je de CSP op orde hebt en geen unsafe-inline in de CSP headers hebt staan.

In het artikel van MUI waar je naar verwees lees ik zo snel niet dat je unsafe-inline nodig hebt.

En ja, als je in de CSP headers unsafe-inline hebt toegevoegd dan is het wel mogelijk.

Wellicht begrijp ik niet waar je op doelt.

[frAmEd]

Juup schreef op woensdag 6 augustus 2025 @ 13:27:
Om mezelf te quoten:

[...]

Als een aanvaller JS code kan uitvoeren, dan heb je al 'verloren' . De hele bedoeling van CSP is dat de aanvaller dat dus niet kan doen.

Een voorbeeld van een 'veilige' CSP:
default-src 'self';
script-src 'self' 'nonce-<unieke_nonce>' 'strict-dynamic';
style-src 'self' 'nonce-<unieke_nonce>';

Dit zorgt ervoor dat:
- alleen JOUW scripts met de door jou voor elke request uniek gegenereerde nonce worden uitgevoerd
- alleen JOUW styles met de door jou voor elke request uniek gegenereerde nonce worden uitgevoerd
-met strict dynamic kunnen jouw eigen toegestane scripts nieuwe scripts laden indien nodig

Een aanvaller kan dan alleen eigen scripts uitvoeren als die VOORDAT die een request gedaan heeft al weet welke nonce geldig gaat zijn voor script en die gerade nonce dan toevoegt aan zijn script. Andere aanvalsvectoren blijven natuurlijk bestaan zoals vulnerabilities in je eigen scripts of een gehackte server, maar je hebt hiermee het inladen van malicious scripts na het laden van een pagina voorkomen.

Het is dus niet de bedoeling unsafe-inline in combinatie met een nonce te gebruiken. Dit is ook een tegenstrijdig beleid. Je zegt dan in feite: alleen een script of style met een unieke nonce is akkoord maar tegelijkertijd vind ik al het andere ook goed.

[Juup]

Spiral schreef op woensdag 6 augustus 2025 @ 14:14:
Ik mis even het gedeelte hoe een aanvaller js kan injecteren op de html pagina in de browser als je de CSP op orde hebt en geen unsafe-inline in de CSP headers hebt staan.

Dat kan bv doordat je een server-side vulnerability hebt die de aanvaller kan misbruiken om js code te injecteren (bv in request voor een js file)

In het artikel van MUI waar je naar verwees lees ik zo snel niet dat je unsafe-inline nodig hebt.

Nee, dat heb je bij hun oplossing inderdaad niet nodig.

[Juup]

frAmEd schreef op woensdag 6 augustus 2025 @ 14:15:
Als een aanvaller JS code kan uitvoeren, dan heb je al 'verloren' . De hele bedoeling van CSP is dat de aanvaller dat dus niet kan doen.

Dat is ten dele waar. Het doel van een strakke CSP header is ook om de schade zoveel mogelijk te beperken als een aanvaller onverhoopt toch ergens een ingang weet te vinden (bv aan de serverkant).

Het is dus niet de bedoeling unsafe-inline in combinatie met een nonce te gebruiken.

Helemaal mee eens. Ik stel dit dan ook nergens voor (hoop ik).

[Spiral]

Juup schreef op woensdag 6 augustus 2025 @ 17:50:
[...]
Dat kan bv doordat je een server-side vulnerability hebt die de aanvaller kan misbruiken om js code te injecteren (bv in request voor een js file)
[...]

Ja dat klopt, maar dan neemt de initiële TS een hele andere wending. Ik bekeek het vanuit de context van CSP. Om dat te mitigeren heb je daarvoor weer andere tooling die dat doet, zoals Mend, Snyk, Fortify en/of anderen.

Als je server niet gecompromiteerd is, dan is een goed geconfigureerde CSP een first line of defense tegen o.a. xss.

Nogmaals, je beschermt met CSP niet je applicatie of je server, maar de eindgebruiker. Als de gebruiker een browser gebruikt die geen CSP ondersteund dan is die eindgebruiker kwetsbaar.