Wij zijn |
Security headers – het wat en waarom
Wanneer het aankomt op de beveiliging van je website, zijn er veel factoren waarmee je rekening moet houden. Eén van de manieren om de veiligheid van je website te verbeteren, is door het implementeren van security headers, ook wel HTTP security headers genoemd. Goed ingestelde security headers kunnen fijnmazige instructies bevatten over wat er wel en niet uitgevoerd mag worden en kan daardoor een verscheidenheid aan kwetsbaarheden voorkomen zoals Cross-Site Scripting (XSS) . In deze blogpost gaan we dieper in op de vijf belangrijkste security headers die elke website zou moeten implementeren. Lees verder om te ontdekken hoe deze security headers werken en hoe je ze kunt gebruiken om je webapplicatie te beschermen tegen verschillende beveiligingsrisico’s.
Security headers: het wat en waarom
De achtergrond
HTTP-security headers zijn ontstaan uit de groeiende behoefte aan verbeterde webbeveiliging. In een tijdperk waarin websites complexer worden en gevoelige informatie verwerken, zijn ze van vitaal belang geworden om gebruikers en gegevens te beschermen tegen toenemende bedreigingen. De oorsprong van deze headers kan worden herleid tot het vroege aandachtspunt op webbeveiliging, met de introductie van HTTP Strict Transport Security (HSTS) als een van de pioniers. Deze header, ontstaan uit Mozilla’s inspanningen in 2004 en later gestandaardiseerd, was gericht op het elimineren van man-in-the-middle aanvallen door te garanderen dat websites altijd via een beveiligde HTTPS-verbinding werden benaderd.
Na HSTS volgde een reeks andere headers, zoals X-XSS-Protection, X-Frame-Options, X-Content-Type-Options en Content Security Policy (CSP). Deze headers zijn ontwikkeld om specifieke beveiligingsproblemen, variërend van cross-site scripting (XSS) tot clickjacking en MIME-sniffing-aanvallen, aan te pakken. Gezamenlijk vormen ze een krachtig arsenaal aan beveiligingsmechanismen die websitebeheerders in staat stellen om hun webapplicaties te beschermen en de risico’s van moderne cyberdreigingen te minimaliseren.
Zelf security headers configureren en controleren
Na het begrijpen van het belang van security headers, is het tijd om te verkennen hoe je zelf de instellingen van je website kunt controleren. Gelukkig is dit proces eenvoudiger gemaakt dankzij tools zoals Securityheaders.com. Deze website stelt je in staat om snel en effectief de huidige staat van je security headers te analyseren. Door simpelweg je website URL in te voeren, krijg je een gedetailleerd overzicht van welke headers je hebt geïmplementeerd, hoe ze zijn geconfigureerd en welke mogelijke verbeteringen er zijn. Zo krijg je een helder beeld van waar je staat en wat er nodig is om je beveiliging te optimaliseren. Dit vormt een waardevolle eerste stap in het versterken van je webbeveiliging.
Wanneer je Securityheaders.com gebruikt, biedt de site niet alleen een overzicht van je huidige security headers, maar geeft het ook directe feedback over eventuele onveilige instellingen. Je ontvangt praktische suggesties over hoe je deze instellingen kunt wijzigen om de beveiliging te verbeteren. Voor een diepgaander begrip en gedetailleerde richtlijnen voor het veilig configureren van je security headers, raad ik aan de “ICT-beveiligingsrichtlijnen voor Webapplicaties” van het Nationaal Cyber Security Centrum (NCSC) te gebruiken als naslagwerk. Deze richtlijnen zijn te vinden op de website van het NCSC. Onderstaand geven we per security header een korte beschrijving en advies hoe deze veilig geconfigureerd kan worden.
HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) is een security header die helpt om websites te beschermen tegen zogenaamde downgrade-aanvallen en het kapen van cookies. Het werkt als volgt: stel je hebt een website, bijvoorbeeld www.example.com, en je hebt een SSL-certificaat gekocht om je website te migreren van HTTP naar HTTPS. Als oude gebruikers nog steeds je website openen via HTTP, kunnen ze worden omgeleid naar HTTPS via een doorverwijzing als een oplossing. Omdat bezoekers mogelijk eerst communiceren met de niet-versleutelde versie van de site voordat ze worden omgeleid, ontstaat er een kans voor een man-in-the-middle aanval. De HTTP Strict Transport Security-header vertelt de browser dat deze nooit een site mag laden via HTTP en dat alle pogingen om de site via HTTP te openen automatisch moeten worden omgezet naar HTTPS-verzoeken.
Content Security Policy (CSP)
Content Security Policy (CSP) is een security header die bepaalt welke bronnen geladen mogen worden op een webpagina. Het helpt bijvoorbeeld om Cross-Site Scripting (XSS) aanvallen te voorkomen door te specificeren welke scripts mogen draaien. Stel, je hebt een website, en je wilt alleen scripts toestaan die van jouw eigen server komen. Met CSP kun je dit afdwingen. Als iemand probeert een kwaadaardig script (XSS) toe te voegen via een commentaarformulier of een andere invoer, zal de CSP dit blokkeren. Dit verhoogt de beveiliging aanzienlijk door alleen toegestane bronnen, zoals scripts, stijlen, en afbeeldingen, van vertrouwde locaties te laden.
X-Content-Type-Options
De X-Content-Type-Options header, met name de instelling ‘nosniff’, speelt een belangrijke rol in de beveiliging van websites. Deze header voorkomt MIME type ‘sniffing’ door de browser. Dit betekent dat als je een bestand aanbiedt vanaf je server, de (oudere) browser niet probeert het type bestand te raden, maar vertrouwt op wat jij opgeeft. Dit helpt bij het voorkomen van aanvallen waarbij kwaadaardige inhoud wordt verstopt in onschuldig lijkende bestandstypen, zoals het vermommen van een uitvoerbaar script als een afbeelding.
X-Frame-Options
De X-Frame-Options header is ontworpen om je website te beschermen tegen ‘clickjacking‘-aanvallen. Deze header bepaalt of je pagina al dan niet in een frame of iframe geladen mag worden, die op een andere website wordt weergegeven. Door de instellingen ‘DENY’ of ‘SAMEORIGIN’ te gebruiken, kun je voorkomen dat kwaadwillenden jouw webpagina in een frame op hun eigen site plaatsen, waarmee ze gebruikers misleiden om op verborgen elementen te klikken. Dit verhoogt de beveiliging door ongeautoriseerde framing te blokkeren. Het is ook belangrijk op te merken dat het risico van clickjacking verder verminderd kan worden door een goed afgestelde Content Security Policy (CSP), zoals hierboven besproken.
Permission-Policy
De Permission Policy header, voorheen bekend als Feature Policy, stelt webbeheerders in staat om te bepalen welke functies en API’s gebruikt mogen worden door hun webpagina’s. Deze header biedt gedetailleerde controle over functies zoals camera- en microfoontoegang, locatiebepaling en pop-upvensters. Door specifieke regels te definiëren, kun je voorkomen dat kwaadaardige scripts toegang krijgen tot gevoelige apparaatfuncties, wat bijdraagt aan een sterkere beveiliging van zowel de website als de eindgebruikers.
Referrer-Policy
De Referrer-Policy header helpt bij het beheren van de informatie die wordt verzonden als onderdeel van de ‘referer’ header bij navigatie tussen pagina’s. Deze header kan worden gebruikt om de hoeveelheid gegevens die wordt gedeeld te beperken, vooral wanneer van een beveiligde (HTTPS) naar een onbeveiligde (HTTP) omgeving wordt overgestapt. Door de juiste configuratie van deze header kun je de privacy van de gebruikers verbeteren door te bepalen welke informatie wordt gedeeld en onder welke omstandigheden.
De conclusie
Hoe kunnen wij u helpen?
QR Codes: Het onverwachte wapen in Device Code Phishing
Device code phishing, net als aanvallen via Adversary-in-the-middle (AiTM), vertegenwoordigt een geavanceerde vorm van cyberdreiging die zich onderscheidt van traditionele phishing. Device code phishing exploiteert de ‘OAuth2 Device Authorization Grant flow‘ van Microsoft Azure, die gebruikers in staat stelt zich aan te melden bij apparaten met beperkte invoermogelijkheden.
Cross-Site Scripting (XSS): wat is het en hoe te voorkomen
In deze blogpost lees je alles over Cross-Site Scripting (XSS). Welke vormen van XSS er zijn. Wat de impact van een XSS-aanval kan zijn en hoe je het kan voorkomen.
CORS: het belang van Cross-Origin Resource Sharing
Bij onze klanten zien we een toenemende implementatie van Cross-Origin Resource Sharing (CORS). Helaas constateren we ook een stijging in het aantal onveilig geconfigureerde CORS-implementaties. In deze blog duiken we dieper in wat CORS is, de meest voorkomende misconfiguraties en hun potentiële risico’s, en hoe je sterke CORS-regels kunt instellen om je webapplicaties te beschermen.