Ontbrekend Referrer-Policy

De Referer-header is een overblijfsel uit de begintijd van het web, bedoeld om sitebeheerders te laten zien waar hun bezoekers vandaan kwamen. Die goedbedoelde functie stuurt tegenwoordig standaard de volledige URL van uw pagina naar elke externe partij die uw bezoeker aandoet. Hieronder leest u wat daar precies in kan zitten en hoe u dat begrenst.

Wat is de Referrer-Policy?

De Referrer-Policy is een HTTP-header waarmee u bepaalt hoeveel de browser prijsgeeft over de pagina waarvandaan een verzoek vertrekt. Zonder beleid hanteren browsers een standaardwaarde die de volledige URL binnen hetzelfde domein doorgeeft en het domein naar buiten toe; oudere browsers en sommige configuraties zijn daarin ruimhartiger en sturen het complete adres inclusief pad en queryparameters mee.

Het is te vergelijken met een bezoeker die bij binnenkomst standaard vertelt waar hij vandaan komt. “Ik kom van de website van de gemeente” is onschuldig. “Ik kom van de pagina wachtwoord-herstellen met token 8f3a-c91d” is dat niet. De header maakt zelf geen onderscheid: hij geeft door wat er in de URL staat.

Daarom is deze bevinding op zichzelf licht, maar hangt de werkelijke betekenis volledig af van hoe uw applicatie haar URL’s opbouwt.

Hoe lekt informatie via de referrer?

Het lek ontstaat niet alleen wanneer een gebruiker op een externe link klikt. Elke resource die de pagina laadt (een script van een CDN, een lettertype, een afbeelding, een analytics-pixel) krijgt de header net zo goed mee.

Kwetsbaar:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Er is geen beleid, dus de browser hanteert zijn standaard. Bekijkt de gebruiker deze pagina:

https://portaal.example/herstel?token=9c2f81ad4e&gebruiker=j.dekker@bedrijf.nl

en laadt die pagina een extern script of klikt de gebruiker op een externe link, dan vertrekt het volgende naar die derde partij:

GET /widget.js HTTP/1.1
Host: cdn.example
Referer: https://portaal.example/herstel?token=9c2f81ad4e&gebruiker=j.dekker@bedrijf.nl

Het herstel-token en het e-mailadres staan nu in de logbestanden van een partij die daar niets mee te maken heeft. Wie toegang heeft tot die logs (een medewerker, een aanvaller die het CDN compromitteert, of de dienst zelf) kan met dat token het wachtwoord van deze gebruiker opnieuw instellen.

Veilig:

HTTP/1.1 200 OK
Referrer-Policy: strict-origin-when-cross-origin

Binnen uw eigen domein blijft de volledige URL beschikbaar, zodat interne statistieken en navigatielogica blijven werken. Gaat het verzoek naar een ander domein, dan wordt alleen https://portaal.example doorgegeven, zonder pad of parameters. En gaat het naar een onversleutelde bestemming, dan stuurt de browser helemaal niets. Voor pagina’s waar echt niets mag weglekken, gaat u een stap verder:

Referrer-Policy: no-referrer

Wat is de impact van een ontbrekend Referrer-Policy?

Als losstaande bevinding is dit een hardeningkwestie met een lage ernst: er is geen directe aanval mogelijk en er is geen kwetsbaarheid in uw code. De betekenis ontstaat in combinatie met de rest van uw applicatie.

Bevatten uw URL’s uitsluitend neutrale paden, dan blijft de schade beperkt tot privacy: externe partijen zien welke pagina’s uw bezoekers bekijken, wat bij een medische, juridische of financiële dienst al gevoelig genoeg kan zijn. Staan er wél identificerende gegevens of tokens in, dan verschuift het naar een echt beveiligingsprobleem, omdat die waarden daarmee bij derden terechtkomen.

Er is nog een minder bekende toepassing: interne URL-structuren die weglekken helpen een aanvaller bij het in kaart brengen van uw applicatie. Padnamen als /beheer/rapportage/exporteer verraden functionaliteit die verder niet zichtbaar is, en dat is precies het soort informatie waarmee een gerichte aanval begint.

Hoe spoor je een ontbrekend Referrer-Policy op?

De aanwezigheid van de header is snel vastgesteld, maar de relevante vraag is wat er zónder beleid zou weglekken. Een tester inventariseert daarom welke URL’s in de applicatie parameters bevatten en of daar gevoelige waarden in staan: tokens, e-mailadressen, klantnummers, zoekopdrachten of documentidentificaties.

Vervolgens wordt bekeken welke externe bronnen die pagina’s laden, want elk daarvan is een ontvanger van de header. Ook wordt gecontroleerd of het beleid consistent op alle routes wordt gezet, juist de herstel- en uitnodigingspagina’s, waar de gevoeligste URL’s voorkomen, worden vaak apart afgehandeld en missen dan de header. AssistSec beoordeelt bij een penetratietest de combinatie van beide: niet alleen of de header er staat, maar vooral of er in uw URL’s iets staat dat nooit naar buiten had mogen gaan.

Hoe voorkom je een ontbrekend Referrer-Policy?

• Stel Referrer-Policy: strict-origin-when-cross-origin in als centrale standaard voor de hele applicatie.
• Gebruik no-referrer op pagina’s die tokens, herstelcodes of persoonsgegevens in de URL bevatten.
• Plaats geheimen nooit in een queryparameter; gebruik een POST-body, een header of een kortlevende sessie aan serverzijde.
• Voeg rel="noreferrer" toe aan links naar externe sites waarvan u de herkomst niet wilt prijsgeven.
• Beperk het aantal externe bronnen dat uw pagina’s laden; elke bron is een ontvanger van de referrer.
• Controleer dat ook foutpagina’s, e-mailgestuurde landingspagina’s en antwoorden uit een CDN de header meesturen.
• Combineer de header met een Content Security Policy, zodat u zowel beperkt wát er laadt als wát daarbij wordt doorgegeven.