HTTP-beveiligingsheaders: CSP en HSTS

U hebt de toepassing geïmplementeerd. De pagina's worden geladen, de formulieren werken en niets ziet er kapot uit. Vervolgens voert u een scan uit en deze komt terug met een lijst met bevindingen over kopteksten - en niets daarvan is duidelijk.

Dat is een normale eerste reactie. Headers verschijnen niet op het scherm, dus het is moeilijk te zeggen of ze ertoe doen of dat de scanner gewoon kieskeurig is. In deze gids worden de kopteksten besproken die u het vaakst tegenkomt, wat elke kop in gewone taal doet en hoe u de uwe kunt controleren zonder giswerk.

Beveiligingsheaders zijn instructies die uw server naast de pagina naar de browser verzendt. De browser leest ze en past aan hoe hij met uw inhoud omgaat: welke scripts mogen worden uitgevoerd, of de pagina over gewone HTTP kan worden geladen, of een andere site deze in een frame kan insluiten.

Er verandert niets op de pagina. Dat is precies waarom deze bevindingen abstract aanvoelen: de site kan er perfect uitzien en zich perfect gedragen, terwijl hij een reeks beveiligingen mist die van belang zouden zijn op de dag dat er iets misgaat.

De eerlijke formulering is deze: headers verminderen een specifieke risicoklasse. Ze maken een site niet op zichzelf veilig, en een schone headercontrole bewijst niet dat een site volledig veilig is. Beschouw ze als één laag tussen meerdere, en een van de goedkoopste lagen om goed te krijgen.

Wanneer een browser een pagina opvraagt, reageert uw server met de pagina en een blok metadata genaamd responsheaders. U kunt ze zelf bekijken: open de ontwikkelaarstools van uw browser, ga naar het tabblad Netwerk, laad de pagina opnieuw en klik op het bovenste verzoek. De headers staan ​​daar.

Beveiligingsheaders zijn eenvoudigweg de headers die de browser vertellen een regel af te dwingen. Sommige zijn streng, sommige zijn adviserend, en ze zijn allemaal ingesteld in uw serverconfiguratie, uw framework of uw hostingplatform - niet in uw HTML.

CSP vertelt de browser welke inhoudsbronnen op uw pagina mogen laden. Het is de krachtigste header hier en degene die mensen het meest intimiderend vinden.

In de praktijk beschrijft een CSP dingen als: scripts mogen alleen afkomstig zijn van uw eigen domein en één vertrouwd CDN; afbeeldingen kunnen overal vandaan komen in HTTPS; de pagina mag niet door een andere site worden geframed. Als iets probeert te laden vanaf een bron die u niet hebt toegestaan, blokkeert de browser dit en registreert de poging in de console.

CSP is een extra verdediging tegen scriptinjectie, naast veilige uitvoercodering en opschoning. Het is ook de header die het meest waarschijnlijk iets kapot maakt als je hem te agressief instelt. Het praktische pad voor een beginner is om te beginnen in de modus 'Alleen rapporteren', te kijken wat er geblokkeerd zou zijn, de echte problemen op te lossen en dit vervolgens af te dwingen.

HSTS vertelt de browser om gedurende een bepaalde periode alleen met uw site te praten via HTTPS. Zodra een browser deze header heeft gezien, weigert deze een onveilige HTTP-verbinding met uw domein te maken, zelfs als een gebruiker typt http:// of volgt een oude link.

Zodra de browser het HSTS-beleid kent, upgradet hij HTTP-verzoeken voordat deze worden verzonden. Bij het eerste bezoek kan HTTP nog steeds worden gebruikt, tenzij het domein al wordt gedekt door een vooraf geladen HSTS-invoer.

Het enige dat we hier moeten respecteren, is toewijding. HSTS wordt door de browser onthouden zolang u opgeeft, dus begin met een korte duur terwijl u bevestigt dat elk subdomein via HTTPS werkt, en verleng het vervolgens zodra u er zeker van bent.

X-Frame-Options bepaalt of een andere site uw pagina's in een frame kan laden - een <iframe> op de pagina van iemand anders.

