Beperk het herschrijven van proxy-inhoud met no-transform en HTTPS

Een proxy die inhoud transformeert kan een respons onderweg naar de browser wijzigen: een afbeelding opnieuw comprimeren, opmaak herschrijven of ondersteunende JavaScript invoegen. Een pagina die op het ene netwerk werkt en op het andere onbekende opmaak krijgt, kan precies dat gedrag van een tussenpartij tegenkomen.

Voor een site die u beheert, biedt HTTP een expliciete responsrichtlijn:

Cache-Control: no-transform

RFC 9111 vereist dat een tussenpartij die deze responsrichtlijn ontvangt de inhoud ongetransformeerd laat, ongeacht of die tussenpartij een cache implementeert. Het is relevant voor het opnieuw comprimeren van afbeeldingen en het injecteren van opmaak, niet alleen voor de vraag of een object wordt opgeslagen.

Houd het bij het bestaande cachebeleid

Als een respons al cache-richtlijnen heeft, voeg de eis dan bewust toe in plaats van de rest van het beleid weg te gooien. Een openbaar cachebare asset kan bijvoorbeeld hebben:

Cache-Control: public, max-age=3600, no-transform

Dit voorbeeld behoudt een versheidsbeleid van één uur en verbiedt tegelijk inhoudstransformatie. no-transform betekent niet no-store en schakelt de gewone overdrachtsverwerking niet uit. Stel het in op de responsen waarvan de oorspronkelijke inhoud belangrijk is, inclusief afzonderlijke afbeeldingsresponsen waar passend.

De richtlijn werkt via naleving door de tussenpartij. Het verhindert cryptografisch niet dat een netwerkapparaat de instructie negeert.

Bescherm ook het transport

HTTPS geeft de browser een verbinding met authenticatie en integriteitsbescherming naar zijn TLS-tegenpartij. Een gewone carrierproxy die versleuteld verkeer doorlaat, kan niet stilzwijgend een script in die beschermde verbinding invoegen. Houd certificaatverificatie aan; een lokaal vertrouwde inspectieproxy die TLS beëindigt is een andere opzet.

Serveer de pagina en de bijbehorende afhankelijke bronnen via HTTPS. Leid HTTP-bezoekers door naar HTTPS en overweeg HSTS voor een uitrol die dit consistent kan ondersteunen. Alleen een doorverwijzing begint met een onbeveiligde HTTP-uitwisseling voor een bezoeker die een HTTP-URL gebruikte; een eerder geleerd of vooraf geladen HSTS-beleid verandert die eerste keuze.

Het blokkeren van een geïnjecteerd script kan de zichtbare effecten ervan verminderen, maar de respons kan al gewijzigde HTML of herschreven afbeeldings-URL's bevatten. Eén oude functienaam vervangen, een ongebruikelijke opmerking toevoegen of een historisch injectieadres in kaart brengen vestigt geen inhoudsintegriteit voor de volgende tussenpartij.

Bij het onderzoeken van een melding vergelijkt u de ontvangen respons met de bedoelde inhoud van de oorsprong en bepaalt u waar TLS eindigt. Dat bewijs is nuttiger dan elk onbekend script als een fout in de eigen applicatiecode van de site te behandelen.