Ontbrekende HTTP Strict Transport Security

Vrijwel elke site draait tegenwoordig op HTTPS, en toch begint een browserbezoek nog opvallend vaak met een onversleuteld verzoek. Iemand typt een adres zonder protocol, klikt op een oude link of volgt een bladwijzer van jaren geleden. Dat ene eerste verzoek is precies waar een aanvaller op wacht. Hieronder leest u hoe HSTS dat venster sluit en welke instellingen daarbij misgaan.

Wat is HTTP Strict Transport Security?

HTTP Strict Transport Security (HSTS) is een HTTP-header waarmee een server de browser opdraagt om dit domein voortaan uitsluitend via HTTPS te benaderen. De browser onthoudt die instructie voor de opgegeven periode en zet vanaf dat moment elk http://-adres voor dit domein automatisch om naar https://, nog vóór er ook maar één byte het netwerk op gaat.

Het verschil met een gewone redirect is subtiel maar bepalend. Een redirect is een antwoord van de server: de browser moet dus eerst een onversleuteld verzoek sturen om te horen dat hij naar HTTPS moet. HSTS is een instructie die de browser zich hérinnert: er wordt geen onversleuteld verzoek meer verstuurd om te weten te komen dat het niet had gemogen.

Stelt u zich een receptie voor waar bezoekers hun paspoort moeten tonen. Een redirect is de receptionist die zegt: “u staat nu binnen, maar loopt u even terug en meldt u zich netjes aan.” HSTS is het bordje aan de buitenkant dat bezoekers al hebben gelezen voordat ze naar binnen liepen. In het eerste geval heeft iemand al in de hal gestaan; in het tweede niet.

Hoe werkt een downgrade-aanval?

De aanval speelt zich af op het netwerk: een openbaar wifinetwerk, een gecompromitteerde router of een tussenliggende provider. De aanvaller hoeft geen versleuteling te breken, hij hoeft alleen te voorkomen dat die ooit tot stand komt.

Kwetsbaar:

HTTP/1.1 301 Moved Permanently
Location: https://portaal.example/inloggen

Op het oog is dit correct: de server stuurt bezoekers netjes door naar HTTPS. Het probleem is dat de gebruiker, om dit antwoord te ontvangen, eerst het volgende moest versturen:

GET /inloggen HTTP/1.1
Host: portaal.example

Dat verzoek gaat in leesbare vorm over het netwerk. Een aanvaller die ertussen zit, laat de redirect nooit aankomen. In plaats daarvan houdt hij zelf de verbinding met de gebruiker over HTTP in stand, praat aan de achterkant wél via HTTPS met uw server en leest zo alles mee wat het slachtoffer intypt: gebruikersnaam, wachtwoord, sessiecookie. De gebruiker ziet een werkende inlogpagina en merkt hooguit dat het slotje ontbreekt.

Veilig:

HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Na één succesvol HTTPS-bezoek onthoudt de browser dit een jaar lang. Typt de gebruiker daarna portaal.example in de adresbalk, dan verstuurt de browser meteen een HTTPS-verzoek; er is geen onversleuteld verzoek meer om te onderscheppen. includeSubDomains breidt die regel uit naar elk subdomein, wat belangrijk is omdat een vergeten test.portaal.example anders een openstaande zijdeur blijft. Met preload komt het domein op een lijst die in de browser zelf is opgenomen, zodat zelfs het allereerste bezoek al beschermd is.

Wat is de impact van ontbrekende HSTS?

De ernst wordt doorgaans als laag tot middelzwaar beoordeeld, omdat de aanvaller een positie in het netwerkpad nodig heeft. Die voorwaarde is echter minder zwaar dan ze klinkt: een openbaar netwerk in een trein, hotel of café, een nagebootst wifitoegangspunt of een gecompromitteerd thuisapparaat volstaan.

Slaagt de aanval, dan is de schade wel volledig. De aanvaller leest alles wat over de verbinding gaat: inloggegevens, sessiecookies, persoonsgegevens en de inhoud van formulieren. Bovendien kan hij het antwoord aanpassen, waarmee de weg openligt naar een nagemaakt inlogscherm of geïnjecteerde scriptcode. Omdat de sessiecookie in dat scenario wordt buitgemaakt, hoeft de aanvaller het wachtwoord niet eens te kennen om verder te kunnen.

Een te korte max-age verzwakt de bescherming zonder haar helemaal weg te nemen. Staat de waarde op 30 dagen, dan is een gebruiker die zes weken niet is langsgeweest opnieuw kwetsbaar bij zijn eerstvolgende bezoek, precies het moment waarop hij het adres weer intypt.

Hoe spoor je ontbrekende HSTS op?

De controle begint bij het HTTPS-antwoord: is er een Strict-Transport-Security-header, en zo ja, hoe lang is de max-age? Een waarde onder een jaar is een aandachtspunt, een waarde van nul schakelt de bescherming actief uit.

Daarna volgt het onderzoek dat scanners meestal overslaan. Wordt de header ook op subdomeinen gezet, of dekt includeSubDomains domeinen af die zelf geen HTTPS aanbieden? Stuurt de HTTP-versie van de site correct door naar HTTPS, en gebeurt dat naar het juiste pad? Wordt de header per ongeluk alleen op de startpagina gezet en niet op de API of het inlogendpoint? En staat het domein op de preloadlijst terwijl er nog een subdomein zonder certificaat bestaat? AssistSec controleert bij een penetratietest de volledige certificaatketen en de redirectstructuur, en beoordeelt of er in de praktijk nog een pad bestaat waarlangs een gebruiker onversleuteld met uw applicatie kan praten.

Hoe voorkom je ontbrekende HSTS?

• Stuur Strict-Transport-Security mee op elk HTTPS-antwoord, met max-age=31536000 als richtwaarde.
• Voeg includeSubDomains toe zodra u zeker weet dat alle subdomeinen HTTPS ondersteunen.
• Bouw de looptijd gefaseerd op: begin kort, controleer of alles werkt en verhoog daarna naar een jaar.
• Blijf HTTP naar HTTPS doorsturen; HSTS vervangt die redirect niet, maar vult hem aan.
• Overweeg opname in de preloadlijst voor domeinen die blijvend en volledig op HTTPS draaien.
• Zet de header nooit op een onversleuteld antwoord; browsers negeren hem daar, wat een vals gevoel van veiligheid geeft.
• Bewaak de geldigheid van uw certificaten actief, want met HSTS kunnen bezoekers een certificaatfout niet meer wegklikken.
• Regel de header centraal in uw webserver of proxy, zodat nieuwe hosts en routes hem automatisch overnemen.