HSTS beállítása anélkül, hogy kizárnád magad

A HSTS egyszerű, amíg nem az

A HTTP Strict Transport Security, röviden HSTS, azt mondja a böngészőknek: „ennél a webhelynél mindig HTTPS-t használj.” Amint a böngésző érvényes HTTPS-kapcsolaton keresztül megkapja a fejlécet, megjegyzi a szabályt az általad megadott időtartamra.

Ez hasznos. Megakadályozza a protokoll-visszaminősítéses támadásokat, csökkenti a véletlenül nem biztonságos kérések számát, és elkerüli azt a kellemetlen pillanatot, amikor a felhasználó beírja, hogy example.com, és egy átirányítás előtt röviden sima HTTP-t érint.

Ugyanakkor ragadós is. Ha rossz HSTS-szabályzatot teszel közzé, a böngészők jóval azután is érvényben tarthatják, hogy eltávolítottad a fejlécet a szerveredről. Így zárják ki magukat a csapatok: nem feltétlenül a saját adminfelületükről, hanem a felhasználók böngészőiből, az aldomainjeikből, a staging rendszerekből, a régi végpontokból és az elfelejtett szolgáltatásokból, amelyek még nem állnak készen a kötelező HTTPS-re.

A cél nem az, hogy elkerüld a HSTS-t. A cél az, hogy migrációként vezesd be, ne kapcsolóként.

Mit csinál valójában a HSTS fejléc

Egy tipikus HSTS fejléc így néz ki:

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

Három fontos része van:

• max-age: mennyi ideig, másodpercben, kényszerítse ki a böngésző a HTTPS-t ennél a hostnál.
• includeSubDomains: a szabály vonatkozzon-e minden aldomainre is.
• preload: jelzés arra, hogy szeretnéd a domaint felvenni a böngészők preload listáira.

A böngésző csak akkor bízik ebben a fejlécben, ha érvényes HTTPS-en keresztül kapja meg. Ha a tanúsítvány érvénytelen, lejárt vagy nem illeszkedik, a böngészőnek nem szabad új HSTS-szabályzatot elfogadnia abból a válaszból.

Miután a szabályzat eltárolódott, a jövőbeni http://example.com látogatási kísérleteket a böngésző még a kérés elküldése előtt https://example.com címre frissíti. Ez az adatvédelmi nyereség: a nem biztonságos kérés soha nem hagyja el az eszközt.

Kizárási forgatókönyvek, amelyeket érdemes elkerülni

A legtöbb HSTS-hibát nem a fő webhely okozza. A problémák a peremeken jelentkeznek.

1. Egy elfelejtett aldomain nem áll készen a HTTPS-re

Az includeSubDomains rendezett megoldásnak hangzik, de abszolút érvényű. Ha beállítod az example.com domainen, akkor vonatkozik ezekre is:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• bármi másra a domain alatt

Ha ezek közül bármelyik host nem tud érvényes HTTPS-t kiszolgálni, azok a felhasználók, akiknél a HSTS-szabályzat gyorsítótárazva van, nem fogják tudni HTTP-n elérni.

2. Lejár egy tanúsítvány

HSTS nélkül a felhasználók néha átkattintanak a tanúsítványfigyelmeztetéseken. Ez nem jó biztonsági gyakorlat, de előfordul.

HSTS mellett a modern böngészők nem engednek könnyű megkerülést a tanúsítványhibáknál az adott host esetében. Pont ez a lényeg. Ez egyben azt is jelenti, hogy a tanúsítványmegújításnak unalmasnak, felügyeltnek és teszteltnek kell lennie.

3. A staging vagy belső eszközök a production domain alatt élnek

A belső eszközök *.example.com alá helyezése fájdalmassá válhat, amint a szülődomain includeSubDomains beállítást használ. Ha ezek az eszközök önaláírt tanúsítványokat, privát hitelesítésszolgáltatókat, régi TLS-konfigurációkat vagy egyáltalán nem HTTPS-t használnak, a HSTS láthatóvá teszi ezt a rövidítést.

Ez az egyik oka annak, hogy sok csapat a belső és kísérleti rendszereket külön domain alatt tartja, saját biztonsági szabályzattal.

4. A preloadot rutinszerű jelölőnégyzetként kezelik

A HSTS preload nem csak egy újabb direktíva. Azt jelenti, hogy a domained HTTPS-only módban kerülhet be a böngészőkbe, még mielőtt bármely felhasználó meglátogatta volna a webhelyedet.

Ez bezárja az „első látogatás” rést, de sokkal nehezebb visszavonni. A preload listákról való eltávolítás hetekig vagy hónapokig is eltarthat, mire eljut a felhasználókhoz, a böngészők kiadási ciklusaitól függően. A preload stabil, érett domainekhez való. Nem olyan webhelyhez, amely még csak most térképezi fel az aldomainjeit.

Biztonságos bevezetési terv

1. lépés: Auditálj minden általad kezelt hostnevet

Az includeSubDomains beállítása előtt listázz minden hostnevet a domain alatt. A DNS-rekordok jó kiindulópontot jelentenek, de nem adják a teljes képet. Ellenőrizd a CDN-konfigurációkat, a tárhelykezelő felületeket, az e-mailhez kapcsolódó hostneveket, a régi marketingeszközöket, a storage bucketeket és a belső dokumentációt.

Minden hostnévnél válaszold meg:

• HTTP-t, HTTPS-t vagy mindkettőt szolgál ki?
• Érvényes a HTTPS-tanúsítvány, és automatikusan megújul?
• Tisztán átirányítja a HTTP-t HTTPS-re?
• Nyilvánosnak szánták?
• Szükség van még rá?

Ha a csapatodnak már vannak production fejléc-hibakeresési szokásai, ez természetesen illeszkedik az átirányítási és fejlécellenőrzések mellé. Ezt a munkafolyamatot bemutattuk itt: egy kis eszközkészlet production átirányítások és HTTP-fejlécek hibakereséséhez.

2. lépés: Javítsd ki a HTTPS-t, mielőtt HSTS-t adnál hozzá

A HSTS nem tesz biztonságossá egy hibás HTTPS-beállítást. Csak kötelezővé teszi a HTTPS-t.

Engedélyezés előtt ellenőrizd:

• A TLS-tanúsítványok lefedik a megfelelő hostneveket.
• A tanúsítványok automatikusan megújulnak.
• A HTTP lehetőség szerint egyetlen tiszta lépéssel irányít át HTTPS-re.
• A kanonikus host átirányításai következetesek, például non-www irányból www felé, vagy fordítva.
• Az alkalmazás assetjei nem függenek nem biztonságos http:// URL-ektől.

A mixed content ritkább, mint korábban, de még mindig megjelenik régi CMS-témákban, analitikai snippetekben, beágyazott médiában és hard-coded képelérési utakban.

3. lépés: Kezdd nagyon rövid max-age értékkel

Ne egy évvel kezdd. Kezdd öt perccel:

Strict-Transport-Security: max-age=300

Ezt csak azon a hostnéven vezesd be, amelyet tesztelsz, általában a kanonikus production webhelyen. Az includeSubDomains egyelőre maradjon ki.

Ezután tesztelj valódi böngészőkben és parancssori kérésekkel:

curl -I https://example.com

Pontosan egy Strict-Transport-Security fejlécet kell látnod. Az app server és a CDN által egyszerre küldött duplikált HSTS-fejlécek gyakori zavarforrást jelentenek. A böngészők általában az effektív szabályzatot alkalmazzák, de egy incidenst hibakereső embernek nincs szüksége kétértelműségre.

4. lépés: Növeld fokozatosan

Ha semmi nem törik el, növeld az időtartamot szakaszosan:

Strict-Transport-Security: max-age=86400

Majd:

Strict-Transport-Security: max-age=604800

Aztán esetleg:

Strict-Transport-Security: max-age=2592000

Egy praktikus ütemezés:

• 5 perc
• 1 nap
• 1 hét
• 1 hónap
• 6 hónap vagy 1 év

Nem jár díj a sietésért. A szakaszos bevezetés lényege az, hogy időt adj a monitoringnak, a support inboxnak és a peremeseteknek, hogy megmutassák, mit hagyott ki az ellenőrzőlistád.

5. lépés: Csak akkor add hozzá az includeSubDomains beállítást, ha az audit valódi

Amint minden nyilvános aldomain HTTPS-ready, megfontolhatod ezt:

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

Ez az a pillanat, amikor érdemes konzervatívnak lenni. Ha egy régi szolgáltatásnak még mindig HTTP-re van szüksége, ne add hozzá az includeSubDomains beállítást a szülődomainhez. Vagy migráld azt a szolgáltatást, vagy mozgasd másik domainre, vagy fogadd el, hogy a HSTS-szabályzatodnak egyelőre szűkebbnek kell maradnia.

A biztonsági fejléceknek a valóságot kell tükrözniük. Nem motivációs poszterként kell használni őket olyan infrastruktúrához, amelyben később reménykedsz.

6. lépés: Kezeld a preloadot külön projektként

Csak akkor fontold meg a preloadot, ha az alábbiak mind igazak:

• A domain és minden aldomain támogatja az érvényes HTTPS-t.
• A HTTP HTTPS-re irányít át.
• A HSTS fejléc legalább 31536000 másodperces max-age értéket használ.
• A fejléc tartalmazza az includeSubDomains beállítást.
• A fejléc tartalmazza a preload beállítást.
• Biztos vagy benne, hogy a domain alatt sehol nem lesz szükséged sima HTTP-re.

