Nieuwe HTTP Security headers

De HTTP security headers zijn een belangrijk onderdeel van de beveiliging van een website. HTTP security headers bevinden zich in de response headers wanneer een webpagina opent met een browser. Zo wordt er met deze security headers afgedwongen dat een website alleen opent door middel van een beveiligde https verbinding. Daarnaast biedt het extra beveiliging tegen cross site scripting aanvallen en wordt er bepaald of de website in een iframe mag laden. Ten slotte zijn er nog een aantal beveiligingsmechanismen die met deze security headers geïmplementeerd kunnen worden. Deze beveiligingsmechanismes bieden bescherming tegen de volgende aanvallen: cross-site injections, cookie hijacking, clickjacking, MIME-sniffing en Cross origin attacks. Om te testen of een website deze security headers al heeft geïmplementeerd, kan er gebruik worden gemaakt van de volgende link: https://securityheaders.com/

Het testen op HTTP security headers zijn bij de security scans van Carthago een standaard onderdeel. Hierbij wordt een tabel opgeleverd met welke security headers er wel of nog niet geïmplementeerd zijn. 

Sinds januari zijn er een aantal nieuwe security headers. Deze worden echter nog niet door alle browsers ondersteunt. Zie per beschreven header een link voor ondersteuning van de verschillende browsers. Het aan te raden deze links over browser ondersteuning goed in de gaten te houden. Deze security headers zijn in het leven geroepen om aanvallen als Spectre tegen te gaan. Spectre stelde een aanvaller in staat om cross-origin data te lezen, ook als deze de “Same Origin Policy” had ingesteld. Met de onderstaande security headers is hier wel bescherming tegen te bieden. 

In de onderstaande beschrijvingen over de nieuwe security headers gaat het vaak over de termen cross-origin, same-origin en same-site. Om duidelijk te maken deze termen betekenen, hier een korte uitleg. Als we site a.example en b.example pakken. Dan zijn requests tussen site a en b same-site maar wel cross-origin, requests in enkel a.example zijn same-origin.  Voor meer informatie over dit onderwerp zie: https://web.dev/same-site-same-origin/

COEP: Cross Origin Embedder Policy

Deze response header maakt het mogelijk om aan te geven of cross-origin bronnen wel of niet mogen laden. Op de bronnen van de website kan vervolgens een CORP header worden geïmplementeerd, deze header vertelt hoe een bron mag laden. In deze header zijn 2 verschillende opties mogelijk: 

  • Unsafe-none, 

Deze optie staat toe om bronnen cross-origin te laden, zonder expliciet permissie te hebben van een CORS of CORP header. Deze optie is hetzelfde als het niet implementeren van deze header. 

  • Require-corp, 

Deze optie zorgt ervoor dat een pagina alleen bronnen same-origin kan laden. Tenzij de cross-origin bron dit toestaat om met de CORS of CORP header, is het wel mogelijk om bronnen van een andere oorsprong te laden. 

Browser ondersteuning: https://caniuse.com/mdn-http_headers_cross-origin-embedder-policy

CORP: Cross Origin Resource Policy

Met de CORP header wordt bepaald hoe alle sub bronnen op de pagina toegestaan zijn om te laden. Hier wordt als het ware bepaald of deze bronnen same-site, same-origin of cross-origin kunnen laden. Dit kan verschillende aanvallen voorkomen zoals side-channel aanvallen (Spectre) en Cross-site script inclusion (XSSI) aanvallen.  Deze header heeft drie verschillende opties:

  • same-origin

Deze optie is het meest strikt, enkel requests vanuit de same-origin kunnen de bron lezen. 

  • same-site

Enkel requests vanuit de same-site kunnen de bron lezen.

  • cross-origin

Requests vanuit zowel same-site als same-origin kunnen de bron lezen. 

In onderstaande afbeelding staat de COEP  van a.example op require-corp, b.example heeft een aantal resources. Deze cross-origin laadt, doordat het javascript bestand de CORP heeft ingesteld op cross-origin. In de 2de overdracht staat de CORS ingesteld, CORS werkt ook met COEP. De laatste overdracht laat zien dat de CORP is ingesteld op same-origin. Deze laadt vervolgens niet. Dit gebeurt omdat een CORP op same-origin niet cross-origin kan laden.

Browser ondersteuning: https://caniuse.com/mdn-http_headers_cross-origin-opener-policy

Figuur 1 – voorbeeld COEP en CORP

Bron: https://web.dev/why-coop-coep/

COOP: Cross Origin Opener Policy

Deze response header zorgt ervoor dat de “browsing context group” van een pagina niet wordt gedeeld met pagina’s met een andere oorsprong. Deze header zorgt voor “proces isolatie”, wat ervoor zorgt dat aanvallers niet bij het globale object kunnen. Dit maakt het mogelijk om cross-origin aanvallen te voorkomen. Deze header kan ingesteld worden met 3 verschillende opties:

  • Unsafe-none 

Staat de pagina toe om toegevoegd te worden aan de opener zijn “browsing context group”, tenzij de opener zelf een COOP heeft ingesteld met same-origin of same-origin-allow-popups.

  • same-origin-allow-popups

 Behoud de referenties naar nieuw geopende browser schermen of tabjes. Welke geen COOP geïmplementeerd hebben of de COOP op unsafe-none hebben staan. 

  • same-origin

Isoleert de browsing context exclusief naar same-origin pagina’s. Pagina’s met een cross-origin laden niet in dezelfde browsing context. In onderstaande afbeelding zijn a.example en b.example cross-origin. Doordat de COOP header op same-origin staat kunnen ze geen resources van elkaar lezen.

Browser ondersteuning: https://caniuse.com/mdn-http_headers_cross-origin-resource-policy

Figuur 2 – Voorbeeld COOP

Bron: https://web.dev/why-coop-coep/

Samenvatting:

Inhoud van blog

Auteur van deze blog: