Kufizoni rishkrimin e përmbajtjes nga proxy me no-transform dhe HTTPS

Një proxy që transformon përmbajtjen mund të ndryshojë një përgjigje në rrugën drejt shfletuesit: të rikompresojë një imazh, të rishkruajë shënimin ose të fusë JavaScript mbështetës. Një faqe që funksionon në një rrjet dhe merr shënim të panjohur në një tjetër mund të përballet pikërisht me këtë sjellje të ndërmjetësit.

Për një sajt që menaxhoni, HTTP ofron një direktivë të qartë përgjigjeje:

Cache-Control: no-transform

RFC 9111 kërkon që një ndërmjetës që merr këtë direktivë përgjigjeje ta lërë përmbajtjen të patransformuar, pavarësisht nëse ai ndërmjetës zbaton një cache. Kjo lidhet me rikompresimin e imazheve dhe futjen e shënimit, jo vetëm me atë nëse një objekt ruhet.

Mbajeni atë me politikën ekzistuese të cache

Nëse një përgjigje ka tashmë direktiva cache, shtojeni kërkesën me qëllim në vend që të hidhni pjesën tjetër të politikës. Për shembull, një aset publikisht i ruajtshëm në cache mund të ketë:

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

Ky shembull ruan një politikë freskie prej një ore ndërsa ndalon transformimin e përmbajtjes. no-transform nuk nënkupton no-store dhe nuk çaktivizon përpunimin e zakonshëm të transferimit. Vendoseni në përgjigjet përmbajtja origjinale e të cilave ka rëndësi, duke përfshirë përgjigjet e veçanta të imazheve kur është e përshtatshme.

Direktiva funksionon përmes përputhshmërisë së ndërmjetësit. Ajo nuk e pengon në mënyrë kriptografike një pajisje rrjeti të injorojë udhëzimin.

Mbroni edhe transportin

HTTPS i jep shfletuesit një lidhje me vërtetim dhe mbrojtje të integritetit drejt partnerit të tij TLS. Një proxy i zakonshëm transportuesi që kalon trafik të kriptuar nuk mund të fusë në heshtje një skript në atë lidhje të mbrojtur. Mbajini verifikimin e certifikatave në vend; një proxy inspektimi i besuar lokalisht që përfundon TLS është një rregullim tjetër.

Shërbeni faqen dhe burimet e saj të varura përmes HTTPS. Ridrejtini vizitorët HTTP në HTTPS dhe merrni parasysh HSTS për një vendosje që mund ta mbështesë vazhdimisht. Vetëm ridrejtimi fillon me një shkëmbim HTTP të pambrojtur për një vizitor që përdori një URL HTTP; një politikë HSTS e mësuar më parë ose e parangarkuar e ndryshon atë zgjedhje fillestare.

Bllokimi i një skripti të futur mund të zvogëlojë efektet e tij të dukshme, por përgjigja mund të përmbajë tashmë HTML të ndryshuar ose URL imazhesh të rishkruara. Zëvendësimi i një emri të vjetër funksioni, shtimi i një komenti të pazakontë ose hartëzimi i një adrese historike injektimi nuk vendos integritetin e përmbajtjes për ndërmjetësin tjetër.

Kur hetoni një raport, krahasoni përgjigjen e marrë me përmbajtjen e synuar të origjinës dhe identifikoni ku përfundon TLS. Ai provë është më e dobishme sesa trajtimi i çdo skripti të panjohur si defekt në kodin e aplikacionit të vetë sajtit.