Misschien omdat er ZOVEEL van dit soort ditjes en datjes zijn die ad-hoc worden toegevoegd als "standaard"?

Ook dat. CSP moet eigenlijk onderdeel zijn van je design framework en kan op de meest gekke plekken gevolgen hebben.
Vaak wordt er pas bij een compleet nieuwe versie aandacht aan gegeven.

En waarom biedt dit extra bescherming?

Wat is de toegevoegde waarde?

Het belangrijkste voordeel van een CSP (content security policy) is,
dat deze het uitbuiten van cross-site scripting kwetsbaarheden verhindert.

Wanneer een applicatie een strict policy gebruikt,
kan een aanvaller niet langer gebruik maken van een XSS kwetsbaarheid,
wanneer de aanvaller die aantreft, om zodoende kwaadaardig script op de webpagina te kunnen uitvoeren.

luntrus

P.S.

Zij die beslissingen nemen, hebben er meestentijds geen verstand van.
Zij die het willen implementeren, doen er in het beslissingstraject veelal niet toe.

Dat is vaak de 'makke' bij dit soort zaken. Kosten gaan voor de baat uit
en dan zit de uiteindelijke rekening vaak onder in de zak.
Zeker na een sucesvolle cyber-aanval.

Check hier: https://cspvalidator.org/#url=https://cspvalidator.org/

No CSP policies in headers or meta elements found at https://www.security.nl/ (ergo 100% secure content only?).

#obserwator

Mijn antwoord op deze vraag is: De meeste websitemakers hebben onvoldoende kennis op het gebied van het bouwen van veilige websites. Opdrachtgevers en werkgevers vragen er niet om. (Hebben liever een extra animatie dan een veiligheidsaudit.)

De gemiddelde website haalt stukken code overal vandaan en dat is moeilijker als je CSP goed wil implementeren, daarom kiezen ze ervoor om CSP niet te implementeren ipv. hun site zo te bouwen dat ze niet afhankelijk zijn al die andere plaatsen waar ze hun code vandaan halen.

Het instellen van een CSP vereist de nodige kennis van hoe een applicatie werkt, zoals de domeinen waarvandaan scripts ingeladen worden. Als je ook nog eens een 'veilige' CSP wil instellen (zonder inline-scripts e.d.) dan ontkom je er vaak niet aan om een applicatie te herschrijven. Dat maakt dat het toepassen van een CSP erg ingrijpend is.

Daar tegenover staat dat de meeste websites gebruik maken van http-only cookies waardoor er al een redelijke bescherming is tegen de impact van XSS-aanvallen. XSS is de voornaamste aanval die voorkomen moet worden met een 'veilige' CSP. Dat gaat uiteraard niet op voor alle websites. Met name sites die Bearer tokens (JWT's e.d.) gebruiken, slaan deze vaak op in de local storage van een browser. Daardoor is de impact van een XSS-aanval veel groter. In die situatie is het juist belangrijk om een 'veilige CSP in te stellen. Meer dan in de situatie dat alle authenticatie via (http-only) sessie cookies werkt.

(Overigens zou je ook gebruik kunnen maken van closures om sessie tokens te beschermen. Deze zijn dan niet meer uit te lezen via local storage. Maar in alle pentesten die ik heb gedaan ben ik dat nog nooit tegen gekomen.)

Wat niet zal helpen is dat:
1) de reporting niet echt goed werkt (je krijgt meldingen over plugins etc die iets aan je site zitten te klussen, kun je niet goed op filteren)
2) CSPv1 onhandig was met al die domeinen, v2 met nonces niet lekker werkt met bv. Google Tag Manager en v3 nog niet goed genoeg in browsers werkt
3) debuggen toch best lastig is als je wat scripts inlaad, zelf met 'script-sample' ingeschakeld.
4) sites nog best vaak veel inline scripts hebben (b.v. etc.).
5) er best wat scripts zijn die je wilt inladen wellicht, maar waar de leveranciers CSP niet goed bij ondersteunen

Mijn tip zou zijn als je begint (en niet wilt opgeven):
Pas het toe op vooral je belangrijkste pagina's (dus je homepage, contactformulier en wellicht je winkelmand of dergelijke als je dat hebt) en wees wat minder streng op al die andere pagina's.

En terechte vraag dus!

Als je code tussen " plaatst is het dan code / opdracht / een boodschap ?

Bijvoorbeeld : bla bla bla functie hier functie daar ; string functie random "Disclose" data "All" bla functie String hash none

C, Overt, Go, assembly ken ik wel


En dan heb je nog: Trumpscript, rockstar, lolcode, Brainf*ck

En Chicken en Piet (ja, het is echt... zie link)

https://www.omnesgroup.com/weirdest-programming/

Maar dan is er nog geen bescherming tegen het volgende: https://portswigger.net/research/evading-csp-with-dom-based-dangling-markup.

De verdediger heeft het altijd veel zwaarder (verdediging tegen van alles en nog wat) dan de eventuele aanvaller, die aan een klein gaatje soms genoeg kan hebben.

luntrus

Precies, wat ook niet helpt is als mensen dingen neerzetten met een aire van "iedereen snapt toch dat dat fout is" zonder
er bij te zeggen wat er dan fout aan is.

Kijk ook eens even hier: https://securityheaders.com/?q=https%3A%2F%2Fwww.security.nl&followRedirects=on

En voldoen we aan moderne internet standaards? https://en.internet.nl/

Op al mijn websites heb ik A+ op securityheaders.com.
Maar mijn wordpress site krijg ik niet van A naar A+ omdat nonces implementeren niet te doen is in WP.
Zonet een CSP plugin getest die gebruikt ook geen nonces die headers kan ik er zelf ook wel inzetten.

