Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Content Security Policy: vaak te omzeilen
Heb je ooit geadviseerd om Content Security Policy (CSP) te gebruiken om een nog mogelijke onbekende XSS op site alvast (gedeeltelijk) te kunnen mitigeren? Of heb je CSP zelf geïmplementeerd op een site? Dan is het nu tijd om nog eens heel kritisch te kijken of de uiteindelijke implementatie niet te omzeilen is!
Vier Google werknemers die CSP implementaties eens onder de loop namen troffen veel gemaakte fouten aan.
Slidepack op: https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum?slide=9
Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS), the top security vulnerability in modern web applications. In this paper, we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies. We base our Internet-wide analysis on a search engine corpus of approximately 100 billion pages from over 1 billion hostnames; the result covers CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies – the most comprehensive study to date. We introduce the security-relevant aspects of the CSP specification and provide an in-depth analysis of its threat model, focusing on XSS protections. We identify three common classes of CSP bypasses and explain how they subvert the security of a policy. We then turn to a quantitative analysis of policies deployed on the Internet in order to understand their security benefits. We observe that 14 out of the 15 domains most commonly whitelisted for loading scripts contain unsafe endpoints; as a consequence, 75.81% of distinct policies use script whitelists that allow attackers to bypass CSP. In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS. Finally, we propose the ’strict-dynamic’ keyword, an addition to the specification that facilitates the creation of policies based on cryptographic nonces, without relying on domain whitelists. We discuss our experience deploying such a nonce-based policy in a complex application and provide guidance to web authors for improving their policies.
Bron: https://research.google.com/pubs/pub45542.html
Volledige artikel: https://static.googleusercontent.com/media/research.google.com/nl//pubs/archive/45542.pdf
Vier Google werknemers die CSP implementaties eens onder de loop namen troffen veel gemaakte fouten aan.
Slidepack op: https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum?slide=9
Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS), the top security vulnerability in modern web applications. In this paper, we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies. We base our Internet-wide analysis on a search engine corpus of approximately 100 billion pages from over 1 billion hostnames; the result covers CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies – the most comprehensive study to date. We introduce the security-relevant aspects of the CSP specification and provide an in-depth analysis of its threat model, focusing on XSS protections. We identify three common classes of CSP bypasses and explain how they subvert the security of a policy. We then turn to a quantitative analysis of policies deployed on the Internet in order to understand their security benefits. We observe that 14 out of the 15 domains most commonly whitelisted for loading scripts contain unsafe endpoints; as a consequence, 75.81% of distinct policies use script whitelists that allow attackers to bypass CSP. In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS. Finally, we propose the ’strict-dynamic’ keyword, an addition to the specification that facilitates the creation of policies based on cryptographic nonces, without relying on domain whitelists. We discuss our experience deploying such a nonce-based policy in a complex application and provide guidance to web authors for improving their policies.
Bron: https://research.google.com/pubs/pub45542.html
Volledige artikel: https://static.googleusercontent.com/media/research.google.com/nl//pubs/archive/45542.pdf
Reacties (8)
06-09-2016, 11:29 door
Erik van Straten
Dank voor jouw bijdrage! Ik weet nog te weinig van CSP en moet me maar eens goed inlezen.
De vraag is wel of websites altijd zo complex moeten zijn, met als consequentie dat je CSP nodig hebt in een poging alle gaten te dichten. Om er, gezien de uitslag van dit onderzoek, vervolgens achter te komen dat je half werk hebt geleverd.
Persoonlijk denk ik dat de complexiteit in veel gevallen omlaag moet - vaak zijn websites "lappendekens" waarbij die lappen uit alle hoeken en gaten van het Internet lijken te komen.
De vraag is wel of websites altijd zo complex moeten zijn, met als consequentie dat je CSP nodig hebt in een poging alle gaten te dichten. Om er, gezien de uitslag van dit onderzoek, vervolgens achter te komen dat je half werk hebt geleverd.
Persoonlijk denk ik dat de complexiteit in veel gevallen omlaag moet - vaak zijn websites "lappendekens" waarbij die lappen uit alle hoeken en gaten van het Internet lijken te komen.
Het misbruik maken van widget scripts heeft vaak succes, want niemand anders als facebook en consorten weten de beveiligingsgaten te zitten en te exploiteren voor eigen gewin. Maar niemand ziet dat als misbruik, maar als legitiem.
Een voorbeeld om even achterover te leunen en over de consequenties hiervan na te denken.
Even een voorbeeld hoe de beveiliging zou kunnen falen:
Headers: strict-transport-security: max -age=60 blokkeert elke mogelijke oorsprong, van waarvan een script kan worden geladen. Gelukkig voor de hacker worden bookmarklets er niet door geblokkeerd.
Een bookmarklet gebaseerd op gewijzigde widget code kan dus een wijze zijn om de beveiliging te omzeilen.
Bron: bookmarkleteer dot com
Vraagje?
Zijn uw SRI Hashes juist gegenereerd, het is vaak een "last line of defense" in de "same origin" benadering,
zeker voor externe third party code. Scan: https://sritest.io/ en generator: https://www.srihash.org
Een voorbeeld om even achterover te leunen en over de consequenties hiervan na te denken.
Even een voorbeeld hoe de beveiliging zou kunnen falen:
Headers: strict-transport-security: max -age=60 blokkeert elke mogelijke oorsprong, van waarvan een script kan worden geladen. Gelukkig voor de hacker worden bookmarklets er niet door geblokkeerd.
Een bookmarklet gebaseerd op gewijzigde widget code kan dus een wijze zijn om de beveiliging te omzeilen.
Bron: bookmarkleteer dot com
Vraagje?
Zijn uw SRI Hashes juist gegenereerd, het is vaak een "last line of defense" in de "same origin" benadering,
zeker voor externe third party code. Scan: https://sritest.io/ en generator: https://www.srihash.org
Er schijnen zelfs online diensten voor te bestaan zoals: Any Origin: http://anyorigin.com/ (donatie betaalde service).
Lees achtergrond info: https://stackoverflow.com/questions/3076414/ways-to-circumvent-the-same-origin-policy
Lees achtergrond info: https://stackoverflow.com/questions/3076414/ways-to-circumvent-the-same-origin-policy
Geen CSP protectie
Onveranderd sinds 26 augustus 2016
Misschien is die CSP protectie gewoon niet belangrijk, is het niet alleen voor beheerders maar ook voor hackers te moeilijk en is daarom een cloudflare abonnementje voor verreweg de meeste websites meer dan voldoende?
Onveranderd sinds 26 augustus 2016
Content Security Policy : Content Security Policy (CSP) header not implemented
https://observatory.mozilla.org/analyze.html?host=www.security.nlMisschien is die CSP protectie gewoon niet belangrijk, is het niet alleen voor beheerders maar ook voor hackers te moeilijk en is daarom een cloudflare abonnementje voor verreweg de meeste websites meer dan voldoende?
@Anoniem 12-09-2016, 15:51: hoewel ik betwijfel of security.nl volstrekt veilig en/of bugvrij is, betekent het ontbreken van een CSP header niet persé dat de site onveilig is.
Bovendien, zoals de TS aangeeft, betekent het aanwezig zijn van een CSP header niet automatisch dat e.e.a. dan correct geïmplementeerd is, integendeel (in veel gevallen).
Daarnaast vermoed ik dat het risico voor gebruikers, dat hun account wordt gekaapt (en bijdragen in hun naam wordem gepost en/of oudere gewijzigd of verwijderd), klein is. En daarmee ook het risico voor de eigenaar van deze site.
Liever heb ik dat de beheerders van security.nl hun tijd stoppen in het dichten van lekken in de gebruikte CMS/forum software (nog steeds een afgeleide van vBulletin als ik me niet vergis), iets dat de Mozilla observatory niet meet - maar iets waar de beheerders van security.nl tot nu toe goed in lijken te slagen.
Overigens is het de vraag of beheerders (zoals jij schrijft) zich met zaken als XSS/CSRF preventie, HSTS, CSP etc. moeten bezighouden, dat vind ik eerder iets voor ontwikkelaars en testers.
Bovendien, zoals de TS aangeeft, betekent het aanwezig zijn van een CSP header niet automatisch dat e.e.a. dan correct geïmplementeerd is, integendeel (in veel gevallen).
Daarnaast vermoed ik dat het risico voor gebruikers, dat hun account wordt gekaapt (en bijdragen in hun naam wordem gepost en/of oudere gewijzigd of verwijderd), klein is. En daarmee ook het risico voor de eigenaar van deze site.
Liever heb ik dat de beheerders van security.nl hun tijd stoppen in het dichten van lekken in de gebruikte CMS/forum software (nog steeds een afgeleide van vBulletin als ik me niet vergis), iets dat de Mozilla observatory niet meet - maar iets waar de beheerders van security.nl tot nu toe goed in lijken te slagen.
Overigens is het de vraag of beheerders (zoals jij schrijft) zich met zaken als XSS/CSRF preventie, HSTS, CSP etc. moeten bezighouden, dat vind ik eerder iets voor ontwikkelaars en testers.
Afgelopen donderdag is GitHub met een mooie blog gekomen over hun analyse na aanleiding van al deze CSP-issues:
https://githubengineering.com/githubs-post-csp-journey/.
Veel voorbeelden, dus goed leesvoer!
https://githubengineering.com/githubs-post-csp-journey/.
Veel voorbeelden, dus goed leesvoer!
23-01-2017, 12:31 door
karma4
Door Erik van Straten: ....
Overigens is het de vraag of beheerders (zoals jij schrijft) zich met zaken als XSS/CSRF preventie, HSTS, CSP etc. moeten bezighouden, dat vind ik eerder iets voor ontwikkelaars en testers.
Dat is een lastige. In het politieke spel van de afdelingen leidt dat er toe dat niemand iets doet aan wat wel zou moeten gebeuren. De gewone secùrity invulling leidt daar al.onder.Overigens is het de vraag of beheerders (zoals jij schrijft) zich met zaken als XSS/CSRF preventie, HSTS, CSP etc. moeten bezighouden, dat vind ik eerder iets voor ontwikkelaars en testers.
Beter Is om het Is beleidspunt zichtbasr te maken en wie wat doet door de echte verantwoordelijken te laten nemen.
Dan Is ook budget fte taak helder belegd.
Zelfs de Mozilla site laat steken vallen: https://csp-evaluator.withgoogle.com/
Click the icons in the tables below for a more detailed explanation.
HTTP security headers
Name
Value
Setting secure
content-security-policy
default-src 'none'; connect-src https://api.ssllabs.com https://hstspreload.org https://http-observatory.security.mozilla.org https://securityheaders.io https://tls.imirhil.fr https://tls-observatory.services.mozilla.com https://www.htbridge.com; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; img-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com, upgrade-insecure-requests; block-all-mixed-content
Page meta security headers not set as secure.
default-src 'none';
connect-src https://api.ssllabs.com https://hstspreload.org https://http-observatory.security.mozilla.org https://securityheaders.io https://tls.imirhil.fr https://tls-observatory.services.mozilla.com https://www.htbridge.com;
font-src 'self' https://fonts.gstatic.com;
frame-ancestors 'none';
img-src 'self';
script-src 'self';
style-src 'self' https://fonts.googleapis.com
Voor wat: connect-src https://api.ssllabs.com https://hstspreload.org https://http-observatory.security.mozilla.org https://securityheaders.io https://tls.imirhil.fr https://tls-observatory.services.mozilla.com https://www.htbridge.com;
font-src 'self' https://fonts.gstatic.com;
frame-ancestors 'none';
img-src 'self';
script-src 'self';
style-src 'self' https://fonts.googleapis.com
help_outlinescript-src
expand_more
help_outline'self'
'self' can be problematic if you host JSONP, Angular or user uploaded files.
Dan is er nog een probleem met cache-control. Help Iconexpand_more
help_outline'self'
'self' can be problematic if you host JSONP, Angular or user uploaded files.
Click the icons in the tables below for a more detailed explanation.
HTTP security headers
Name
Value
Setting secure
content-security-policy
default-src 'none'; connect-src https://api.ssllabs.com https://hstspreload.org https://http-observatory.security.mozilla.org https://securityheaders.io https://tls.imirhil.fr https://tls-observatory.services.mozilla.com https://www.htbridge.com; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; img-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com, upgrade-insecure-requests; block-all-mixed-content
Page meta security headers not set as secure.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?