Limitahan ang muling pagsulat ng nilalaman ng proxy gamit ang no-transform at HTTPS

Ang proxy na nagbabago ng nilalaman ay maaaring magbago ng tugon habang papunta sa browser: muling i-compress ang larawan, muling isulat ang markup o magsingit ng sumusuportang JavaScript. Ang pahinang gumagana sa isang network at nakakakuha ng kakaibang markup sa iba ay maaaring nakakaharap ng ganoong gawi ng tagapamagitan.

Para sa site na pinapatakbo mo, nagbibigay ang HTTP ng malinaw na direktiba sa tugon:

Cache-Control: no-transform

Inaatasan ng RFC 9111 ang tagapamagitang tumatanggap ng direktibang ito na iwanang hindi binago ang nilalaman, may cache man ito o wala. May kaugnayan ito sa muling pag-compress ng larawan at pagsingit ng markup, hindi lamang sa kung itatabi ang isang bagay.

Panatilihin ito kasama ng umiiral na patakaran sa cache

Kung may mga direktiba na sa cache ang tugon, idagdag ang pangangailangan nang sinasadya sa halip na itapon ang natitirang patakaran. Halimbawa, ang isang asset na pampublikong maaaring i-cache ay maaaring may:

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

Pinapanatili ng halimbawang ito ang isang oras na patakaran sa pagiging sariwa habang ipinagbabawal ang pagbabago ng nilalaman. Ang no-transform ay hindi nangangahulugang no-store at hindi pinapatay ang ordinaryong pagproseso ng paglilipat. Itakda ito sa mga tugon na mahalaga ang orihinal na nilalaman, kasama ang magkahiwalay na tugon ng larawan kung naaangkop.

Gumagana ang direktiba sa pamamagitan ng pagsunod ng tagapamagitan. Hindi nito cryptographically pinipigilan ang isang aparato sa network na balewalain ang tagubilin.

Protektahan din ang transportasyon

Binibigyan ng HTTPS ang browser ng koneksyon na may pagpapatunay at proteksyon sa integridad patungo sa kapareha nitong TLS. Ang ordinaryong carrier proxy na nagpapadaan ng naka-encrypt na trapiko ay hindi maaaring tahimik na magsingit ng script sa protektadong koneksyong iyon. Panatilihing naka-on ang pagpapatunay ng sertipiko; ang lokal na pinagkakatiwalaang inspection proxy na nagtatapos ng TLS ay ibang kaayusan.

Ihatid ang pahina at ang mga nakadependeng resource nito sa HTTPS. I-redirect ang mga bisitang HTTP sa HTTPS, at isaalang-alang ang HSTS para sa deployment na matatag na makakasuporta nito. Ang redirect lamang ay nagsisimula sa hindi protektadong HTTP exchange para sa bisitang gumamit ng HTTP URL; ang dating natutunan o na-preload na HSTS policy ay nagbabago sa unang pagpipiliang iyon.

Ang pagharang sa na-inject na script ay maaaring mabawasan ang nakikitang epekto, ngunit ang tugon ay maaaring may binagong HTML o muling isinulat na URL ng larawan. Ang pagpapalit ng isang lumang pangalan ng function, pagdaragdag ng kakaibang komento o pagmamapa ng makasaysayang address ng injection ay hindi nagtatatag ng integridad ng nilalaman para sa susunod na tagapamagitan.

Kapag sinisiyasat ang isang ulat, ihambing ang natanggap na tugon sa nilalayong nilalaman ng pinagmulan at tukuyin kung saan nagtatapos ang TLS. Ang ebidensiyang iyon ay mas kapaki-pakinabang kaysa ituring ang bawat kakaibang script bilang bug sa sariling code ng aplikasyon ng site.