Kaip nustatyti HSTS neužsirakinant savęs

HSTS paprastas tol, kol toks nebėra

HTTP Strict Transport Security, paprastai trumpinamas kaip HSTS, naršyklėms nurodo: „šiai svetainei visada naudok HTTPS.“ Kai naršyklė gauna šią antraštę per galiojantį HTTPS ryšį, ji įsimena taisyklę jūsų nurodytam laikotarpiui.

Tai naudinga. Tai apsaugo nuo protokolo pažeminimo atakų, sumažina atsitiktinių nesaugių užklausų skaičių ir padeda išvengti nepatogaus momento, kai naudotojas įveda example.com ir trumpam paliečia paprastą HTTP prieš nukreipimą.

Tačiau tai ir labai „limpa“. Jei paskelbsite netinkamą HSTS politiką, naršyklės gali ją taikyti dar ilgai po to, kai pašalinsite antraštę iš serverio. Taip komandos ir užsirakina: nebūtinai nuo savo administravimo skydelio, bet nuo naudotojų naršyklių, subdomenų, staging sistemų, senų galinių taškų ir pamirštų paslaugų, kurios dar nepasirengusios priverstiniam HTTPS.

Tikslas nėra vengti HSTS. Tikslas yra diegti jį kaip migraciją, o ne kaip jungiklį.

Ką iš tikrųjų daro HSTS antraštė

Tipinė HSTS antraštė atrodo taip:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Ji turi tris svarbias dalis:

• max-age: kiek laiko sekundėmis naršyklė turėtų priverstinai naudoti HTTPS šiam hostui.
• includeSubDomains: ar taisyklė taip pat taikoma kiekvienam subdomenui.
• preload: signalas, kad norite įtraukti domeną į naršyklių preload sąrašus.

Naršyklė pasitiki šia antrašte tik tada, kai gauna ją per galiojantį HTTPS. Jei sertifikatas negalioja, yra pasibaigęs arba neatitinka, naršyklė neturėtų priimti naujos HSTS politikos iš tokio atsako.

Kai politika išsaugoma, būsimi bandymai aplankyti http://example.com naršyklės yra atnaujinami į https://example.com dar prieš išsiunčiant užklausą. Čia ir yra privatumo laimėjimas: nesaugi užklausa niekada nepalieka įrenginio.

Užsirakinimo scenarijai, kurių reikia vengti

Daugumą HSTS nesėkmių sukelia ne pagrindinė svetainė. Jos įvyksta pakraščiuose.

1. Pamirštas subdomenas nėra paruoštas HTTPS

includeSubDomains skamba tvarkingai, bet jis yra absoliutus. Jei nustatote jį example.com, jis taikomas:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• viskam kitam po tuo domenu

Jei kuris nors iš šių hostų negali pateikti galiojančio HTTPS, naudotojai, kurių naršyklėse HSTS politika yra talpykloje, negalės jų pasiekti per HTTP.

2. Sertifikatas baigia galioti

Be HSTS naudotojai kartais pereina per sertifikatų įspėjimus. Tai nėra gera saugumo praktika, bet taip nutinka.

Su HSTS šiuolaikinės naršyklės neleidžia lengvai apeiti to hosto sertifikato klaidų. Tokia ir yra esmė. Tai taip pat reiškia, kad sertifikatų atnaujinimas turi būti nuobodus, stebimas ir testuojamas.

3. Staging arba vidiniai įrankiai veikia po produkcijos domenu

Vidinius įrankius laikyti po *.example.com gali tapti skausminga, kai tėvinis domenas naudoja includeSubDomains. Jei tie įrankiai naudoja savarankiškai pasirašytus sertifikatus, privačias sertifikavimo institucijas, senas TLS konfigūracijas arba apskritai neturi HTTPS, HSTS atskleis šį trumpinį.

Tai viena priežasčių, kodėl daugelis komandų vidines ir eksperimentines sistemas laiko atskirame domene, turinčiame savo saugumo politiką.

4. Preload laikomas įprastu žymimuoju langeliu

HSTS preload nėra tik dar viena direktyva. Tai reiškia, kad jūsų domenas gali būti pristatytas naršyklėse kaip tik HTTPS dar prieš bet kuriam naudotojui apsilankant jūsų svetainėje.

Tai uždaro „pirmojo apsilankymo“ spragą, bet tai daug sunkiau atšaukti. Pašalinimas iš preload sąrašų gali užtrukti savaites ar mėnesius, kol pasieks naudotojus, priklausomai nuo naršyklių leidimų ciklų. Preload tinka stabiliems, brandiems domenams. Jis netinka svetainei, kuri dar tik aiškinasi savo subdomenų inventorių.

Saugus diegimo planas

