Defaults.Exposed › Javítások › HSTS (Strict-Transport-Security)

Hogyan javítsd ki: HSTS (Strict-Transport-Security)

A HSTS egy egysoros utasítás, amelyet a webhelyed minden böngészőnek ad: 'mindig a biztonságos, titkosított kapcsolaton gyere vissza – soha a titkosítatlanon.' Enélkül a lakatod csendesen lehántható megosztott Wi-Fi-n, és az első webhelylátogatás ki van téve.

Az üzleted szempontjából lényeg: A HTTPS (a lakat) megléte nem ugyanaz, mint a kényszerítése. HSTS nélkül egy támadó ugyanazon a Wi-Fi-n csendesen visszaminősítheti az ügyfeled kapcsolatát sima, titkosítatlan HTTP-re – elfogva a bejelentkezéseket, kártyaadatokat és űrlapadatokat, miközben az ügyfél semmit sem lát. Az SSL-tanúsítványod, amelyért esetleg fizetsz, megkerülhető. A javítás ingyenes, és kb. 15 percet vesz igénybe annak, aki az oldalt kezeli.

Mibe kerülhet ez neked

• A kávézói, szállodai, repülőtéri vagy konferencia Wi-Fi-n lévő ügyfelek az oldaladon lévő kapcsolatuk csendesen visszaminősíthető és az adataik elolvashatók – anélkül, hogy bármilyen figyelmeztetés jelenne meg a képernyőjükön.
• Fizetett a HTTPS-ért, és van a lakat, de HSTS nélkül a támadók egyszerűen megkerülhetik; a tanúsítvány hamis biztonságérzetet ad.
• Az oldaladon lévő első látogatás (mielőtt a HTTPS-re való átirányítás megtörténne) az a gyenge pont, amelyet a támadók célba vesznek – a HSTS az, ami bezárja ezt minden visszatérő látogatásnál.
• Egy biztonsági kérdőív, kibervédelmi biztosítási nyomtatvány vagy vállalati vevő ellenőrzőlistája megjelöli a 'nincs HSTS' tételt, és megállítja az üzletet, amíg ki nem javítod.
• Ha az értéket tévesen állítod be (túl rövidre), a legrosszabbat kapod mindkét világból: konfigurálva tűnik, de szinte semmilyen valódi védelmet nem nyújt.

Miért fontos. A HTTPS védi a kapcsolatot, amint titkosítva van – de nem kényszeríti a böngészőket a használatára. A támadók kihasználják ezt a rést az 'SSL-lehántással': bármely megosztott hálózaton csendesen a titkosítatlan HTTP-n tartják a látogatót, olvasva mindent. A HSTS azt mondja a böngészőnek, hogy egyáltalán utasítsa el a sima HTTP-t a domainedhöz, hosszú ideig, tehát a rés az első látogatás után bezárul. Egyetlen válasz-fejléc, ingyenes hozzáadni, és a pontozásunkban valódi pontokat ér, mert egy hiányzó vagy túl rövid érték minden nyilvános Wi-Fi-n lévő látogatót kitesz.

Mi ez egyszerű szavakkal

Szinte biztosan van HTTPS-ed – a böngésző sávjában lévő kis lakat. Jó. De itt az a rész, amelyet szinte senkinek sem mondanak el: a HTTPS megléte nem ugyanaz, mint a kényszerítése.

A HTTPS titkosítja a kapcsolatot, amint a böngésző úgy dönt, hogy azt használja. A HSTS – a HTTP Strict Transport Security rövidítése – az az utasítás, amely mindig azt az opciót választatja a böngészővel. Egyetlen, láthatatlan sor, amelyet a webhelyed minden látogatónak küld, amelynek lényege:

„Ezentúl a domaineemhez csak a biztonságos kapcsolaton kommunikálj velem. Soha a titkosítatlann. Ne is próbálkozz.”

A böngésző megjegyzi ezt, és engedelmeskedik annyidáig, amennyit megadsz – általában egy évig. Egy látogató első biztonságos látogatása után a böngészőjük egyszerűen megtagadja, hogy sima, titkosítatlan HTTP-n töltse be az oldaladat, még akkor is, ha valami erre próbálja kényszeríteni.

HSTS nélkül ez az „mindig a biztonságos verzión” szabály nem létezik – és a támadók pontosan tudják, hogyan kell kihasználni a rést.

Mibe kerülhet ez neked

Ezek valós, mindennapi forgatókönyvek. Sosem nevesítünk valódi vállalkozást; ezek illusztrációi a rés kihasználásának.

