Kort samengevat: stille extensie-update die CSP-headers verwijdert onder de W3C-clausule over gebruikersprioriteit
- De meeste teams behandelen CSP als een harde grens. De CSP3-spec zegt iets anders: beleid mag add-ons niet hinderen, omdat de user agent voorrang heeft. Een extensie kan je 31 directives verwijderen zonder dat je grootvader ooit een toestemmingsprompt te zien krijgt.
- cside detecteert browser-runtime-gedrag nadat het verzoek je controle al heeft verlaten. Wanneer een stilletjes bijgewerkte extensie de header verwijdert die je verzond om een betaalpagina te beschermen, is dat gedrag wat het alarm activeert, aangezien de report-uri waarop je rekende nooit afgaat zodra de header verdwenen is.
- Het is onwaarschijnlijk dat het W3C de prioriteitsclausule op jouw tijdlijn herschrijft. De echte beslissing is dus of CSP je enige client-side verdediging blijft, of dat je runtime-scriptobservatie toevoegt die nog steeds werkt voor de extensie die een gebruiker zes jaar geleden installeerde en is vergeten.
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 zorg:
"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 W3C. Het zou onderdeel moeten zijn van het bredere beveiligingskader voor browsers, een kader dat browserleveranciers aanzet tot zelfregulering en om beveiliging serieus te nemen.
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.