1 žingsnis: audituokite kiekvieną valdomą hosto vardą

Prieš nustatydami includeSubDomains, sudarykite kiekvieno po domenu esančio hosto vardo sąrašą. DNS įrašai yra pradžia, bet ne visa istorija. Patikrinkite CDN konfigūracijas, hostingo valdymo skydelius, su el. paštu susijusius hostų vardus, senus rinkodaros įrankius, saugyklų bucket’us ir vidinę dokumentaciją.

Kiekvienam hosto vardui atsakykite:

• Ar jis aptarnauja HTTP, HTTPS, ar abu?
• Ar HTTPS sertifikatas galioja ir automatiškai atnaujinamas?
• Ar HTTP švariai nukreipiamas į HTTPS?
• Ar jis turi būti viešas?
• Ar jo vis dar reikia?

Jei jūsų komanda jau turi produkcinių antraščių derinimo įpročių, tai natūraliai dera šalia nukreipimų ir antraščių patikrų. Šį darbo procesą aptarėme straipsnyje mažas įrankių rinkinys nukreipimams ir HTTP antraštėms produkcijoje derinti.

2 žingsnis: sutvarkykite HTTPS prieš pridėdami HSTS

HSTS nepadaro sugadintos HTTPS sąrankos saugios. Jis tik padaro HTTPS privalomą.

Prieš įjungdami, patikrinkite:

• TLS sertifikatai apima tinkamus hostų vardus.
• Sertifikatai atnaujinami automatiškai.
• HTTP nukreipiamas į HTTPS vienu švariu šuoliu, kur įmanoma.
• Kanoninio hosto nukreipimai yra nuoseklūs, pavyzdžiui, iš ne www į www arba atvirkščiai.
• Programos ištekliai nepriklauso nuo nesaugių http:// URL.

Mišrus turinys pasitaiko rečiau nei anksčiau, bet jis vis dar atsiranda senose CMS temose, analizės fragmentuose, įterptoje medijoje ir kietai įrašytuose paveikslėlių keliuose.

3 žingsnis: pradėkite nuo labai trumpo max-age

Nepradėkite nuo vienų metų. Pradėkite nuo penkių minučių:

Strict-Transport-Security: max-age=300

Įdiekite tai tik hosto vardui, kurį testuojate, paprastai kanoninei produkcinei svetainei. Kol kas nenaudokite includeSubDomains.

Tada testuokite tikrose naršyklėse ir komandinės eilutės užklausomis:

curl -I https://example.com

Turėtumėte matyti tiksliai vieną Strict-Transport-Security antraštę. Pasikartojančios HSTS antraštės iš programos serverio ir CDN yra dažnas painiavos šaltinis. Naršyklės paprastai taiko efektyvią politiką, bet žmonėms, derinantiems incidentą, nereikia dviprasmybių.

4 žingsnis: didinkite palaipsniui

Jei niekas nesulūžta, didinkite trukmę etapais:

Strict-Transport-Security: max-age=86400

Tada:

Strict-Transport-Security: max-age=604800

Tada galbūt:

Strict-Transport-Security: max-age=2592000

Praktiškas grafikas būtų toks:

• 5 minutės
• 1 diena
• 1 savaitė
• 1 mėnuo
• 6 mėnesiai arba 1 metai

Už skubėjimą prizo nėra. Visa laipsniško diegimo esmė – suteikti stebėsenai, pagalbos pašto dėžutei ir ribiniams atvejams laiko parodyti, ko nepastebėjo jūsų kontrolinis sąrašas.

5 žingsnis: pridėkite includeSubDomains tik po tikro audito

Kai kiekvienas viešas subdomenas paruoštas HTTPS, galite svarstyti:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Šiuo momentu verta būti konservatyviems. Jei vienai senai paslaugai vis dar reikia HTTP, nepridėkite includeSubDomains tėviniam domenui. Arba migruokite tą paslaugą, perkelkite ją į kitą domeną, arba susitaikykite, kad jūsų HSTS politika kol kas turi likti siauresnė.

Saugumo antraštės turėtų atspindėti realybę. Jos neturėtų būti naudojamos kaip motyvaciniai plakatai infrastruktūrai, kurią tikitės turėti vėliau.

6 žingsnis: preload laikykite atskiru projektu

Preload svarstykite tik tada, kai teisingi visi šie teiginiai:

• Domenas ir visi subdomenai palaiko galiojantį HTTPS.
• HTTP nukreipiamas į HTTPS.
• HSTS antraštė naudoja bent 31536000 sekundžių max-age.
• Antraštėje yra includeSubDomains.
• Antraštėje yra preload.
• Esate tikri, kad niekur po domenu neprireiks paprasto HTTP.

