Site Security Policy voorstel tegen XSS & CSRF
Een werknemer van Mozilla heeft een nieuwe voorstel uit gebracht dat het gevaar van Cross Site Scripting (XSS) en Cross Site Request Forgery (CSRF) moet beperken. Het voorstel beschrijft namelijk manieren om op te geven welke hosts / domeinen bijv. Javascript mogen aanleveren of juist een bepaald request mogen uitvoeren. Mocht er een situatie voorkomen waarbij een van deze regels doorbroken zou worden (bijv: een niet toegestane host probeert request uit te voeren), dan kan de site ook een URL opgeven waarnaar een rapport gestuurd moet worden.
Site Security Policy provides a way to greatly reduce or altogether eliminate a website's attack surface for Cross-Site Scripting. With proper Site Security Policy in place, a successful XSS attack will require the attacker to have control over the contents of white-listed script source files. No longer will XSS attacks which rely on echoing script into page contents be effective. Further, if a site knows it never want to have JavaScript executing in its pages, it can simply globally disable JavaScript and not have to worry about script injection attacks against its users with supporting browsers.
Site Security Policy also provides a simple way for a website to prevent Cross-Site Request Forgery against its sensitive resources. A comprehensive CSRF protection mechanism, such as form token checking, can be complicated to implement and difficult to integrate into an existing web application. Such a mechanism may even be subject to its own security bugs. Even a properly implemented CSRF-protection-token system will not stand up in an environment with XSS bugs. Web sites facing these challenges can utilize Site Security Policy to harden themselves against attack and achieve a higher level of confidence in the security of their systems with an added layer of security. Websites will be able to fully control who can request resources from outside the site and what remote locations should be reachable by content from within the site.
Het voorstel is compleet met voorbeelden van syntax en zelfs een Firefox Addon waarin het voorgestelde reeds is geimplementeerd. Wat denk jij, zou een dergelijke beveiliging vanuit de browser helpen, of moet de focus toch meer bij de ontwikkelaars blijven liggen?
Volg Scriptorama via RSS!
Reageer ook!
De focus moet ten alle tijde bij de ontwikkelaar liggen. Maar een browser kan in dit geval helpen. Bij een ontwikkelaar maar ook bij bijv. de hobbyist.
Door Kees
op 06.06.08 @ 7:47 am | Permalink
Moet meer bij de ontwikkelaars liggen. Dit mag hoogstens een extraatje zijn, maar security moet niet afhankelijk zijn van de aanwezigheid van een dergelijke policy (net zoals dat het niet afhankelijk moet zijn van magic quotes oid). Sowieso zal je voorlopig user agents houden welke dit niet (of niet correct) implementeren.
SSP moet in ieder geval KISS gehouden worden, met gewoon heel grove white- en blacklist mogelijkheden. Te veel nuances en het wordt minder helder waardoor wellicht fouten gemaakt worden, waar dankzij een gevoel van schijnveiligheid, niet bij stil gestaan wordt.
Door Maarten
op 06.06.08 @ 8:39 am | Permalink
Ik ben het met Maarten eens.
Zo word je weer teveel bescherm waardoor je het niet direct nodig acht dat je veiligheid in je Scripts meen neemt.
En je ook zit met het probleem van Legacy browsers, zoals IE6...
Door Sebastiaan Stok
op 06.06.08 @ 9:34 am | Permalink
Offtopic: In de Poll mis ik nog Mercurial ;)
Door Sebastiaan Stok
op 06.10.08 @ 9:09 am | Permalink
Ik ben het met bovenstaande commentaren eens. Een dergelijke whitelist in de browser klinkt natuurlijk leuk, maar de oplossing zou zich op de server moeten bevinden, niet bij de client, om bovengenoemde redenen.
Wel is het idee van een whitelist van domeinen waar scripts op mogen draaien een goed idee natuurlijk, maar ik prefereer dit aan de server kant te testen. Wellicht zou je in ZF iets kunnen maken dat je response controleerd op basis van je whitelist? Daar zou ik wel van onder de indruk zijn :)
Door berry__
op 06.30.08 @ 10:03 am | Permalink
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>