Абмежаванне перазапісу змесціва праз проксі з дапамогай no-transform і HTTPS

Проксі, які пераўтварае змесціва, можа змяніць адказ на шляху да браўзера: перасціснуць выяву, перазапісаць разметку або ўставіць дапаможны JavaScript. Старонка, якая працуе ў адной сетцы і атрымлівае незнаёмую разметку ў іншай, можа сутыкацца менавіта з такімі дзеяннямі пасярэдніка.

Для сайта, які вы кіруеце, HTTP прадастаўляе яўную дырэктыву адказу:

Cache-Control: no-transform

RFC 9111 патрабуе, каб пасярэднік, які атрымаў гэтую дырэктыву адказу, пакінуў змесціва непераўтвораным, незалежна ад таго, ці рэалізуе ён кэш. Гэта датычыцца перасціску выяў і ўстаўкі разметкі, а не толькі таго, ці будзе аб'ект захаваны.

Захавайце гэта разам з існуючай палітыкай кэша

Калі адказ ужо мае дырэктывы кэша, дадайце патрабаванне свядома, а не адкідвайце астатнюю палітыку. Напрыклад, публічна кэшаваны рэсурс можа мець:

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

Гэты прыклад захоўвае палітыку свежасці ў адну гадзіну, забараняючы пераўтварэнне змесціва. no-transform не азначае no-store і не адключае звычайную апрацоўку перадачы. Усталюйце яго для адказаў, арыгінальнае змесціва якіх мае значэнне, уключаючы асобныя адказы з выявамі, дзе гэта мэтазгодна.

Дырэктыва працуе праз выкананне яе пасярэднікам. Яна не прадухіляе крыптаграфічна ігнараванне інструкцыі сеткавай прыладай.

Абараніце таксама транспарт

HTTPS дае браўзеру злучэнне з аўтэнтыфікацыяй і абаронай цэласнасці да яго партнёра па TLS. Звычайны аператарскі проксі, які прапускае зашыфраваны трафік, не можа моўчкі ўставіць скрыпт у гэтае абароненае злучэнне. Пакіньце праверку сертыфіката ўключанай; лакальна давераны інспекцыйны проксі, які спыняе TLS, — гэта іншая схема.

Падавайце старонку і залежныя рэсурсы праз HTTPS. Перанакіроўвайце наведвальнікаў HTTP на HTTPS і разгледзьце HSTS для разгортвання, якое можа паслядоўна яго падтрымліваць. Адно перанакіраванне пачынаецца з незашчышчанага абмену HTTP для наведвальніка, які выкарыстаў HTTP-адрас; раней засвоеная або папярэдне загружаная палітыка HSTS змяняе гэты першапачатковы выбар.

Блакаванне ўстаўленага скрыпта можа паменшыць яго бачныя эфекты, але адказ можа ўжо змяшчаць зменены HTML або перазапісаныя URL выяў. Замена аднаго старога імя функцыі, даданне незвычайнага каментара або адлюстраванне гістарычнага адраса ўстаўкі не ўстанаўлівае цэласнасць змесціва для наступнага пасярэдніка.

Разследуючы паведамленне, параўнайце атрыманы адказ з меркаваным змесцівам крыніцы і вызначце, дзе спыняецца TLS. Гэтыя доказы карыснейшыя, чым стаўленне да кожнага незнаёмага скрыпта як да памылкі ва ўласным кодзе праграмы сайта.