Preload paruošta antraštė atrodo taip:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Pateikimas į preload sąrašą yra ilgalaikis įsipareigojimas. Jei svetainė yra kampanijos mikrosvetainė, laikinas produkto domenas arba domenas su neaiškiomis nuosavybės ribomis, praleiskite tai.

Konfigūracijos pavyzdžiai

Nginx

Naudokite always, kad antraštė būtų siunčiama ir klaidų atsakuose:

add_header Strict-Transport-Security "max-age=300" always;

Kai diegimas stabilus:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Įjungus mod_headers:

Header always set Strict-Transport-Security "max-age=300"

Vėliau:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN arba krašto platforma

Jei jūsų CDN nustato atsako antraštes, geriau valdykite HSTS vienoje vietoje. Nenustatykite vienos politikos kilmės serveryje ir kitos krašte, nebent turite labai aiškią priežastį.

Taip pat patikrinkite, ar CDN taiko antraštes nukreipimams, talpykloje esantiems klaidų atsakams ir pasirinktinėms klaidų puslapių versijoms. Produkcinė svetainė nėra vien jos 200 OK atsakas.

Kaip saugiai atšaukti HSTS

Jei reikia išjungti HSTS, siųskite:

Strict-Transport-Security: max-age=0

Tačiau yra kabliukas: naršyklė turi sėkmingai pasiekti svetainę per galiojantį HTTPS, kad gautų šią antraštę. Jei pats HTTPS sugedęs, naudotojai su talpykloje esančia HSTS politika negalės pasiimti instrukcijos, kuri ją išvalytų.

Todėl įprasta atkūrimo tvarka yra tokia:

1. Atkurti galiojantį HTTPS.
2. Pateikti Strict-Transport-Security: max-age=0.
3. Laikyti tai pakankamai ilgai, kad grįžtantys naudotojai tai gautų.
4. Pašalinti arba pakeisti antraštę, kai incidentas išspręstas.

Jei domenas yra preload sąraše, max-age=0 pateikimo nepakanka naujiems naršyklių profiliams. Taip pat reikia paprašyti pašalinti iš preload sąrašo ir laukti, kol šis pakeitimas pasieks naudotojus per naršyklių atnaujinimus.

Testavimo kontrolinis sąrašas prieš paleidžiant

Naudokite šį kontrolinį sąrašą prieš didindami max-age arba pridėdami includeSubDomains:

• Kanoninis HTTPS URL grąžina galiojantį sertifikatą.
• HTTP nukreipiamas į HTTPS.
• Yra tik viena HSTS antraštė.
• Antraštė rodoma nukreipimuose ir klaidų atsakuose, kur tai tinkama.
• Visi vieši subdomenai turi galiojantį HTTPS.
• Sertifikatų atnaujinimas stebimas.
• Jokia kritinė vidinė sistema nepriklauso nuo HTTP po tuo pačiu tėviniu domenu.
• Preload buvo aptartas aiškiai, o ne pridėtas iš įpročio.

Lighthouse kai kuriuose kontekstuose taip pat gali pažymėti trūkstamas arba silpnas saugumo antraštes, bet tai neturėtų būti vienintelis jūsų patikros metodas. Jei naudojate jį kaip platesnės peržiūros dalį, išvadas skaitykite kaip signalus, o ne kaip nuosprendžius; tas pats požiūris tinka, kai skaitote Lighthouse ataskaitą nepanikuodami.

<!-- tool-cta:start -->

💡 Išbandykite tai: Prieš ir po kiekvieno HSTS pakeitimo patikrinkite Strict-Transport-Security atsaką naudodami Get Headers, kad įsitikintumėte, jog max-age, includeSubDomains ir preload yra tokie, kokių tikitės.

<!-- tool-cta:end -->

Privatumo argumentas už HSTS

HSTS dažnai pristatomas kaip saugumo antraštė, ir taip yra. Jis taip pat turi privatumo naudą: sumažina tikimybę, kad pirmoji naudotojo užklausa nutekės per paprastą HTTP nepatikimame tinkle.

Tai svarbu oro uostų Wi-Fi, viešbučių tinkluose, įmonių svečių tinkluose ir visur, kur naudotojo srautas gali būti stebimas arba keičiamas. Paprasta HTTP užklausa gali atskleisti hosto vardą, kelią, slapukus be Secure žymos ir kitą užklausos informaciją. HTTPS nėra magija, bet nuoseklus jo priverstinis naudojimas pašalina visą išvengiamo nutekėjimo klasę.

Geriausi HSTS diegimai yra neįdomūs. Jie diegiami lėtai, paremti patikimais sertifikatais ir pakankamai nuobodūs, kad niekas jų nepastebėtų. Būtent to ir norite iš antraštės, kurios gedimo režimas gali būti dramatiškas.