Waarom zorgen? Omdat framing het mechanisme achter clickjacking is, waarbij een aanvaller uw echte pagina bedekt met onzichtbare of verhulde elementen, zodat een gebruiker op iets klikt waar hij niet op doelde. Als uw app een ingelogde actie heeft (een verwijderknop, een betaling, een wijziging van de instellingen) is het elders inlijsten van de app een risico dat u niet wilt.

De gebruikelijke instelling is SAMEORIGIN, waardoor uw eigen pagina's elkaar kunnen framen, maar alle anderen worden geblokkeerd. Als u nooit van plan bent om ingelijst te worden, is dat meestal de juiste standaard.

Referrer-Policy bepaalt hoeveel van uw URL wordt gedeeld met andere sites wanneer een gebruiker op een link klikt buiten uw pagina. Moderne browsers gebruiken normaal gesproken strict-origin-when-cross-origin: de volledige URL kan worden verzonden bij verzoeken van dezelfde oorsprong, terwijl HTTPS-verzoeken met meerdere oorsprong alleen de oorsprong ontvangen. Een expliciet zwakker beleid kan meer onthullen.

Dat is belangrijk omdat volledige URL's soms gevoelige waarden in zoekreeksen bevatten: tokens, ID's, e-mailadressen, zoektermen. Het lekken ervan naar een derde partij is stil en gemakkelijk te missen.

Een verstandige basislijn is om alleen de oorsprong, of helemaal niets, te verzenden bij cross-site verzoeken. Het kost u bijna niets en verwijdert een onbedoeld datalek.

Er komen nog een paar headers vaak genoeg voor om de naam te kennen:

• X-Content-Type-Options: nosniff voorkomt dat de browser het bestandstype raadt, waardoor een geüpload bestand anders in een uitvoerbaar script kan worden omgezet.

• Permissions-Policy schakelt browserfuncties uit die u niet gebruikt, zoals camera, microfoon of geolocatie.

• Cross-Origin-Opener-Policy en gerelateerde cross-origin headers isoleren uw pagina van anderen, waardoor bepaalde aanvallen worden beperkt.

Je hebt ze niet allemaal op de eerste dag nodig. Als u weet wat ze doen, kunt u een scanrapport lezen zonder in paniek te raken.

Je kunt op twee manieren kijken.

Eerst de handmatige route: ontwikkelaarstools, tabblad Netwerk, klik op het paginaverzoek en lees de antwoordkoppen. Dit is handig om te bevestigen dat er een enkele header aanwezig is en deze in te stellen zoals u verwacht.

Ten tweede de praktische route voor meer dan één pagina: voer een scan uit. Een scanner haalt uw site op zoals een browser dat zou doen en rapporteert welke beveiligingsheaders aanwezig zijn, welke ontbreken, en wat elke leemte blootlegt. Dat geeft je een prioriteitenlijst in plaats van een muur met ruwe tekst - en het controleert de pagina's waarvan je niet had gedacht dat je ze handmatig zou openen.

Een hulpmiddel voor algemene doeleinden, zoals de gratis lichtgewicht beveiligingsscan van VICE, markeert koptekstbevindingen naast andere problemen, met het bewijs achter elke kwestie, zodat u kunt zien waarom deze naar voren zijn gebracht.

Headers leven in configuratie, dus de meeste oplossingen zijn klein: voeg een regel toe aan uw serverconfiguratie, een instelling in uw framework of een optie in het dashboard van uw host. Wijzig één header tegelijk en bevestig dat de site nog steeds werkt.

Scan vervolgens opnieuw. Dit is de stap die mensen overslaan. Het bewerken van een configuratie betekent niet dat de header nu op elke pagina correct is, en iets als opgelost markeren in een dashboard is niet hetzelfde als het bevestigen ervan. Alleen een nieuwe scan over hetzelfde bereik vertelt u dat de wijziging daadwerkelijk van kracht is geworden.

Begin met een gratis scan, kijk wat uw headers werkelijk doen en corrigeer de belangrijkste bevindingen één voor één. Dat is een redelijke eerste stap - en een veel betere positie dan te hopen dat de standaardinstellingen goed waren.