Mixed content ongelmat syntyvät, kun verkkosivut toimittavat sivujaan HTTPS: n kautta, mutta sallivat joidenkin resurssien toimittamisen selkotekstinä. Aktiivinen verkkohyökkääjä ei voi tehdä mitään salatulle liikenteelle, mutta pelkän tekstin kanssa pelleily voi johtaa hyökkäyksiin, jotka vaihtelevat parhaassa tapauksessa tietojenkalastelusta pahimmassa tapauksessa täydelliseen selaimen kompromissiin. Yksi altistunut skripti riittää: hyökkääjä voi kaapata yhteyden ja pistää siihen mielivaltaisia hyökkäyskuormia.
meillä on tapana puhua paljon SSL/TLS: n muista näkökohdista, mutta sekoitettu sisältö on luultavasti helpoin tapa sotkea web-sivuston salaus täysin.
webin alkuaikoina kaikki sekoitettu sisältö oli sallittua; verkkoselaimet odottivat sivuston ylläpitäjien miettivän sisällön sekoittamisen seurauksia. Se ei tietenkään johtanut suureen turvallisuuteen. Työmaaoperaattorit tekivät kaiken tarvittavan saadakseen työnsä tehdyksi ja vähentääkseen kustannuksia. Vasta viime vuosina selaintoimittajat ovat alkaneet kiinnittää huomiota ja alkaa rajoittaa sekasisältöä.
Sekasisältö nykyaikaisissa selaimissa
nykyään lähes kaikilla suurilla selaimilla on tapana jakaa sekalaista sisältöä kahteen luokkaan: passiiviseen kuville, videoille ja äänelle; ja aktiiviseen vaarallisempien resurssien, kuten skriptien, puolesta. Ne yleensä sallivat passiivisen sekasisällön oletusarvoisesti, mutta hylkäävät aktiivisen sisällön. Tämä on selvästi kompromissi netin rikkomisen ja kohtuullisen tietoturvan välillä.
Internet Explorer on ollut johtava turvallinen sekasisältöjen käsittely. Jo Internet Explorer 5: ssä (tämän julkaisun mukaan) heillä oli oletuksena turvattoman sisällön havaitseminen ja ehkäisy. Chrome aloitti estämisen oletusarvoisesti vuonna 2011 ja Firefox vuonna 2013. Oletus Android-selain ja Safari kuitenkin sallivat edelleen kaiken sekalaisen sisällön ilman rajoituksia (ja lähes olemattomilla varoituksilla).
tässä tuoreen testini tulokset siitä, mikä epävarma sisältö on oletusarvoisesti sallittua:
selain | kuvat | CSS | skriptit | XHR | WebSockets | Kehykset | |
---|---|---|---|---|---|---|---|
Android-selain 4.4.x | Kyllä | Kyllä | Kyllä | Kyllä | Kyllä | Kyllä | |
Kromi 33 | Kyllä | Ei | Ei | Kyllä | Kyllä | Ei | |
Firefox 28 | Kyllä | Ei | Ei | Ei | Ei | Ei | |
Internet Explorer 11 | Kyllä | Ei | Ei | Ei | Ei | Ei | Ei |
Safari 7 | Kyllä | Kyllä | Kyllä | Kyllä | Kyllä | Kyllä | Kyllä |
ne ovat enimmäkseen odotusten mukaisia, mutta Chromessa on yllätys, joka estää aktiivisen sivun sisällön, mutta sallii silti plaintext XMLHttpRequest-ja WebSocket-yhteydet.
on syytä mainita, että taulukko ei kerro kaikkea. Esimerkiksi selaimet eivät yleensä hallitse sitä, mitä niiden lisäosat tekevät. Edelleen, tietyt komponentit (esim., Flash tai Java) ovat täysin ympäristöissä itsessään, ja siellä on vähän selaimet voivat tehdä valvoa turvallisuutta.
miksatun sisällön käsittelyn testaus SSL Labs: ssä
helpottaakseni tämän ongelman selainkäsittelyn arviointia laajensin äskettäin SSL Labs-Asiakastestin koskemaan sekasisällön käsittelyä. Kun vierailet sivulla, käyttäjän selain testataan, ja saat samanlaisia tuloksia kuin nämä:
Sekapitoisuuden esiintyvyys
Anekdotaalisesti sekapitoisuus on hyvin yleistä. Qualysissa tutkimme tätä ongelmaa vuonna 2011 yhdessä useiden muiden sovellustason ongelmien kanssa, jotka johtavat verkkosovellusten salauksen täydelliseen murtumiseen. Analysoimme noin 250 000 turvallisen verkkosivuston kotisivut Alexa top 1 million-listalta ja määritimme, että 22,41% niistä käytti epävarmaa sisältöä. Jos kuvat jätetään pois, määrä putoaa 18,71 prosenttiin.
Alexa top 100 000: sta poimittujen 18 526 sivuston tarkempi tutkimus tehtiin vuonna 2013: a Dangerous Mix: Large-scale analysis of mixed-content websites (Chen et al.). Kutakin sivustoa varten analysoitiin jopa 200 suojattua sivua, yhteensä 481 656 sivua. Niiden tulosten mukaan jopa 43 prosentissa WWW-sivustoista on ristiriitaisia sisältöasioita.
lieventäminen
paras puolustus sekasisältöasioita vastaan on yksinkertaisesti se, ettei koodissasi ole tällaista ongelmaa. Mutta se on helposti sanottu kuin tehty; on monia tapoja, joilla sekoitettu sisältö voi hiipiä ylös. Kun se epäonnistuu, on olemassa kaksi teknologiaa, jotka voivat olla hyödyllisiä:
- HTTP Strict Transport Security (HSTS) on mekanismi, joka valvoo turvallista resurssien hakua, jopa edessä käyttäjän virheitä (yrittää käyttää web-sivuston portti 80) ja täytäntöönpano virheitä (Kehittäjät sijoittaa epävarma linkki suojatun sivun). HSTS on yksi parhaista asioista, mitä TLS: lle on tapahtunut viime aikoina, mutta se toimii vain hallitsemillasi hostnameseilla.
- Content Security Policyn (CSP) avulla voidaan estää turvattomien resurssien hakeminen kolmannen osapuolen sivustoilta. Siinä on myös monia muita hyödyllisiä ominaisuuksia muiden sovellusten tietoturvaongelmien, esimerkiksi XSS: n, ratkaisemiseksi.