En proxy, der omdanner indhold, kan ændre et svar på vej til browseren: genkomprimere et billede, omskrive markup eller indsætte understøttende JavaScript. En side, der virker på ét netværk og får ukendt markup på et andet, kan være stødt på netop denne mellemmandsadfærd.

For et websted, du driver, giver HTTP en udtrykkelig svardirektiv:

Cache-Control: no-transform

RFC 9111 kræver, at en mellemmand, der modtager dette svardirektiv, lader indholdet være uomdannet, uanset om mellemmanden implementerer en cache. Det er relevant for billedgenkomprimering og markupsindsættelse, ikke kun for om et objekt bliver lagret.

Behold det sammen med den eksisterende cachepolitik

Hvis et svar allerede har cachedirektiver, så tilføj kravet bevidst i stedet for at kassere resten af politikken. Et offentligt cachebart aktiv kan for eksempel have:

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

Dette eksempel bevarer en friskhedspolitik på en time og forbyder samtidig indholdsomdannelse. no-transform betyder ikke no-store og deaktiverer ikke almindelig overførselsbehandling. Sæt det på de svar, hvis oprindelige indhold betyder noget, herunder separate billedsvar, hvor det er relevant.

Direktivet virker gennem mellemmandens efterlevelse. Det forhindrer ikke kryptografisk, at en netværksenhed ignorerer instruktionen.

Beskyt også transporten

HTTPS giver browseren en forbindelse med autentificering og integritetsbeskyttelse til sin TLS-modpart. En almindelig carrier-proxy, der sender krypteret trafik igennem, kan ikke lydløst indsætte et script i den beskyttede forbindelse. Behold certifikatverifikationen; en lokalt betroet inspektionsproxy, der terminerer TLS, er en anden opsætning.

Servér siden og dens afhængige ressourcer over HTTPS. Omdiriger HTTP-besøgende til HTTPS, og overvej HSTS til en udrulning, der konsekvent kan understøtte det. En omdirigering alene begynder med en ubeskyttet HTTP-udveksling for en besøgende, der brugte en HTTP-URL; en tidligere lært eller forudindlæst HSTS-politik ændrer det første valg.

Blokering af et indsat script kan mindske dets synlige virkninger, men svaret kan allerede indeholde ændret HTML eller omskrevne billed-URL'er. At erstatte ét gammelt funktionsnavn, tilføje en usædvanlig kommentar eller kortlægge en historisk indsættelsesadresse etablerer ikke indholdsintegritet for den næste mellemmand.

Når du undersøger en rapport, sammenlign det modtagne svar med oprindelsens tilsigtede indhold, og identificer, hvor TLS terminerer. Det bevis er mere nyttigt end at behandle hvert ukendt script som en fejl i webstedets egen applikationskode.

Relaterede artikler