Egy preload-ready fejléc így néz ki:

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

A preload listára való beküldés hosszú távú elköteleződés. Ha a webhely egy kampány-microsite, ideiglenes termékdomain vagy tisztázatlan tulajdonosi határokkal rendelkező domain, hagyd ki.

Konfigurációs példák

Nginx

Használd az always beállítást, hogy a fejléc hibaüzeneteknél is elküldésre kerüljön:

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

Miután a bevezetés stabil:

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

Apache

Engedélyezett mod_headers mellett:

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

Később:

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

CDN vagy edge platform

Ha a CDN-ed állít be válaszfejléceket, lehetőleg egy helyen kezeld a HSTS-t. Ne állíts be egy szabályzatot az originen és egy másikat az edge-en, hacsak nincs rá nagyon világos okod.

Ellenőrizd azt is, hogy a CDN alkalmazza-e a fejléceket átirányításokra, gyorsítótárazott hibákra és egyedi hibaoldalakra. Egy production webhely nem csak a 200 OK válaszaiból áll.

Hogyan vond vissza biztonságosan a HSTS-t

Ha le kell tiltanod a HSTS-t, küldd ezt:

Strict-Transport-Security: max-age=0

De van egy bökkenő: a böngészőnek érvényes HTTPS-en keresztül sikeresen el kell érnie a webhelyet ahhoz, hogy megkapja ezt a fejlécet. Ha maga a HTTPS hibás, a gyorsítótárazott HSTS-szabályzattal rendelkező felhasználók nem tudják lekérni az utasítást, amely törölné azt.

Ezért a szokásos helyreállítási sorrend:

1. Állítsd helyre az érvényes HTTPS-t.
2. Szolgáld ki ezt: Strict-Transport-Security: max-age=0.
3. Tartsd érvényben elég ideig ahhoz, hogy a visszatérő felhasználók megkapják.
4. Az incidens megoldása után távolítsd el vagy cseréld le a fejlécet.

Ha a domain preloaded, a max-age=0 kiszolgálása nem elég az új böngészőprofilok számára. Kérned kell a preload listáról való eltávolítást is, majd meg kell várnod, amíg ez a változás böngészőfrissítéseken keresztül eljut a felhasználókhoz.

Tesztelési ellenőrzőlista élesítés előtt

Használd ezt az ellenőrzőlistát, mielőtt növeled a max-age értéket vagy hozzáadod az includeSubDomains beállítást:

• A kanonikus HTTPS URL érvényes tanúsítványt ad vissza.
• A HTTP HTTPS-re irányít át.
• Csak egy HSTS fejléc van.
• A fejléc megjelenik az átirányításokon és a hibaválaszokon, ahol ez indokolt.
• Minden nyilvános aldomain rendelkezik érvényes HTTPS-sel.
• A tanúsítványmegújítás felügyelve van.
• Nincs kritikus belső rendszer, amely HTTP-től függ ugyanazon szülődomain alatt.
• A preloadról kifejezetten beszéltetek, nem megszokásból került hozzáadásra.

A Lighthouse bizonyos kontextusokban jelezheti a hiányzó vagy gyenge biztonsági fejléceket is, de nem szabad, hogy ez legyen az egyetlen ellenőrzési módszered. Ha egy szélesebb felülvizsgálat részeként használod, az eredményeket jelzésekként olvasd, ne ítéletekként; ugyanez a szemlélet érvényes akkor is, amikor pánik nélkül olvasol Lighthouse jelentést.

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

💡 Próbálja ki ezt: Minden HSTS-módosítás előtt és után vizsgálja meg a Strict-Transport-Security választ a Get Headers segítségével, hogy megerősítse: a max-age, includeSubDomains és preload értékek megfelelnek az elvárásainak.

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

Az adatvédelmi érv a HSTS mellett

A HSTS-t gyakran biztonsági fejlécként mutatják be, és az is. De adatvédelmi előnye is van: csökkenti annak esélyét, hogy a felhasználó első kérése sima HTTP-n szivárogjon ki egy nem megbízható hálózaton.

Ez számít repülőtéri Wi-Fi-n, szállodai hálózatokon, vállalati vendéghálózatokon és bárhol, ahol a felhasználó forgalmát megfigyelhetik vagy módosíthatják. Egy sima HTTP-kérés felfedheti a hostnevet, az elérési utat, a Secure flag nélküli cookie-kat és más kérésrészleteket. A HTTPS nem varázslat, de következetes kikényszerítése megszüntet egy teljes, elkerülhető szivárgási osztályt.

A legjobb HSTS-bevezetések érdektelenek. Lassan kerülnek bevezetésre, megbízható tanúsítványok támasztják alá őket, és elég unalmasak ahhoz, hogy senki ne vegye észre. Pontosan ezt szeretnéd egy olyan fejléctől, amelynek hibamódja drámai lehet.