1. A kávézói pénztár. Egy ügyfél megnyitja a boltodat kávézói Wi-Fi-n, és fizet. A ugyanazon a hálózaton lévő támadó egy ingyenes, jól ismert eszközzel sima HTTP-n tartja az ügyfelet a HTTPS helyett. Az ügyfél látja, ami normális oldaladnak tűnik – nincs figyelmeztetés, nincs törött lakat azon a helyen, ahol rátekintenének –, és beírja a kártyaadatait. A támadó minden billentyűleütést olvas. Az SSL-tanúsítványod semmit sem tett, mert a kapcsolatnak soha nem volt megengedve, hogy biztonságos legyen.

2. Az utazó munkavállaló. Egy munkatárs bejelentkezik az admin panelbe vagy a webmailjébe egy szállodából vagy repülőtérről. Ugyanaz a visszaminősítési trükk megfogja a felhasználónevüket és jelszavukat. Most a támadónak van egy útja be a vállalkozásodba – nem azért, mert a jelszavad politika gyenge volt, hanem azért, mert a bejelentkezési oldal titkosítatlan HTTP-n elérhető volt.

3. Az elakadt üzlet. Egy nagyobb ügyfél aláírás előtt elküldi a szokásos biztonsági kérdőívet. Az egyik sor megkérdezi: ‘Az oldala HSTS-sel kényszeríti-e a HTTPS-t?’ Az IT-kapcsolatodnak ‘nem’ választ kell adnia, és a beszerzési folyamat megáll, amíg rohanva javítasz egy ingyenes, 15 perces beállítást, amely most vörös zászlónak tűnik egy vevő előtt.

4. A kibervédelmi biztosítás vagy megfelelési ellenőrzés. Egy biztosító vizsgálata, vagy egy adatvédelmi helyzetét felülvizsgáló auditor megjelöli a hiányzó fejlécet. A személyes adatok titkosítása explicit elvárás az adatvédelmi szabályozások (GDPR 32. cikk) alatt, és ‘van tanúsítványunk, de nem kényszerítjük’ gyenge álláspont.

5. A hamis biztonságérzet. SSL-ért fizetsz, a lakat megjelenik, és mindenki feltételezi, hogy az oldal biztonságos. Ez nagyrészt igaz – amíg egy ügyfél megosztott hálózaton van, ami pontosan akkor, amikor a legsebezhetőbbek és a legkevésbé valószínű, hogy bármi rosszra gondolnak.

Az összefüggő szál: a költség nem elvont. Egy valódi ügyfél kártyája vagy bejelentkezése, elfogva a legrosszabb lehetséges pillanatban, semmilyen riasztás nélkül.

Mi is ez pontosan

Amikor egy böngésző oldalt kér a webhelyedtől, a szervered visszaküldi az oldalt néhány láthatatlan ‘fejléccel’ – extra utasítások, amelyeket a böngésző olvas, de a látogató soha nem lát. A HSTS az egyik ilyen fejléc:

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

Három rész számít:

• max-age – mennyi ideig (másodpercben) emlékezzen a böngésző arra, hogy kényszerítse a HTTPS-t. A 31536000 egy év. Ez a lényege: túl rövid és alig segít.
• includeSubDomains – kiterjeszti a szabályt minden aldomainre (shop., app., mail. stb.), nem csak a fő címedre.
• preload – bevezeti a domainedet egy mesterlistába, amely beépített a böngészőkbe, így a védelem még a látogató legelső kérésénél is érvényes, mielőtt valaha is látták volna az oldaladat.

Miért számít az ‘első látogatás’

A HSTS-nek van egy inherens korlátja: a böngésző csak azután engedelmeskedik a szabálynak, miután legalább egyszer látta a fejlécet. Tehát egy vadonatúj látogató legelső kapcsolata még mindig egy kis kitettségi ablak. Két dolog szűkíti ezt: egy HTTP-ről HTTPS-re való átirányítás (ami gyorsan a biztonságos verzióra viszi őket), és a preload (ami teljesen eltávolítja az ablakot). Ezért egy teljes beállítás a HSTS-t egy megfelelő átirányítással párosítja.

Mit jelent a „jó” beállítás – és hogyan pontozódik

Az ellenőrzésünk olvassa az élő fejlécet, és osztályozza a max-age-t:

Tehát egy fejléc, amely létezik, de néhány percre van beállítva, hibának minősül – konfigurálva tűnik, de nem végzi el a munkát. Cél egy év. Az ellenőrzés azt is megjegyzi, hogy az includeSubDomains és a preload jelen van-e.

