Uit de resultaten van een penetratietest op een applicatie kwam naar voren dat er beveiligingsheaders ontbraken. Het eerste wat je als ontwikkelaar natuurlijk doet is checken of de test wel klopt. Dat kan in dit geval makkelijk via de website securityheaders.com. Helaas liet het resultaat niet veel ruimte voor discussie.
Wat zijn HTTP Security Headers eigenlijk?
Wanneer je een webserver aanroept geeft deze jou een mix van onder andere content en HTTP response headers. In deze response headers staan allerlei instellingen waarmee tegen de aanroepende applicatie verteld wordt hoe die met de content moet omgaan.
Zoals het testresultaat al duidelijk maakt zijn er een aantal die belangrijk zijn:
Strict-Transport-Security
De HTTP Strict Transport Security zorgt er voor dat er alleen via HTTPS gecommuniceerd mag worden. Dit verzekert dat de verbinding veilig is.
Content-Security-Policy
Met de Content Security Policy definieer je van welke goedgekeurde bronnen de browser van de bezoeker bestanden (stylesheets, Javascript etc.) mag laden. Je kunt ervoor kiezen om alle externe bronnen op jouw eigen site te plaatsen, of via de CSP te regelen welke externe bronnen je accepteert.
X-Frame-Options
De X-Frame-Options zorgt er voor dat website niet binnen een iframe kan draaien op een andere website. Een mogelijk veiligheidsprobleem kan zijn dat er dan over je website heen een laag gelegd wordt, waarbij over de knoppen van jouw pagina andere knoppen overheen worden geplaatst en zo het gedrag kunnen beïnloeden.
X-Content-Type-Options
Met het zetten van de X-Content-Type-Options kan worden voorkomen dat bestanden anders worden gelezen. Bijvoorbeeld een php-script dat de extensie .jpg heeft en toch uitgevoerd wordt als php-script.
Referrer-Policy
De Referrer Policy zorgt er voor dat er ingesteld kan worden welke gegevens meegestuurd worden wanneer men op een externe link klikt.
Permissions-Policy
Met de Permissions-Policy bepaal je welke browserfuncties en functies je in of uit wilt schakelen. Denk hierbij aan gebruik van locatiebepaling, microfoon en camera.
Hoe voeg je deze headers toe?
De applicatie waar het testresultaat betekking op had is een website die ik host in een Azure Function App. Het hosten Is een leuk experiment, maar daar schrijf ik later nog een uitgebreid artikel over. Ik ben via Google op zoek gegaan naar mogelijke oplossingen voor een Azure Function App. De meeste resultaten gingen voornamelijk over het bewerken van de respons tijdens het uitvoeren van de functie. Dit vereist programmeerwerk en dat is niet wat je wilt. Een artikel van Saitej Kuralla bracht mij uiteindelijk op het juiste spoor.
In de host.json heb je de mogelijkheid om 'customheaders' toe te voegen. Dit is de enige plek waar configuratie mogelijk is die voor alle functies geldt. Ik ben gestart met de boel zoveel mogelijk dicht te zetten, maar toen merkte ik dat de website niet meer optimaal functioneerde. Ik moest nog wat uitzonderingen definieren op in de Content-Security-Policy en toen werkte het weer. Mijn uiteindelijke aanpassing ziet er als volgt uit:
{
"version": "2.0",
"extensions": {
"http": {
"routePrefix": "",
"customHeaders": {
"Strict-Transport-Security": "max-age=31536000",
"X-Content-Type-Options": "nosniff",
"X-Xss-Protection": "1; mode=block",
"X-Frame-Options": "SAMEORIGIN",
"Referrer-Policy": "no-referrer",
"Permissions-Policy": "camera=(), microphone=(), geolocation=()",
"Content-Security-Policy": "default-src 'self';img-src data: https:;object-src 'none'; script-src https://maxcdn.bootstrapcdn.com/ 'self' 'unsafe-inline';style-src https://maxcdn.bootstrapcdn.com/ 'self' 'unsafe-inline'; upgrade-insecure-requests;"
}
}
},
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
}
}
}
} Nog even controleren of we nu wel door de test heen komen.
Precies zoals we hem willen hebben!
