Defaults.Exposed › Korjaukset › HSTS (Strict-Transport-Security)

Kuinka korjata HSTS (Strict-Transport-Security)

HSTS on yksirivi ohje, jonka verkkosivustosi antaa jokaiselle selaimelle: 'tule aina takaisin luokseni turvallisen, salatun yhteyden kautta – älä koskaan turvattoman.' Ilman sitä lukkosi voidaan hiljaa poistaa jaetussa WiFissä, ja aivan ensimmäinen sivustovierailusi on alttiina.

Lyhyesti liiketoiminnallesi: HTTPS:n (lukon) olemassaolo ei ole sama asia kuin sen pakottaminen. Ilman HSTS:ää hyökkääjä samassa WiFissä kuin asiakkaasi voi hiljaa alentaa yhteyden tavalliseen, salaamattomaan HTTP:hen – kaapaten kirjautumiset, korttitiedot ja lomaketiedot samalla kun asiakas ei näe mitään vikaa. SSL-sertifikaattisi, josta saatat maksaa, ohitetaan. Korjaus on ilmainen ja vie noin 15 minuuttia verkkosivustoasi hallinnoivalle.

Mitä tämä voi maksaa sinulle

• Kahvilan, hotellin, lentokentän tai konferenssin WiFissä olevat asiakkaat voivat saada yhteytensä sivustollesi hiljaa alennetuksi ja tietonsa luetuksi – ilman mitään varoitusta näytöllään.
• Maksoivat HTTPS:stä ja heillä on lukko, mutta ilman HSTS:ää hyökkääjät voivat yksinkertaisesti kiertää sen; sertifikaatti antaa väärän turvallisuuden tunteen.
• Juuri ensimmäinen sivustovierailusi (ennen HTTPS:ään uudelleenohjausta) on heikko kohta, johon hyökkääjät kohdistuvat – HSTS sulkee sen jokaisen paluuvierailun osalta.
• Tietoturvakyselylomake, kyberturvallisuusvakuutuslomake tai yritysostajan tarkistuslista merkitsee 'ei HSTS:ää' ja pysäyttää sopimuksen kunnes se on korjattu.
• Arvo asetetaan väärin (liian lyhyt) ja saat molemman maailman pahan puolen: se näyttää konfiguroidulta, mutta tarjoaa lähes olemattoman suojan.

Miksi tällä on merkitystä. HTTPS suojaa yhteyden kun se on salattu – mutta se ei pakota selaimia käyttämään sitä. Hyökkääjät hyödyntävät tätä aukkoa 'SSL-strippingillä': missä tahansa jaetussa verkossa he hiljaa pitävät kävijän turvattomassa HTTP:ssä, lukien kaiken. HSTS kertoo selaimelle kieltäytymään pelkästä HTTP:stä kokonaan verkkotunnuksellesi pitkäksi aikaa, joten aukko sulkeutuu ensimmäisen vierailun jälkeen. Se on yksittäinen vastausotsikko, ilmainen lisätä, ja pisteytyksessämme se on todellisten pisteiden arvoinen, koska puuttuva tai liian lyhyt arvo altistaa jokaisen kävijän julkisessa WiFissä.

Mitä tämä on selkokielellä

Sinulla on lähes varmasti HTTPS – pieni lukko selaimen osoitepalkissa. Hyvä. Mutta tässä on osa, josta lähes kukaan ei kerro: HTTPS:n olemassaolo ei ole sama asia kuin sen pakottaminen.

HTTPS tekee yhteyden salatuksi kun selain päättää käyttää sitä. HSTS – lyhenne sanoista HTTP Strict Transport Security – on ohje, joka pakottaa selaimen aina käyttämään sitä. Se on yksittäinen, näkymätön rivi, jonka verkkosivustosi lähettää jokaiselle kävijälle, joka sanoo käytännössä:

“Tästä eteenpäin, verkkotunnukselleni, yhdistä aina minuun vain turvallisen yhteyden kautta. Ei koskaan turvattoman. Älä edes yritä.”

Selain muistaa sen ja tottelee niin kauan kuin kerrot sille – tyypillisesti vuoden. Ensimmäisen turvallisen vierailun jälkeen heidän selaimensa yksinkertaisesti kieltäytyy lataamasta sivustoasi tavallisen, salaamattoman HTTP:n kautta, vaikka jokin yrittäisi pakottaa siihen.

Ilman HSTS:ää tuo “käytä aina turvallista versiota” -sääntö ei ole olemassa – ja hyökkääjät tietävät tarkalleen, miten hyödyntää aukkoa.

Mitä tämä voi maksaa yrityksellesi

Nämä ovat realistisia, arkipäiväisiä skenaarioita. Emme nimeä oikeita yrityksiä; nämä ovat havainnollistuksia siitä, miten aukkoa käytetään.