Als iemand een oplossing heeft om geen script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; meer te hoeven gebruiken, hoe ik in wordpress nonces kan implementeren dan lees ik dar graag.

Lees hier: https://www.hostinger.com/tutorials/wordpress-nonce

luntrus

@luntrus
Ik ga het bestuderen.
Enorm bedankt!

Omdat inline CSS en inline EcmeScript (w/o JavaScript) al als onacceptabel groot risico gezien wordt.

Dus waarom niemand het toepast is omdat niemand dan nog iets kan.
Inderdaad heel veilig, maar niet heel gebruiksvriendelijk; tijdrovend en 0,0 van nut om van A naar B te komen.
Dus ja, success met de opdrachtgever / je CEO / jezelf te motiveren.

Offtopic, wat van mij wel een standaard mag worden is een security.txt.

Dat zou contact zoeken met websitemakers/bouwers zoveel makkelijker maken.

Security.txt is volgens https://securitytxt.org/een voorgestelde standaard, en IEFT heeft het als RFC gepubliceerd:
https://datatracker.ietf.org/doc/html/rfc9116. Voor IEFT is het geen "internet standards track" maar een informatief document over iets waar consensus over is. Ik betwijfel of er in de praktijk een noemenswaardig verschil is tussen die twee, er is een eenduidige beschrijving en iedereen die dit op een manier wil doen die compatibel is met wat de rest doet kan ermee aan de slag.

Misschien bedoel je met "standaard" dat iedereen het ook toepast. Maar een standaard is op zich geen verplichting maar een norm waar je je wel of niet aan kan houden. Een plicht is het pas als de wetgever, of op kleinere schaal bijvoorbeeld een werkgever, voorschrijft dat een norm gehanteerd moet worden.

CSP is daar een voorbeeld van. Dat is een concept-standaard van het W3C (dus nog niet definitief vastgesteld maar al wel ondersteund door browsers), maar dat betekent niet dat elke website het ook toepast. En dat gebeurt ook niet per se als het de concept-status verlaat en een echte standaard wordt. Het is namelijk geen verplichting, het vertelt alleen dat als je het toepast hoe je het dan goed doet.

Wellicht dat die ditjes en datjes nuttig zijn voor de beveiliging, en schade te voorkomen. Heb je ook een slot op je voordeur van je huis bijvoorbeeld, of is dat ook allemaal ''teveel gedoe'' ;))

Fijn dat het niet verplicht wordt door derden. Maar is dat de meeste essentiele vraag ? Of is de vraag toch meer of je het wel/niet nodig hebt om je te beschermen tegen risico's, in het kader van de beveiliging. Onveilig, maar compliant, daar heb je geen bal aan, leuk voor check-in-the-box monkeys.

Daar heb je geen bal aan. Ik hoop dat autoriteiten dat nooit gaan beweren over E2E encryptie.
Want dan zijn we al aardig in de aap gelogeerd. Dat zijn we trouwens toch al flink.
Die aap, een middeleeuws idee, dat was de imitator G*ds, de duvel dus in eigen persoon - Saytan, de Asmodee.

De onderstaande gelinkte site is wel niet kwaadaardig, maar als http site behorend tot een verdwijnende webbeeld.
Zo te openen dus met een tooltje als IntelliTamper en de gescande webserver is dan een open boek.

http://security.nl.domainsdata.org/ -> https://dnslytics.com/domain/domainsdata.org

luntrus

Een slot is ook wel de meest basale vorm van beveiliging op je huis. Heb je naast sloten ook dievenklauwen op elk raam? Heb je een anti-inbraak-alarm? Heb je een kluis waar je elke nacht je waardevolle spullen in opbergt?

Als het op brand aankomt, heb je rookmelders hangen op elke verdieping? Een brandblus-deken in je keuken hangen? Een brandblusapparaat staan dat periodiek wordt onderhouden? Zijn de deuren in je woning voldoende brandvertragend? Oefen je regelmatig met je gezin op een evacuatieplan? Heb je een sprinkler-installatie?

En als het op gezondheid aankomt, heb je een EHBO-doos liggen? Vernieuw je de inhoud van die doos regelmatig met nieuwe producten volgens de laatste aanbevelingen van de GGD? Heb je op elke verdieping een CO-detector hangen? Heb je in de koelkast een aantal anti-brandwonden-pleisters klaarliggen? Volg je zelf regelmatig een EHBO-cursus om te weten wat te doen bij ongelukken?

Allemaal redelijk nuttige en grotendeels basic veiligheidsmaatregelen die indereen in of rond zijn/haar huis zou kunnen en misschien moeten nemen om schade te voorkomen. Toch durf ik te stellen dat vrijwel niemand al die maatregelen daadwerkelijk geïmplementeerd heeft.

Het is net als met al deze dingen gewoon een kwestie van kennis, middelen, risico, en baten. Als één daarvan niet voldoende aanwezig is, dan houdt het een beetje op.

Dan krijgen we dus dit soort overzichtjes:


En in dit geval is dit wel het minimale wat aan onveilige headers kan worden aangewezen. Bron = sucuri site check info.

#webproxy

Ik bedoel inderdaad dat men het meer gaat toepassen, ook daadwerkelijk gaat gebruiken. Wat je ook wel ziet is als je een pagina inspecteerd dat hem bovenaan de HTML een Break aanmaakt met daarin wat gegevens voor degene die daar naar opzoek is. Dus waar drop je een vulnerability e.d.