Hogyan javítsd ki (ingyenes, ~15 perc)

Add ezt a részt annak, aki a weboldaladat kezeli – az IT-személyednek, webfejlesztőnek vagy tárhely ügyfélszolgálatnak. A javítás ingyenes. Egyetlen fejléc, vagy egy kapcsoló a tárhely platformon. Nincs mit venni.

Egy fontos sorrendiségi szabály először: a HSTS ragadós – amint engedélyezve van, a böngészők megtagadják a sima HTTP-t a domainedhöz a teljes max-age időtartamára. Tehát erősítsd meg, hogy a HTTPS megfelelően működik a fő oldaladon és minden aldomaineden, mielőtt széles körben bekapcsolod. A biztonságos út: tesztelj rövid értékkel → erősítsd meg, hogy semmi nem törik → emeld egy évre.

1. lépés – Ügyelj arra, hogy a HTTPS már mindenhol működjön

Látogasd meg az oldaladat és a fő aldomaineket https://-en, és erősítsd meg, hogy érvényes tanúsítvánnyal tisztán töltik. Erősítsd meg azt is, hogy a sima http:// kérések https://-re irányítódnak. (Ha nem, először javítsd a HTTP-ről HTTPS-re való átirányítást – a HSTS feltételezi, hogy már megvan.)

2. lépés – Add hozzá a fejlécet (válaszd ki a platformot)

Cloudflare (vagy hasonló CDN): Ez a legegyszerűbb. Menj a SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) résbe, és engedélyezd. Állítsd a Max-Age-t 6 hónapra vagy 12 hónapra, és engedélyezd az ‘Apply HSTS policy to subdomains’ opciót, amint biztos vagy, hogy az összes aldomain HTTPS-en van.

Nginx: adj hozzá a HTTPS server blokkodba:

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

Apache: ügyelj arra, hogy a mod_headers engedélyezve van, majd add hozzá a HTTPS virtuális hosztodhoz:

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

Microsoft IIS: add hozzá a web.config-ba az <customHeaders> belül:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Google Workspace / Microsoft 365 megjegyzés: ezek az e-mailedet hajtják, nem a weboldal tárhelyedet – a HSTS ott van beállítva, ahol a nyilvános webhelyed ténylegesen él (a CDN-ed, webszervered vagy site builder-ed), nem a Workspace/365 adminban. Ha az oldalad Squarespace, Wix vagy Shopify builderen van, a HSTS általában neked kezelt; ellenőrizd az SSL/biztonsági beállításaikat, ha az ellenőrzésünk megjelöli.

3. lépés – Tesztelj kicsiben, majd vállalj el

Kezdj max-age=300-zal (5 perc). Erősítsd meg, hogy az oldal még mindig tökéletesen tölt mindenhol. Majd emeld max-age=31536000-re (egy év). Ez a teljes pontszámot adó beállítás.

4. lépés (opcionális, arany standard) – preload

Amint biztos vagy, és egy évig includeSubDomains-szal futtattál egy éves fejlécet, benyújthatod a domained a hstspreload.org oldalon, hogy a böngészőkbe süssék. Ez teljesen bezárja az első látogatás ablakát. Kezeld tudatos elkötelezettségként – egy domain eltávolítása a listáról lassú.

Általános hibák

• A max-age túl rövidre állítása. Néhány perces vagy órás érték konfigurálva tűnik, de szinte semmilyen védelmet nem nyújt – és az ellenőrzésünk mindent egy napnál rövidebbet hibának kezel. Használj egy évet.
• Az includeSubDomains bekapcsolása, mielőtt az aldomainek HTTPS-re készen állnak. Ha egy aldomain nincs teljesen HTTPS-en, a ragadós szabály elérhetetlenné teheti a látogatók számára. Először töltsd át az összes aldomaint HTTPS-re.
• HSTS hozzáadása, de nincs HTTP-ről HTTPS-re való átirányítás. A HSTS feltételezi, hogy a látogatók elérik a biztonságos verziót; átirányítás nélkül az első látogatás feleslegesen ki van téve. Mindkettőt egyszerre javítsd.
• Egyből preload-ra ugrani, hogy ‘alaposak’ legyünk. A preload nehéz visszavonni. Szerezd meg fokozatosan egy stabil egyéves fejléc után – ne siess bele.
• Feltételezni, hogy a lakat fedezi. A lakat és a HSTS különböző dolgok. Lehet tökéletes tanúsítványod, és mégis megbukhat ezen az ellenőrzésen.

GYIK