1. Kahvilan kassaprosessi. Asiakas avaa kauppasi kahvilan WiFissä ja lähtee kassalle. Hyökkääjä samassa verkossa ajaa ilmaista, tunnettua työkalua, joka pitää asiakkaan tavallisessa HTTP:ssä HTTPS:n sijaan. Asiakas näkee tavallisen näköisen sivustosi – ei varoitusta, ei rikkinäistä lukkoa kohdassa, johon he katsoisivat – ja kirjoittaa korttitietonsa. Hyökkääjä lukee jokaisen näppäinpainalluksen. SSL-sertifikaattisi ei tehnyt mitään, koska yhteyttä ei koskaan annettu tulla turvalliseksi.

2. Matkustava työntekijä. Henkilöstön jäsen kirjautuu hallintapaneeliisi tai verkkosähköpostiisi hotellista tai lentokentältä. Sama alennus kaappaa heidän käyttäjätunnuksensa ja salasanansa. Nyt hyökkääjällä on pääsy yritykseesi – ei siksi, että salasanakäytäntösi oli heikko, vaan koska kirjautumissivu oli saavutettavissa turvattomassa HTTP:ssä.

3. Pysähtyneeseen sopimus. Suurempi asiakas lähettää sinulle vakiotietoturvakyselylomakkeen ennen allekirjoittamista. Yksi rivi kysyy: “Pakottaako verkkosivustosi HTTPS:n HSTS:n kautta?” IT-yhteyshenkilösi joutuu vastaamaan “ei”, ja hankintaprosessi pysähtyy, kun sinä kiirehdät korjaamaan ilmaista, 15 minuutin asetusta, joka nyt näyttää punaiselta lipulta ostajan edessä.

4. Kyberturvallisuusvakuutus tai vaatimustenmukaisuustarkistus. Vakuuttajan skannaus tai tietosuojatarkastus merkitsee puuttuvan otsikon. Henkilötietojen salaus on nimenomainen odotus tietosuojasääntöjen mukaan (GDPR artikla 32), ja “meillä on sertifikaatti mutta emme pakota sitä” on heikko asema.

5. Väärä turvallisuuden tunne. Maksat SSL:stä, lukko näkyy, ja kaikki olettavat sivuston olevan turvallinen. Se pääosin on – kunnes asiakas on jaetussa verkossa, mikä on täsmälleen silloin, kun he ovat haavoittuvaisimpia eivätkä todennäköisimmin huomaa mitään vikaa.

Punainen lanka: kustannus ei ole abstrakti. Se on todellisen asiakkaan kortti tai kirjautuminen, kaapattu pahimpaan mahdolliseen hetkeen, ilman minkäänlaista hälytystä.

Mitä se oikeasti on

Kun selain pyytää verkkosivustoltasi sivua, palvelimesi lähettää takaisin sivun sekä joitakin näkymättömiä “otsikoita” – ylimääräisiä ohjeita, jotka selain lukee, mutta kävijä ei koskaan näe. HSTS on yksi näistä otsikoista:

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

Kolme osaa on tärkeää:

• max-age – kuinka kauan (sekunneissa) selaimen tulisi muistaa pakottaa HTTPS. 31536000 on yksi vuosi. Tämä on sen ydin: liian lyhyt ja se ei juuri auta.
• includeSubDomains – laajenna sääntö jokaiseen aliverkkotunnukseen (kauppa., sovellus., posti. ja niin edelleen), ei vain pääosoitteeseesi.
• preload – lisää verkkotunnuksesi selaimiin sisäänrakennettuun päälistaan, jotta suojaus koskee jopa kävijän ensimmäistä pyyntöä, ennen kuin he ovat koskaan vierailleet sivustollasi.

Miksi “ensimmäinen vierailu” merkitsee

HSTS:ssä on yksi luontainen rajoitus: selain tottelee sääntöä vasta sen jälkeen kun se on nähnyt otsikon vähintään kerran. Joten täysin uuden kävijän ensimmäinen yhteys on silti pieni altistumisen ikkuna. Kaksi asiaa kaventaa sitä: HTTP-to-HTTPS-uudelleenohjaus (joka saa heidät nopeasti turvalliseen versioon) ja preload (joka poistaa ikkunan kokonaan). Siksi täydellinen asetus yhdistää HSTS:n ja asianmukaisen uudelleenohjauksen.

Miltä “hyvä” näyttää – ja kuinka se pisteytyy

Tarkistuksemme lukee live-otsikkosi ja arvioi max-agen:

Joten otsikko, joka on olemassa mutta on asetettu muutamiin minuutteihin, käsitellään epäonnistumisena – se näyttää konfiguroidulta, mutta ei tee työtänsä. Tähtää vuoteen. Tarkistus myös huomioi, onko includeSubDomains ja preload läsnä.

Korjausohje (ilmainen, n. 15 minuuttia)

