Path Traversal Attack perustuu juuri tähän. Kun selain lähettää palvelimelle pyynnön, että ”lähetä minulle tiedosto, jonka on muotoa /index.html” se pyyntö on plain text -muodossa. Näin ollen ihminen pystyy ymmärtämään sitä, imitoimaan sitä ja leikkimään sillä. Hakkeri taas pystyy saivartelemaan, eli takertumaan haavoittuviin yksityiskohtiin, joita devaaja ei ole tarkoittanut kokonaisuuden kannalta merkityksellisiksi.
Index.html sijaitsee tietyssä kansiossa osana palvelimella olevaa kansiorakennetta. Muissa kansioissa on toisenlaisia tiedostoja, esimerkiksi salasanatiedostoja, joita ei satunnaiselle kyselijälle haluta näyttää. Kun palvelinpyynnön kanssa kikkailee oikealla tavalla, saa usein aikaan virheilmoituksen, josta saa riittävästi vihiä, mikä käyttöjärjestelmä on kyseessä. Usein käyttöjärjestelmissä asiat ovat samoissa paikoissa ja siitähän sitä piilotettua tietoa on sitten mahdollista lähteä kalastelemaan.
Käpälöintiin voidaan käyttää esimerkiksi universaalia ja hyväksyttyä viittausmuotoa ../. Estääkseen tällaisen kansiopolkuhyökkäyksen, devaajat yleensä pyrkivät estämään koodissaan ../-muodon käyttämisen. Ongelma on vain siinä, että on olemassa vähintäänkin 877 tapaa kiertää tuo kielto.
TSQL-injektio OR 1=1
Syvennetään tätä maailmantuskaa vielä hieman. Jos verkkopalvelu sisältää tietokantoja, tehdään noihin tietokantoihin hakuja myös luonnollisilla käskyillä. URL näyttää silloin kutakuinkin tältä: domain.fi/sivu.html?esimerkki=hakuehto. Arvannet, että näitäkin hakuja voi manipuloida, koska ihminen pystyy saivartelemaan niin mielikuvituksellisesti, että kaikkeen varautuminen on mahdotonta.
Esimerkiksi tietämällä pääkäyttäjän tunnuksen, joka on edelleen usein valitettavasti admin, voidaan huonosti rakennetun verkkopalvelun salasanapyyntö ohittaa. Se toimii näin.
Verkkopalvelu tekee tietokantakyselyn muotoa: ”SELECT id FROM account WHERE username=’$username’ AND password=’$password’;”. Nämä dollarimerkillä varustetut muuttujat saavat arvonsa sen perusteella mitä käyttäjä kirjautumissivun kenttiin kirjoittaa.
Nyt jos laitetaan $username = admin ja $password = ’ OR 1=1, tietokantakysely muuttuukin muotoon: “SELECT id FROM account WHERE username=’admin’ AND password = ’’ OR 1=1;”.
Tietokantataulu on vähän niin kuin excel-tiedosto ja tietokantakysely toimii niin, että jokaisella account-taulun rivillä katsotaan onko username-arvo ’admin’ JA onko password =’’ (eli tyhjä ja tämä ei ole totta) TAI onko 1=1. No hemmetti, yksihän on yksi! Näin ehdot täyttyvät ja kirjaimellisesti asioita tulkitseva kone sallii pääsyn järjestelmään.
No nyt jos devaaja pyrkii estämään hyökkäyksen kieltämällä muodon OR 1=1, nauraa hakkeri partaansa ja kirjoittaa OR 2=2 tai OR 2<3. Jos taas tällaiset muodot (eli tautologiat) kielletään, voi hakkeri ujuttaa komentoon RAND()>0.01, joka on 99,99 % kerroista tosi (RAND palauttaa sattumanvaraisen lukuarvon väliltä 0-1), mutta ei matemaattisesti aina totta, kuten tautologia edellyttää.
Puhumattakaan sitten niistä lukuisista eri tavoista, joilla tuon pisteen voi korvata, jos päästään estoyrityksissä näin pitkälle. Ja niin edelleen, ja niin edelleen.
Tarvitaan ajattelutavan muutos
Vuosien varrella olen oppinut, että devaajilla on tietynlainen periaatteessa viaton ajattelumalli, joka palvelee valitettavasti hakkereiden tarkoituksia. Sen sijaan, että pyrittäisiin sallimaan vain tietyt komennot ja kieltämään muut, pyritään sallimaan kaikki ja kieltämään poikkeukset.
Lienee sanomattakin selvää, että on varsin työlästä lähteä tukkimaan kaikki porsaanreiät, mitä joku hakkeri vain keksii kokeilla.
On tietysti poikkeuksia, joissa komentoja ei voi rajata poissulkevasti. Mutta valtaosassa tapauksista olisi helpompi sallia oikea ja kieltää muut. On ylipäätään syytä miettiä, miten oikeaoppisessa käytössä kukaan koskaan lähettäisi palvelimille tahallaan näinkin kauniin pyynnön: /%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af
Koodari pyrkii estämään hyökkäykset, lisäämällä asioita blacklistille. Hakkeri muuttaa kuitenkin saivartelemalla mustan valkoiseksi. Siksi kieltämistä parempi strategia olisikin keskittyä siihen, mikä on sallittua.
Tutustu tietoturvatestauksen palveluihin