Toen Content Security Policies (CSP) werden geïntroduceerd, was het oorspronkelijke doel om Cross-Site Scripting (XSS) en kwaadaardige client-side injecties via client-side opgehaalde resources te beperken. In de loop der tijd is CSP gegroeid en telt het vandaag de dag in totaal 31 directives met wisselende ondersteuning in browsers en 3 verschillende rapportageformaten.
Deze headers stellen een website-eigenaar in staat om te definiëren welke bronnen vertrouwd zijn voor het ophalen van JavaScript. Lettertypen, stylesheets of iFrames. Ook kunnen externe verbindingen worden gedefinieerd waarmee data kan worden geëxfiltreerd. Een correct geïmplementeerde CSP kan ongewenst gedrag voorkomen. Maar CSP is niet erg gebruiksvriendelijk en heeft een aantal grote tekortkomingen, daar kun je hier meer over lezen.
Maar zou een browserextensie deze headers stilletjes mogen verwijderen?
De logica van de specificatie
"Policy die op een resource wordt afgedwongen mag niet interfereren met de werking van user-agent-functies zoals add-ons, extensies of bookmarklets. Dit soort functies stelt de prioriteit van de gebruiker doorgaans boven die van de paginaauteur, zoals beschreven in [HTML-DESIGN]."
Simpel gezegd: jouw browser is jouw client. Jouw client heeft voorrang op de beveiliging van de webpagina die je bezoekt. Dat is logisch. Als dit niet het geval was, zouden browsers het waarschijnlijk toch doen. Browsers kunnen er in de huidige wereld sowieso voor kiezen om dingen niet te doen zoals gespecificeerd. Een specificatie van het W3C wordt vaak gezien als een einddoel dat via compromissen onderweg wordt bereikt.
Maar toch…
Ziet toch iedereen het probleem hier?
Mijn bezwaar:
"Zeker W3C, maar mijn grootvader zou niet weten dat hij door het installeren van een extensie toestaat dat deze essentiële beveiligingsfuncties van websites verwijdert."
Dit probleem reikt verder. Veel browsers werken extensies actief bij zonder specifieke goedkeuring of opt-in. Dit betekent dat een extensie vandaag morgen heel anders kan werken, zonder dat je daarvan op de hoogte wordt gesteld.
Helaas heb ik in mijn carrière gemerkt dat mensen bij het bouwen van technologie niet snel nadenken over hun ouders of grootouders. Onbewust over het hoofd gezien of iets anders — op een dag zijn wij oud en kunnen onze kinderen hetzelfde met ons doen. Waarom zijn we zo?
Browsers zijn functiemachines. Beveiliging is een functie. Als er serieuze beveiligingsproblemen opduiken, wordt er uiteindelijk iets aan gedaan door externe druk en publieke verontwaardiging. Maar de prioriteit blijft bij opvallende functies, en beveiliging wordt simpelweg niet als prioriteit nummer 1 behandeld.
Wat is dan een oplossing?
Dit gaat verder dan het domein van het W3C, maar zou deel moeten uitmaken van het bredere beveiligingskader van browsers, waarbij een zelfregulerende en beveiligingsbewuste houding van browserbeveiligingsbedrijven wordt gestimuleerd.
Ik vraag me af: waarom dit niet een expliciete opt-in maken?
Als een extensie bij installatie of update de functionaliteit toevoegt om beveiligingsheaders te verwijderen of aan te passen, maak de gebruiker dan bewust van dit gedrag en laat hem of haar dit goedkeuren.
Client-side beveiliging is een interessant probleemgebied; het bovenstaande onderwerp is slechts één van de vele zaken die fundamenteel verkeerd zijn geïmplementeerd en gevaarlijk zijn. Hoewel ik dit aankaart als een probleem op W3C-niveau, is het in werkelijkheid een door de browser veroorzaakt beveiligingsprobleem.
Er is nog veel meer. Bescherm je klanten, probeer cside.