Anna tämä osio verkkosivustoasi hallinnoivalle – IT-henkilöllesi, webkehittäjällesi tai hosting-tuelle. Korjaus on ilmainen. Se on yksittäinen otsikko tai vaihtoehto hosting-alustassasi. Ei mitään ostettavaa.

Yksi tärkeä järjestysohjaus ensin: HSTS on tahmea – kun se on käytössä, selaimet kieltäytyvät tavallisesta HTTP:stä verkkotunnuksellesi koko max-age-ajan. Joten vahvista HTTPS:n toimivan oikein pääsivustollasi ja jokaisessa aliverkkotunnuksessa ennen kuin otat sen laajasti käyttöön. Turvallinen polku on: testaa lyhyellä arvolla → vahvista, ettei mikään rikkoudu → nosta vuoteen.

Vaihe 1 – Varmista, että HTTPS jo toimii kaikkialla

Vieraile sivustollasi ja avainaliverkkotunnuksissasi https://:n kautta ja vahvista niiden latautuvan siististi kelvollisella sertifikaatilla. Vahvista myös, että pelkkä http://-pyyntö ohjaa https://:ään. (Jos se ei ohjaa, korjaa HTTP-to-HTTPS-uudelleenohjaus ensin – HSTS olettaa sen olevan paikallaan.)

Vaihe 2 – Lisää otsikko (valitse alustasi)

Cloudflare (tai vastaava CDN): Tämä on helpoin. Siirry kohtaan SSL/TLS → Reunasertifikaatit → HTTP Strict Transport Security (HSTS) ja ota se käyttöön. Aseta Max-Age 6 tai 12 kuukauteen, ja ota käyttöön “Apply HSTS policy to subdomains”, kun olet varma, että kaikki aliverkkotunnukset ovat HTTPS:ssä.

Nginx: lisää HTTPS server-lohkosi sisälle:

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

Apache: varmista, että mod_headers on käytössä, sitten lisää HTTPS-virtuaali-isäntäsi:

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

Microsoft IIS: lisää web.config:iin <customHeaders>:n sisälle:

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

Google Workspace / Microsoft 365 -huomio: nämä tehostavat sähköpostiasi, ei verkkosivustohostingiasi – HSTS asetetaan missä tahansa julkinen verkkosivustosi todella sijaitsee (CDN:ssäsi, verkkopalvelimessasi tai sivustonrakentajassasi), ei Workspacen/365:n hallinnassa. Jos sivustosi on rakentajalla kuten Squarespace, Wix tai Shopify, HSTS hoidetaan yleensä puolestasi; tarkista heidän SSL/tietoturva-asetuksistaan, jos tarkistuksemme merkitsee ongelman.

Vaihe 3 – Testaa pienesti, sitten sitoudu

Aloita max-age=300 (5 minuuttia). Vahvista, että sivusto latautuu edelleen täydellisesti kaikkialla. Sitten nosta se max-age=31536000:een (yksi vuosi). Se on täysien pisteiden asetus.

Vaihe 4 (valinnainen, kultainen standardi) – preload

Kun olet varma ja olet ajanut vuoden otsikkoa includeSubDomainsin kanssa jonkin aikaa, voit lähettää verkkotunnuksesi osoitteessa hstspreload.org sisällytettäväksi selaimiin. Tämä sulkee ensimmäisen vierailun ikkunan kokonaan. Käsittele sitä tietoisena sitoutumisena – verkkotunnuksen poistaminen listalta on hidasta.

Yleisimmät virheet

• max-agen asettaminen liian lyhyeksi. Muutaman minuutin tai tunnin arvo näyttää konfiguroidulta, mutta tarjoaa lähes olemattoman suojan – ja tarkistuksemme pitää alle päivän epäonnistumisena. Käytä vuotta.
• includeSubDomainsin ottaminen käyttöön ennen aliverkkotunnusten HTTPS-valmiutta. Jos aliverkkotunnus ei ole täysin HTTPS:ssä, tahmea sääntö voi tehdä siitä kävijöille tavoittamattoman. Saa jokainen aliverkkotunnus HTTPS:ään ensin.
• HSTS:n lisääminen mutta ei HTTP-to-HTTPS-uudelleenohjausta. HSTS olettaa kävijöiden saapuvan turvalliseen versioon; ilman uudelleenohjausta ensimmäinen vierailu on tarpeettomasti alttiina. Korjaa molemmat yhdessä.
• Suoraan preloadiin hyppääminen “ollakseen perusteellinen.” Preload on vaikea kumota. Ansaitse se vähitellen vakaan vuoden otsikon jälkeen – älä kiirehdi sitä.
• Lukon olettaminen tarkoittavan olevasi suojattu. Lukko ja HSTS ovat eri asioita. Sinulla voi olla täydellinen sertifikaatti ja silti epäonnistua tässä tarkistuksessa.

UKK