Difference: KirjaWAHH (r43 vs. r42)

Tietoturva-arjen kysymyksiä ja vastauksia kirjan perusteella

Vuosina 2012-2013 käsiteltiin kirjan luvut 4 - 18 siten, että kustakin tuli esille muutaman lauseen yleisluonnehdinta ja yhden hyökkäyksen selitys. Myöhemmillä toteutuskerroilla tehdään toinen kierros samoista luvuista, jossa esitellään jokin toinen hyökkäys.

Ohje: Valitse alla olevasta luettelosta vapaa luku eli sellainen, jossa ei ole vielä kahta vastausta (keväällä 2015 merkitty *:llä; poista se). Laadi aiemman vastauksen jälkeen oma otsikkosi suomeksi (raw edit: ---+++++) ja nimikoi se eli kirjoita otsikon edelle nimesi ja nimen jälkeen toteutuskerran tunnus muodossa (201*-x), missä x=s tai k. Laadi noin 150 sanan mittainen vastaus määräaikaasi mennessä tehtävän alle, ja noudata Moodlen keskustelualustalla olevia lisäohjeita.

Dafydd Stuttard, Marcus Pinto: Web application hacker's handbook (2nd ed)

Tämä on uudistettu versio jo aiemmin hyvän maineen saaneesta käsikirjasta. Se on kirjoitettu ikäänkuin murtautujaa varten. Tietysti kirja toimii myös hyökkääjän apuna, mutta suurempi hyöty kirjasta on www-sovelluksen rakentajalle, ylläpitäjälle, puolustajalle ja ulkoiselle arvioijalle. Kirjaan liittyvä sivusto on mdsec.net/wahh.

Kolme ensimmäistä lukua tarjoavat yleistietoa www-sovellusten turvattomuudesta, perusturvamekanismeista ja www:n toteutustekniikoista. Niiden pohjalta luvut 4 - 18 jäsentävät erityyppiset hyökkäykset, joskin 4 käsittelee vasta tiedustelua. Luvut 19-21 esittävät yhteenvetoa kolmesta näkökulmasta: ensin käsitellään lähdekoodin tarkastelua ja hyökkäystyökaluja ja lopuksi esitetään kattava hyökkääjän työlista.

4. Mapping the Application

Sami Niemelä (2013-s): Investigating the functionality

Kaikkien hyökkäysten perustana on etukäteen suoritettu tiedustelu. Kohteeseen ei ole järkevää hyökätä ilman, että tietää kohteesta ennakkoon jotain tärkeitä perustietoja. Tiedustelu kannattaa tehdä käsin, eikä luottaa jonkin automaattisen ohjelman analyysiin. Tiedustelu aloitetaan arvioimalla sivuston sisältöä ja toiminnallisuutta. Suurin osa on helposti saatavilla, mutta osa voi olla piilossa. Piilotettuja sisältöjä voidaan kartoittaa käyttämällä raakaa voimaa, eli tekemällä suuria määriä erilaisia käskyjä. Burb Intruder tekee serverille erilaisia käskyjä ja analysoi niihin saatuja vastauksia. Näiden vastausten perusteella se selvittää serverin hakemistot. Kiinnostavia hakemistoja voidaan tutkia samalla menetelmällä, jolloin saadaan selville alihakemistot. Näistä saadaan selville niinkin yksinkertaisia asioita, kuten sivuston kehittäjän tapa nimetä kansioita ja tiedostoja (esim. AddUser?.asp vs AddUsr?.asp vs AddU?.asp), mikä taasen voi olla hyvinkin hyödyllinen tieto jatkossa.

Tuukka Tapper (2015-k): Identifying Entry Points for User Input

On mahdollista yleensä havaita sovelluksen käyttämät tavat käyttäjäsyötteiden lukemiseen tarkkailemalla sen palauttamia HTTP-otsakkeita. Tällöin kannattaa kiinnittää huomiota käytettäviin evästeisiin, URL:n parametreihin, HTTP-otsakkeisiin ja POST-pyynnön runkoon. Monesti on helppo havaita REST-tyyppiset URL.t niiden rakenteen perusteella, vaikkei siihen voikaan aina luottaa. Myös erilaisten parametrien välittäminen sovellukselle saattaa palauttaa hyödyllistä tietoa, vaikkakin silloin täytyy huomioida ettei parametrien muoto ole välttämättä vakiintunut. Itse muokatut parametrien sisällöt saattavat tarjota väylän esim. SQL-injektioon. Yhtälailla on mahdollista hyödyntää sitä, että monet sovellukset pyrkivät muokkaamaan tarjoamaansa sisältöä HTTP-otsakkeiden perusteella vaikkapa käytetyn hakukoneen tarjoamien hakuparametrien tahi päätelaitteen tyypin (tabletti, mobiililaite,läppäri tms) perusteella. Nämä on usein toteutettu ohjaamalla pyyntö eri hakemistopolkuun, joka voi olla heikommin testettu kuin varsinainen sivu. Kustomoitujen vakio-otsaketietojen lisäksi voidaan lähettää myös ylimääräisiä otsakkeita, joihin ei ole välttämättä varauduttu. Esimerkikis sovelluksen ollessa proxyn tai kuormantasaimen takana, voidaan saada aikaan SQL-injektio mikäli kehittäjä ei ole varautunut siihen, että vierailija tarjoaisi omia syötteitä otsakkeissa.

Pelkästään brute force -tyyppisellä ei kaikkea sivuston toiminnallisuutta saada välttämättä selville. Apuna voidaan käyttää ns. ohjattua selausta, jossa käyttäjä klikkailee itse sivuston läpi selvittääkseen kaiken toiminnallisuuden, ja samaan aikaan softa tarkkailee sivustoon liittyvää liikennettä. Automaattiinen systeemi voi myös pyrkia täyttämään lomakkeita päästäkseen piilotettuihin osiin sivustoja.

5. Bypassing Client-Side Controls

Nina Kuisma (2012-s): ASP.Net ViewState

Jos web-palvelu luottaa täysin asiakaspään lähettämiin tietoihin, se on hyvin haavoittuvainen, koska asiakkaan lähettämiin tietoihin ei voi luottaa vaikka niiden lähettämistä yrittäisikin rajoittaa esim. HTML-formien disabled ja hidden-määreillä, myös HTTP-otsikkotiedot (Cookie, Referral) ovat epäluotettavia. ASP.Netin ViewStatessa sen hetkisen sivun tila lähetetään selaimelle Base64-enkoodattuna ja piilotettuna html-formiin. Tässä enkoodatussa tiedossa voi esimerkiksi olla tuotelistan tiedot, sisältäen esimerikiksi tuotteen hinnan, joka päätyy näin käyttäjän muokattavaksi jos käyttäjällä on oikeat työkalut (kuten kirjan kirjoittajan tekemä Burp Proxy). ASP.Netissä on ns. "MAC-suojaus" joka perustuu vain palvelimen hallussa olevan avaimen avulla luotuun tiivisteen ja jolla voi näin estää ViewStaten muokkaamisen käyttäjäpäässä, mutta joissain ASP.Net-sovelmissa sitä ei käytetä. ViewStaten tutkimista MAC-suojaus ei estä, vaan sen sisältö on aina dekoodattavissa ymmärrettävämpään muotoon.

Vili Laitinen (2014-k): Käyttäjän puoleisen datan turvallinen käsittely

On yleistä että sovellus kuljettaa asiakkaalle dataa sellaisessa muodossa, jota loppukäyttäjä ei pysty suoraan näkemään tai muokkaamaan, oletetaan että nämä myös pysyvät muuttumattomana. Koska kuitenkin kaikki serverille lähetettävä data on käyttäjän hallittavissa, käyttäjien lähettämään dataan ei voida luottaa ja nämä sovellukset ovat alttiita hyökkäyksille. Erityisen kriittistä dataa hyökkäyksille ovat mm. tuotteiden hinnat ja alennusten määrät. Sovellusten tulisikin välttää kriittisen datan lähettämisen asiakkaan kautta esimerkiksi kriittistä dataa säilyttämällä palvelimilla ja niitä hakemalla esimerkiksi tuotekoodien ja kappalemäärien avulla.

Jos kuitenkin halutaan siirtää käyttäjälle kriittistä dataa, tulisi se salata ja/tai allekirjoittaa, mutta tällöinkään data ei ole täysin turvassa muuntelulta. Erityisesti sovelluksiin, jotka toimivat ASP.NET alustan päällä, ei tule sisällyttää ViewState-osioon. Koska käyttäjien kaikkea lähettämää dataa tulee käsitellä uhkana, ainoa tapa turvallisesti vahvistaa käyttäjän tuottaman datan oikeellisuus on sovelluksen palvelinpuolella. Myös erilaisten mekanismien, kuten pituusrajoitusten tai JavaScriptiin? perustuvien varmistamisten tulisi tapahtua palvelimien turvamekanismeissa.

6. Attacking Authentication

Sampo Tolvanen (2012-s): Autentikaation uhkat

Autentikaatiomekanismejä vastaan on lukuisia erilaisia hyökkäystapoja. Web-palvelu voi esimerkiksi antaa käyttäjien valita huonoja salasanoja tai salasanaa saatetaan käsitellä tavalla, joka tekee siitä vähemmän turvallisen. Kirjautumislomakkeisiin sekä mahdollisesti myös salasanan vaihtolomakkeeseen liittyy bruteforce-hyökkäys, jossa kirjautumisyrityksiä päästään kokeilemaan suuria määriä. Käyttäjän jatkuvat kirjautumisyritykset estävä ulossulkeminen voi olla puutteellinen tai sitä ei välttämättä ole ollenkaan. Käyttäjien käyttäjätunnuksia voidaan selvittää mahdollisesti rekisteröintilomakkeen, salasanan vaihtamis- tai palautuslomakkeen avulla tai lomakkeiden paljastavia virheilmoituksia hyväksikäyttäen. Myös kirjautumispyynnön vastausaika voi mahdollisesti paljastaa oliko käyttäjätunnus olemassa.

On myös hyökkäyksiä jotka hyödyntävät lisäksi muita hyökkäysmenetelmiä. Esimerkiksi unohtuneen salasanan palautuksessa käytettävät haasteet saattavat olla helpompia arvata kuin käyttäjän salasana. Autentikaation muista minut -toiminto voi olla väärennettävissä käyttäjän puolella niin, että hyökkääjä pääsee käyttämään haluamaansa käyttäjätunnusta. Autentikaatio voi olla myös monitasoinen mutta eri tasoja pystyy mahdollisesti ohittamaan. Käyttäjätietojen tallennustapa voi olla epäturvallinen, kuten selkokieliset salasanat tai bruteforce-hyökkäysille alttiit tiivisteet. HTTP-protokolla ei ole kirjautumissivulla turvallinen, muttei myöskään HTTPS, jos tietojen käsittelytapa on epäturvallinen.

Pietari Heino (2014-s): Yleisimmät ongelmat autentikoinnissa

Autentikointi eli järjestelmään sisälle yrittävän tahon tunnistetietojen oikeellisuuden varmistaminen on yksi tärkeimmistä osista kaikkia järjestelmiä. Autentikointi voidaan toteuttaa monella tavalla, helpoimmillaan pelkällä tunnuksella (ja salasanalla), ja monimutkaisimmillaan usean vaiheen toisistaan riippuvilla ja eri tietoja vaativilla menetelmillä. Sekä yksinkertaisiin että monimutkaisiin menetelmiin liittyy laaja skaala potentiaalisia reikiä. Turvavaatimukset eivät ole riittäviä, dataa liikutellaan hyökkääjän näköpiirissä, vastaanotetun datan alkuperää ei varmenneta tai autentikointiyritysten onnistumisesta ja/tai epäonnistumisesta annetaan liikaa tietoa.

Monivaiheinen tunnistautumisjärjestelmä vaatii käyttäjältä ensin käyttäjätunnuksen ja salasanan ja sen jälkeen yhdellä tai kahdella kierroksella lisätietoja. Tällainen järjestelmä voidaan helposti toteuttaa väärin. Järjestelmän on kirjattava itselleen ylös, onko aiemmat kierrokset suoritettu onnistuneesti (ei esim. käyttäjän selaimen keksiin). Jos järjestelmä käyttää myöhemmällä kierroksella aiemman kierroksen dataa, sen on pidettävä kirjaa siitä, läpäisikö tunnistautuja aiemmat kierrokset ja jos, niin mitä dataa käyttäen (pitää estää myöhemmällä kierroksella väärän, toisen tunnuksen datan syöttäminen). Jos järjestelmä kysyy jotakin satunnaista ennakkoon tiedetystä (salaisesta) asiasta, on pidettävä kirjaa kysymyksistä ja vastauksista, jotta hyökkääjä ei voi iteroida itselleen mieleistä kysymystä. Järjestelmässä on huomioitava erot sen suhteen, kysytäänkö kaikkien tunnistautumisvaiheiden tiedot kerralla vai peräjälkeen ja mitä tapahtuu, jos epäonnistuu tasolla n (voivatko tasot riippua toisistaan, kerrotaanko hyökkääjälle epäonnistumiskohta).

7. Attacking Session Management

Esa Väntsi (2013-s): Merkitykselliset istuntotokenit

Koska HTTP on tilaton protokolla, monet verkkopalvelut tunnistavat käyttäjän session tokenin perusteella. Token luodaan esimerkiksi kirjautumisvaiheessa, jonka jälkeen tunnistetun käyttäjän tiedot kulkevat sivulta toiselle, kun selain lähettää palvelulle tokenin aina sivunpyynnön yhteydessä. Hyökkääjän on mahdollista esiintyä verkkopalvelulle toisena käyttäjänä, mikäli tämä onnistuu saamaan käyttäjän tokenin. Hyökkäys on mahdollinen esimerkiksi silloin, kun token on jollain tapaa merkityksellinen (esimerkiksi käyttäjätunnus, käyttäjän nimi, aika, päiväys jne). Tällöin hyökkääjä voi järjestelmällisesti koettaa selvittää, minkä kriteerin perusteella token luodaan. Jos esimerkiksi hyökkääjä voi luoda järjestelmään vapaasti käyttäjätunnuksia ja voi kirjautua näillä monta kertaa, on hänellä hyvät mahdollisuudet keksiä luontitapa teettämällä palvelimella useita tokeneita eri käyttäjätunnuksilla eri aikoina.

Tuomas Vaherkoski (2014-s): Heikkoudet istuntotokenien käsittelyssä

Vaikka sivusto onnistuisi luomaan istuntotokenit siten, ettei niiden luontiperusteita voi mitenkään päätellä, ei tästä ole apua, jos tokenin pystyy kaappaamaan verkkoliikenteen joukosta. Tämä tietysti vaatii sen, että hyökkääjä pystyy seuraamaan palvelun käyttäjän verkkoliikennettä. Palvelu on erityisen haavoittuva, jos se käyttää kommunikointiin HTTP-protokollaa, salatun HTTPS-protokollan sijaan. Salaamattomassa versiossa hyökkääjä näkee kaiken liikenteen palvelun ja käyttäjän välillä, mukaan lukien istuntotokenit. Mikäli palvelu käyttää liikentennöintiin sekä HTTP että HTTPS-protokollia, on olemassa monia tilanteita, joissa istuntotokeni voi päätyä hyökkääjän tietoon.

Esimerkiksi jos palvelu käyttää HTTPS yhteyttä pelkästään kirjautumisvaiheessa, voi hyökkääjä kaapata istunnon kirjautumisen jälkeen. Jos palvelu antaa käyttäjälle istuntotokenin ennen hänen kirjautumistaan (HTTP), ja kirjautumisen jälkeen kohottaa sen (luomatta uutta tokenia) kirjautuneeksi (HTTPS), voi hyökkääjä odottaa että käyttäjä kirjautuu sisään ja alkaa sitten käyttää HTTP yhteyden aikana kaapattua tokenia. Vaikka palvelu loisi uuden tokenin kirjautumisen jälkeen, voi käyttäjän vierailu jollain salaamattomalla sivulla johtaa tokenin vuotamiseen hyökkääjälle. Jotkut palvelut käyttävät sivun staattisen sisällön (kuvat, tyylitiedostot, jne.) lataamiseen salaamatonta yhteyttä. Tässä tapauksessa salatulla yhteydellä vastaanotettu tokeni voi päätyä hyökkääjän käsiin kun hän lataa sivun muuta sisältöä.

8. Attacking Access Controls

Otto Huhta (2013-k): Burp Suite

Sovelluksen keskeisimpiä tietoturvaominaisuuksia on pääsynhallinta, joka rakentuu pääosin tunnistautumisen ja istuntojen hallinnan varaan. Yksinkertainen esimerkki tästä on käyttöjärjestelmä, joka ensin vaatii käyttäjää tunnistautumaan käyttäjätunnuksella ja salasanalla, ja tämän jälkeen sallii esimerkiksi luvun tai kirjoituksen sellaisiin tiedostoihin, joihin käyttäjällä on pääsynhallintatietokannassa oikeus.

Helppo tapa hyökätä jonkin sovelluksen pääsynhallintaa vastaan on eri käyttäjätunnusten avulla: ensin paikallistaa jokin tiedosto tai toiminnallisuus korkeamman tason tunnuksella, ja tämän jälkeen pyrkiä käsiksi siihen alemman tason tunnuksella ­- esimerkiksi suoralla URLilla. Burp Suite on eräs työkalu, jolla tällaista kokeilua voidaan automatisoida. Sitä voidaan hyödyntää esimerkiksi niin, että sen välityksellä kartoitetaan tietyn sovelluksen sisältö kahdella eri käyttäjällä, ja myöhemmin vertaillaan, mitä eroja kahden kartoituksen välillä on. Tällainen vertailu voisi esimerkiksi näyttää, mitkä valikot ovat näkyvissä ylläpitäjäkäyttäjälle, mutta eivät tavalliselle käyttäjälle. Työkalu ei kuitenkaan automatisoi haavoittuvuuksien etsintää täysin, sillä sen avulla saatavien kartoitusten eroista tai yhtäläisyyksistä ei välttämättä voida yksiselitteisesti päätellä haavoittuvuuksien olemassaoloa. Se on kuitenkin hyvä apu hyökkäyksissä pääsynhallintaa vastaan.

Mika Karsikas (2015-s): Pääsynvalvonnan turvaaminen

Pääsynvalvonnan heikkouksien löytäminen ja niiden hyödyntäminen on tärkeässä osassa asioiden näkemisessä hyökkääjän näkökulmasta. Kuitenkin tietoturvaosaajan kannalta on erityisen tärkeää osata hyödyntää tätä ymmärrystä heikkouksien minimoimiseksi ja pääsynvalvonnan parantamiseksi. Vaikka pääsynvalvonnan tärkeyden ymmärtäminen on helppoa, sen toteuttaminen tulee suorittaa tarkasti ja perinpohjaisesti parhaan mahdollisen turvallisuustason saavuttamiseksi.

Kun tarkastellaan pääsynvalvontaa liittyen verkkopalveluihin, on olemassa useita keinoja, joiden avulla sitä voidaan parantaa. Ensinnäkin tulee välttää selviä sudenkuoppia, kuten esimerkiksi suojatun sivun turvaaminen ainoastaan näennäisesti salaisena pitämänsä URL-osoitteen avulla tai pääsyoikeuksien varmentaminen joidenkin käyttäjän mahdollisesti syöttämien parametrien avulla (esim. admin=true). Toiseksi pitää pyrkiä noudattamaan parhaita todettuja toimintamalleja. Näistä esimerkkeinä ovat muun muassa jokaisen sovelluksen toiminnallisuuden pääsynvalvonnan vaatimusten arviointi ja dokumentointi erikseen, lokitietojen kerääminen kaikesta suojatun tiedon käsittelystä sekä pääsynvalvonnan toteuttaminen käyttämällä jotain keskitettyä sovellusta, jonka tehtävänä on valvoa käyttäjien pääsyoikeuksia.

Pääsynvalvontaan liittyy lisäksi puolustautuminen syvyyssuunnassa eli useiden suojauskerrosten luominen. Tähän liittyy olennaisesti useiden käyttäjäoikeustasojen hyödyntäminen ja vähimpien oikeuksien periaatteen noudattaminen. Sovelluksesta riippuen voidaan hyödyntää esimerkiksi pääsymatriisia tai rooli-/ryhmäperustaisia pääsynvalvontoja.

9. Attacking Data Stores

Riku Kaura-aho (2013-s)

Tietomäärien kasvaessa taustapalvelut tiedon säilömiseen ovat yleistyneet. Näille taustapalveluille on niille ominainen rajapinta, jonka kautta tietoja haetaan ja talletetaan. Rajapinnan komennot ovat useimmiten helposti luettavia, jolloin hyökkäyksen tekeminen helpottuu, kun kyselyt ja vastaukset ovat ymmärrettävissä helposti lukemalla. Myös suurin osa web-käytössä olevista kielistä on ajon aikana tulkattavia, jolloin väliin on helpompi injektoida komentoja annettujen syötteiden kautta.

Yleisesti hyökkäykset ovat mahdollisia koska järjestelmä ei tarkasta käyttäjän antamaa syötettä riittävän tarkasti. Tämä mahdollistaa sen, että järjestelmälle voi antaa komentoja, joiden ei pitäisi olla sallittuja normaalille käyttäjälle. Näistä tiedoista saadaan esimerkiksi käyttäjätunnuksia tai jopa sopivalla injektiolla koko järjestelmä haltuun. Kirjassa esitellään kyseisiä syntakseja tunnetuimpien palveluiden injektointiin, mutta usein syötteitä joutuu muokkaamaan järjestelmän antamien vastausten perusteella ja näin edetä hyökkäyksen kanssa.

Henry Hynynen (2014-s)

Lähes aina erilaisten web-sovellusten (ja muidenkin) takana on jonkinlainen tietokant, joka helpottaa tiedon säilömistä, hakemista ja hallinnointia. Tämä kappale keskittyi kuvaamaan erilaisia injektiohyökkäyksiä. Näistä valitut tosimaailman esimerkkikannat olivat SQL, MongoDB?, XPath ja LDAP.

Injektiohyökkäyksestä yleensä: vihamielisen toiminnan tavoitteena on saada käyttäjän syöte, kuten lomakkeen tekstikenttä, osaksi suoritettavaa koodia. Näin on toki tarkoitus tehdä myös ihan normaalissa toiminnassa, mutta tällöin syötettävät tiedot ovat mallia nimi, osoite, käyttäjätunnus etc. Vihamieliset komennot pyrkivät onkimaan tietoja, joihin ei ole oikeutta tai aiheuttamaan jonkinlaista harmia tietokantaan. Esimerkki tällaisesta syötteestä voi olla vaikkapa legendaarinen, nimikenttään syötetty "Bobby;) Drop table people;". Tällöin generoitu SQL haku voisi olla muotoa SELECT 'name=("bobby");drop table people;', mikä yrittää poistaa taulu 'people'.

Tällaiset hyökkäykset yleensä vaativat, että käytössä on jokin tulkattava kieli. Tällöin suoritettavan koodin sekaan on tosiaan mahdollista syöttää ajettavaa ohjelmakoodia, toisin kuin käännetyissä ohjelmissa. Näissä ohjelmakoodi on jo valmiiksi ennen suoritusta käännetty konekäskyiksi, jolloin syötetyn vihamielisen koodin tulisi olla valmiiksi konekielinen. Tämä poikkeaa vahvasti tällaisesta "perinteisestä" injektiohyökkäyksestä.

10. Attacking Back-End Components

Ville-Valtteri Jäävalli (2013-s): Hyökkäys käyttöjärjestelmään

Yhä monimutkaisemmiksi käyvät web applikaatiot tarjoavat rajapinnan backendiin, jossa pyörii paljon bisnes kriittisiä resursseja. Onnistunut hyökkäys saattaa aiheuttaa hakkerille pääsyn arkaluontoiseen tietoon.

Nykyisten web server alustojen API:t mahdollistavat laajat mahdollisuudet vuorovaikuttaa palvelimen käyttöjärjestelmän kanssa. Mukaanlukien pääsy tiedostojärjestelmään ja käyttöjärjestelmäkomentojen suoritus. Hakkerin on siis mahdollista kaivaa palvelimelta erittäin kriittistä tietoa ulos, mikäli sopivia tietoturva-aukkoja löytyy.

Tyypillinen tapa kaivaa tietoa on injektoida palvelimelle komentoja web sovelluksen kautta sellaisella syötteellä mihin ohjemassa ei olla varauduttu. Esimerkiksi dynaamisesti suoritettavan koodin sekaan voi hakkeri injektoida omaa koodiaan suoritukseen, millä on yleensä ei toivottuja seurauksia.

Paras tapa suojautua OS käskyjen injektiolta, on minimoida suorat kutsut käyttöjärjestelmälle sovelluksesta. Jos kuitenkin on välttämätöntä välittää käyttäjän syötettä käyttöjärjestelmälle, on suositeltavaa rajata annettua syötettä mahdollisimman tarkkaan. Muutenkin käskyt kannattaa välittää järjestelmälle erillisen komento APIn kautta sen sijaan, että välittäisi ne sellaisenaan järjestelmän komentotulkille.

Heikki Hemminki (2015-k): Sähköpostipalveluiden hyväksikäyttö

Monella sivustolla käyttäjällä on mahdollisuus lähettää sähköpostia sivuston ylläpitäjälle, esimerkiksi palautelomakkeen tai vikailmoituslomakkeen avulla. Lomakkeissa siis usein hyödynnetään SMTP-protokollaa. Jos jokin lomake ei suodata käyttäjän syötettä, palvelu voi olla haavoittuva.

Jos sivustolla käytetään PHP-ohjelmointikieltä, eri lomakkeiden sisältö voidaan syöttää mail()-funktioon, joka muodostaa varsinaisen sähköpostiviestin ja suorittaa tarvittavat SMTP-komennot. Mail()-funktiossa on ylimääräinen parametri additional_headers, johon voidaan syöttää From, Cc ja Bcc –kentät. Nämä kentät erotetaan rivinvaihtomerkillä. Jos palautelomakkeessa on olemassa From-kenttä vastausviestin varalta ja kentän sisältöä ei suodateta, hyökkääjä voi syöttää useamman vastaanottajan sähköpostiosoitteen erottamalla osoitteet rivinvaihtomerkillä. Tällä tavalla hyökkääjä voi lähettää suuren määrän roskapostia palautelomakkeen kautta.

Toisissa tapauksissa jokin palvelu voi suorittaa tarvittavat SMTP-komennot itse. Tällöin palveluun voi olla mahdollista syöttää SMTP-komentoja suoraan lomakkeen kautta. Tässä tilanteessa hyökkääjä voi syöttää SMTP-komentoja lähes mihin tahansa lomakkeen kenttään, jolloin edellisen esimerkin mukaan hyökkääjä voi lähettää suuren määrän roskapostia.

* 11. Attacking Application Logic

Atte Pellikka (2013-s): Applikaatiologiikan hyväksikäyttäminen hyökkäyksissä.

Luku keskittyy webbiapplikaatioiden erilaisten "tilojen" tutkimiseen sekä applikaation tarjoamien palveluiden käyttämistä applikaatiota itseään vastaan. Hyökkäystapa on huomattavasti työläämpi kuin monet muut suoremmat keinot.

Tyypillisessä hyökkäyksessä hyökkääjä käyttää aikaa tutkiessaan millaisiin tiloihin webbiapplikaation saa erilaisilla syötteillä (niin laillisilla kuin laittomilla). Riittävästi tiloja ja siirtymiä kartoitettuaan hyökkääjä tutkii onko tietyssä tilassa mahdollista syöttää applikaatiolle dataa jota normaalisti voi syöttää vain jossakin toisessa tilassa. Sopivat syötteet muodostamalla on mahdollista löytää applikaatioista erittäinkin vakavia haavoittuvuuksia jotka voivat johtua hyvinkin pienestä logiikkavirheestä sovelluksen koodissa.

Esimerkkinä mainittakoon monessa verkkokaupassa nähtävissä oleva ostoprosessi. Käyttäjä lisää tavaroita ostokoriin -> Käyttäjä siirtyy syöttämään yhteystietonsa -> Käyttäjä syöttää maksutietonsa -> Käyttäjä maksaa -> Tilaus vahvistetaan tilausvahvistussivulla. Entäpä jos hyökkääjä onnistuukin yhteystietojen syöttämisen jälkeen siirtymään suoraan vahvistussivulle? Applikaation tilakaaviossa ollaan vieläkin laillisessa tilassa vaikka maksusuoritus on jäänyt kokonaan tekemättä.

Rikhard Nieminen (2015-k): Sovelluslogiikka hyökkäyksissä

Sovelluslogiikan hyödyntäminen hyökkäyksissä perustuu sovelluspintaan, joka on aina saatavilla, mutta jota hyökkääjät ja suojaajat monesti ylenkatsovat käyttäen yleisempiä hyökkäyskeinoja.

Esimerkki1 sovelluslogiikka verkkokaupassa: Verkkokauppa toimii seuraavasti: 1.Etsi tuote valikoimasta ja aseta se ostoskoriin 2.Palaa ostoskoriin ja hyväksy tilaus 3.Syötä maksutiedot 4.Syötä toimitusosoite. Kyseessä olevan verkkokaupan kehittäjät ovat olettaneet, että käyttäjä etenee vaihein 1,2,3,4, sillä sivuston linkit toimivat vastaavalla tavalla. Käyttäjä pystyy kuitenkin ohittamaan maksuvaiheen ja siirtymään suoraan toimitusvaiheeseen. Näin ollen sovelluslogiikassa on virhe, joka mahdollistaa maksun ohittamisen.

Esimerkki2 Verkkokaupassa hyökkääjä lataa ostoskorinsa täyteen tuotteita saaden paljousalennusta. Ennenmaksua checkin vaiheessa hyökkääjä tai käyttäjä poistaa muut tuotteet saavuttaen saman alennusprosentin yhdelle tuotteelle.

Tällaisia hyökkäyksiä tai sovelluslogiikka virheitä (ilman hyökkäystä) oli johonkin aikaan jonkin verran uutisissakin. Kyseessä on siis perustavanlaatuinen ohjelmointikämmi, mikäli hyväntahtoinen käyttäjä vahingossa toteuttaa hyökkäyksen. Esimerkit ovat yksinkertaistettuja ja monesti hyökkäys ei ole näin suoraviivaista. Realistisemmassa skenaariossa hyökkäys perustuu ns.forced browsing tekniikkaan, jossa hyökkääjä syöttää lomakkeita sovelluslogiikan vastaisessa järjestyksessä tai tekee muita sovelluslogiikan vastaisuuksia etsien ohjelmoinnin puutteita.

Sovelluslogiikassa on huomioitava kaikki mahdolliset käyttäjän syötteet ja erikoisemmat toimintatavat. Mitä, jos hyökkääjä tai käyttäjä tekeekin vastoin sovelluksen peruslogiikkaa? Tekee jotain siis odottamattomassa kohdassa, jolloin sovelluksenlogiikka olettaa väärin. Ts. Ohjelmoinnissa on kehitettävää.

12. Attacking Users: Cross-Site Scripting

Lauri Niskanen (2012-s): XSS

Cross-Site Scripting eli XSS on hyökkäys, joka hyödyntää web-palvelun haavoittuvuutta ja hyökkää sen avulla suoraan käyttäjiin eikä niinkään palveluun itseensä. XSS-haavoittuvuuden avulla on mahdollista ujuttaa kohteena oleville käyttäjille suoritettavaksi client-side-koodia kohteena olevan palvelun ympäristössä. Tämän avulla on mahdollista päästä käsiksi palvelussa oleviin käyttäjälle näkyviin tietoihin kuten käyttäjän sessiotietoihin ja muihin kekseihin sekä käyttäjälle sivulla näytettävään sisältöön. Lisäksi on mahdollista muokata käyttäjälle näkyvää sisältöä, piilottaa palvelun lähettämää sisältöä käyttäjältä tai lisätä täysin uutta sisältöä sivulle. On myös mahdollista tehdä uudelleenohjauksia, niin että kohteena ollut palvelu näkyy Referer-kentässä.

XSS-haavoittuvuukset voidaan jakaa pääasissa kahteen tyyppiin: pysyviin ja väliaikaisiin. Pysyvässä haavoittuvuudessa on mahdollista tallentaa XSS-koodi web-palveluun. Tämä voisi olla esimerksi foorumi-postaus, joka suorittaa client-side-koodia kaikilla käyttäjillä, jotka lukevat viestin. Tämä on vakavampi kuin väliaikainen XSS-haavoittuvuus sillä se leviää nopeasti kaikille web-palvelua käyttäville. Väliaikaisessa haavoittuvuudessa XSS-koodi ei ole tallennettuna web-palvelussa vaan kohteena oleva käyttäjä itse lähettää sen. Tyypillisesti tämä on HTTP GET -parametri. Väliaikainen XSS ei leviä automaattisesti vaan kohteena olevat käyttäjät täytyy jollain konstilla saada itse tekemään tietynlainen HTTP-pyyntö. Mikäli sivusto näyttää GET-parametrin verkkosivulla sellaisenaan, voi hyökkääjä sisällyttää URL-osoitteeseen haluamaansa JavaScript?-koodia, joka ajetaan jokaisen osoitteen avanneen selaimessa. Tyypillisesti haitallisia osotteita jaetaan kohdennetusti sähköpostitse tai pikaviestein. Jotkut hyökkääjät ovat jopa ostaneet mainostilaa verkkosivulta ja sijoittaneet tähän tilaan linkin, jonka kuormana on XSS-koodia.

Tommi Kaipainen (2015-k): Reflected XSS

"Heijastetussa" XSS-hyökkäyksessä käytetään hyväksi sovelluksen ominaisuutta, jossa sovellus heijastaa virheviestin suoraan sellaisenaan dynaamiselle sivulle. Kehittäjien kannalta ominaisuus on hyvä, koska voidaan luoda kustomoituja virheviestejä, mutta ilman minkäänlaisia tarkisteluja välissä sovellus on haavottuvainen. Kenttään syötetyn virheellisen arvon tilalle voidaan nyt syöttää mitä vain, esimerkiksi javascriptiä, jonka avulla voidaan suorittaa haitallisia toimintoja. Tämän tyyppinen bugi muodostaa n. 75% oikean maailman web-sovellusten XSS-haavoittuvuuksista.

Yksi yksinkertaisimmista ja eniten käytetyistä tavoista hyödyntää em. XSS-haavoittuvuutta on kaapata käyttäjän "session token/ID" (suojaustunnus). Hyökkääjä syöttää käyttäjälle väärän URL:in, jonka kanssa käyttäjä keskustelee ja palvelin vastailee puolestaan hyökkääjän javascript-viesteillä. Kaapatun session seurauksena hyökkääjän on mahdollista saada tietoa käyttäjän henkilötiedoista ja suorittaa vahingollisia toimia esiintyen käyttäjänä. Jotkut sovellukset käyttävät "muista minut" -toiminnossaan pysyvää evästettä, minkä vuoksi käyttäjän ei tarvitse edes olla aktiivisessa sessiossa, jotta hyökkäys voisi toimia. Nykyisin selaimet osaavat jo varautua osaan hyökkäyksistä muokkaamalla ja estämällä tekstin suoraa kopioitumista ei-haluttuun paikkaan (XSS Filter).

13. Attacking Users: Other Techniques

Luvussa esitellään useita erilaisia tekniikoita, joilla voidaan hyökätä web-palvelun käyttäjää vastaan.

Tapio Linnimäki (2012-s): CSRF (Cross-Site Request Forgery)

CSRF-hyökkäyksen tarkoituksena on käyttää hyväksi sitä, että selaimet automaattisesti lähettävät web-palvelun asettamat evästeet samaan web-palveluun tehtävien seuraavien pyyntöjen mukana. Näin voidaan pitää yllä tilatietoa esimerkiksi käyttäjän kirjautumisesta palveluun. Tästä johtuen hyökkääjä voi tehdä viattoman oloisen sivun, joka tekeekin hyökkäyksen kohteena olevaan palveluun jonkin pyynnön, johon normaalisti tarvittaisiin hyökkäyssivulle houkutellun uhrin oikeuksia. Jos uhri on samalla kirjautuneena palveluun, lähtee pyynnön mukana uhrin evästeet, kuten tieto kirjautumisesta, jolloin palvelu luulee, että kyseessä on uhrin itse tekemä haluttu toiminto. Hyökkääjä voi käyttää esimerkiksi POST-pyynnön tekemiseen piilotettuja lomakekenttiä ja javascriptiä lomakkeen automaattiseen lähettämiseen käyttäjän ladatessa haitallisen sivun. Siis pelkkä haitallisen sivun lataaminen riittää hyökkäyksen tapahtumiseen. Same-origin rajoituksen takia CSRF on yksisuuntainen hyökkäys, eli hyökkääjä ei pysty prosessoimaan pyynnön vastausta.

Standardi tapa suojata palvelu CSRF-hyökkäyksiltä on käyttää lisätunnisteita pyynnöille, joilla on jotain sivuvaikutuksia. Palvelu generoi lisätunnisteen kun käyttäjä lataa sivun ja tunnisteen välittämiseen käytetään piilotettuja lomakekenttiä. Palvelu tietää oikeasta lisätunnisteesta, että pyyntö oli laillinen. Tätä tapaa käytettäessä täytyy varmistua siitä ettei hyökkääjän ole mahdollista arvata tai päätellä generoidun lisätunnisteen arvoa.

Vili Nikkola (2014-s): Open Redirection Vulnerabilities

Avoimen uudelleenohjauksen tarkoituksena on huijata käyttäjää tarjoamalla sille linkki, joka näyttää tai on käyttäjän haluaman osoitteen kaltainen. Tätä uudelleen ohjausta käytetään usein tietojen kalasteluun tai pilailuun. Uudelleen ohjaus on lievempi tietoturvariski kuin cross-site scripting mutta toisaalta helpompi toteuttaa ja käyttäjän luottamuksen saa oikealta näyttävällä linkillä myös helposti. Useimmat tietojen kalastelijat käyttävät muita keinoja hyökkäykseen, kuten oikealta kuulostavia domainnimiä tai alidomaineja. Tutkimusten mukaan monet käyttäjistä eivät tee tietoturvapäätöksiä katsoessaan linkkien rakennetta. Yksi esimerkki uudelleenohjauksesta on mennä vuosien trendi, jossa käyttäjiä rickrollattiin eli huijattiin netin selailija youtube-videoon, jossa pyöri Rick Astleyn kappale Never gonna give you up.

Uudelleenohjausta voidaan tehdä monin tavoin:
- HTTP headerissa kutsutaan 3xx-statuskoodia (esim 302) ja kerrotaan location avainsanalla minne käyttäjä ohjataan
- Niin ikään http headerissa voidaan käyttää refreshia, tai <meta>-tägiä mukailemaan headerin käyttäytymistä
- Javascriptillä voidaan myös toteuttaa uudelleenohjausta.
Monet uudelleenohjaustavoista eivät ole käyttäjän hallinnassa.

* 14. Automating Customized Attacks

Aleksi Sillanpää (2014-k) Hyökkäysten automatisointi

Hyökkäysten manuaalinen syöttäminen selaimen kautta kohdesivustoon on työlästä. Hyökkäysten automatisointi nopeuttaa hyökkäystä paljon ja sen ansiosta voidaan käydä läpi syötetietojen variaatioita ja mahdollisesti käyttää myös bruteforce-tekniikoita. Hyökkääjä voi tehdä ohjelman tai scriptin, joka suorittaa hyökkäyksen kohdesivuun. Automatisoidulla ohjelmalla voidaan myös kerätä tietoja sivusta ja selvittää kaikki sallitut syötteet ja tunnisteet (id:t) tehokkaasti.

Tietoa voi saada mm. tekemällä sovellukselle automatisoituja pyyntöjä ja tulkita sitten saatua vastausta HTTP koodin perusteella (200-ok, 404-not found...). Skivustoilta voi myös yrittää kaivaa tietoja muista käyttäjistä, muuttamalla pyynnön mukana käyttäjän id:tä ja käyttämällä istuntojen id:itä, joita voidaan bruteforce:ttaa. Näin voi mahdollisesti saada käyttäjän tiedot, kuten käyttäjätunnukset ja salasanat.

Automatisoinnilla voidaan käyttää myös Fuzzing tekniikkaa jolla pyritään paljastamaan sivustolta tietoturvavirheet. Tarkoittaa sitä, että sivuston syötekenttiin ja muihin kohteisiin lähetetään esim. SQL-injektioita ja XSS-testejä.

Automatisoidulla hyökkäystyökalulla voidaan myös tutkia ja ohittaa CAPTCHA tarkistuksia. Sivustolla voi olla näkyvillä esim. piilotetussa kentässä Captcha-kuvan koodi. Myös OCR eli Optical character recognition on mahdollista. Rikolliset käyttävät myös ihmisiä apunaan Captcha koodien tunnistamiseen. Heille toimitetaan useita Captcha kuvia ja he selventävät siinä olevat merkit ja he saavat siitä palkkaa.

Jarmo Puttonen (2015-s) Kustomisoidut automaattiset hyökkäykset

Yksinkertaiseksi kustomisoiduksi hyökkäykseksi voidaan laskea esimerkiksi jonkun tietyn sivuston käyttämän URLin GET-parametrin enumerointi, jota ei voida tehdä automaattisesti jollain haavoittuvuus-skannerilla.

Esimerkkinä http://diudiu.com/profile.php?userId=2122, jossa 2122 on tietyn käyttäjän ID. Hyökkääjä voi käydä käsin lävitse Id-sivuja muuttamalla userId-numeroa ja voi käsin kopioida käyttäjien tietoja itselleen talteen. Mikäli käyttäjiä on tuhansia, niin tämä on hyvin aikaa vievä prosessi joka voidaan automatisoida.

Kirjan luvussa ohjeistetaan kuinka voidaan selvittää voiko jonkin hyökkäyksen automatisoida ja kuinka pystytään arvioimaan automatisoidun hyökkäyksen onnistumista esimerkiksi tarkkailemalla palautettuja virheviestejä. Luvussa luodaan esimerkin vuoksi Java-kielellä yksinkertainen fuzzer, jolle voi antaa erinäisiä arvoja joita hyväksikäyttäen se hyökkää yksilöityyn kohteeseen.

Kirjan luvussa kerrotaan myös Burp Suite-ohjelmistosta, jolla pystyy luomaan hyvinkin monipuolisia automatisoituja hyökkäyksiä. Burp suitella voitaisiin mm. määrittää hyökkäys, joka käy ylläolevan esimerkin kaikki userId-arvot lävitse ja tallentaa näiden sivujen sisältä halutut arvot. Lisäksi Burp suiteen voidaan mm. luoda makroja, jolloin pystytään esimerkiksi ohjeistamaan Burp suite kirjautumaan sivustolle uudestaan mikäli hyökkäyksen keskellä aiheutuu jostain syystä uloskirjautuminen.

15. Exploiting Information Disclosure

Jukka Viertola (2013-s) Tiedon paljastumisen hyväksikäyttäminen

Monet Web-sovellukset palauttavat informatiivisiä virheilmoituksia kun odottamaton virhe tapahtuu. Sovellusten antamat virheilmoitukset tuottavat myös usein ylimääräistä, tapauskohtaista dataa. Vaikka tarpeetonta tietoa vuotaisikin murtautujalle, ei se aiheuta usein minkäänlaista sovelluksen tietoturvaa vaarantavaa uhkaa itsessään. Jopa erittäin spesifi virheilmoitusten kasa ei usein hyödytä hyökkääjää.

Se, miten hyökkääjät voivat hyödyntää tätä paljastunutta dataa, on löytää tietolähteitä käytössä olevasta sovelluksesta. Esimerkiksi virheilmoituksen palauttaessa tarkan version ohjelmistokomponenteista, voi hyökkääjä etsiä näitä tietoja käyttäen juuri kyseisen ohjelmistoversion haavoittuvuuksia.

Hyökkäys siis tapahtuu sillä tapaa, että pyritään aiheuttamaan sovellukselle odottamaton virhe, minkä takia saadaan jonkunlainen virheilmoitus. Annettavia parametrejä muuttamalla voidaan analysoida virheilmoituksen muuttumista, ja ajaa sitä jossain tapauksissa haluttuun suuntaan. Virheilmoituksen antamien tietojen avulla voidaan valmistautua varsinaiseen hyökkäykseen.

Antti Nikkilä (2014-s):

Luku käsittelee web-sovellusten antamia virheilmoituksia ja sitä miten niitä voidaan, jos voidaan, hyödyntää hyökkäyksessä.

Yleensä tarpeettomat nettisovelluksesta tulevat tietovuodot eivät aiheuta merkittävää suoranaista uhkaa sovelluksen tietotuvallisuuden kannalta. Jotkin pitkät virheenkorjausviestit saattavat silti antaa ison määrän hyödyllistä tietoutta, jota voi käyttää hyökkäyksen apuna. Informatiiviset virheilmoitukset voivat olla peräisin varsinaisen sovelluksen taustakomponenteista, kuten tietokannasta, sähköposti- tai SOAP-serveristä. Lisäksi moni sovellus käyttää jotain kolmannen osapuolen komponenttia, kuten hakua, ostoskärryä tai palauteosiota joista järjestelmän kokoonpanon lisäinfoa voi irrota. Virheviestit saattavat sisältää kriittistä tietoa järjestelmän heikkouksista. Viestit kertovat monesti suoraan, mikä virheen on aiheuttanut. Yhdistämällä virheilmoituksista saatavia tiedonmuruja hyökkääjä voi hienosäätää hyökkäyksensä paremmin ja kaventaa suunniteltua hyökkäysaluetta. Onnistuessaan hyökkäyksellä voidaan saavuttaa käyttäjätietoja, tietoja käytetystä teknologiasta ja järjestelmän rakenteesta.

Luvussa esitellään erilaisia virheilmoituksia ja kuinka niitä tulee tulkita sekä mikä on hyökkääjän kannalta oleellista tietoa. Tämän lisäksi kerrotaan kuinka niitä voi käyttää vipuvartena hyökkäyksessä. Kappaleessa käydään myös läpi, mistä dokumenteista virheilmoituksia voi yrittää etsiä, elleivät ne ole kokonaisuudessaan ilmestynyt selaimelle.

16. Attacking Native Compiled Applications

Eero Airasvirta (2013-s)

Nykyisin enää harvat web-sovellukset on tehty käyttämällä kieliä, joissa koodi käännetään binääriseksi konekoodiksi ja joissa ohjelmoijan täytyy huolehtia muistinhallinnasta. Kuitenkin esimerkiksi sovellukset jotka pyörivät verkossa olevien laitteiden, kuten tulostimien ja kytkimien päällä, on usein toteutettu esimerkiksi C-kielellä. Tällaisissa sovelluksissa voi olla etenkin puskurin ylivuodosta sekä kokonaislukujen lukualueiden ylittymisistä aiheutuvia haavoittuvuuksia. Joissakin tapauksissa hyökkääjän on mahdollista saada sovellus suorittamaan palvelimella mielivaltaista ohjelmakoodia, mutta usein tuloksena on sovelluksen kaatuminen ja näin sen käytön estäminen muilta.

Hyökkääjä voi hyödyntää esimerkiksi pinon ylivuotoa antamalla sovellukselle sopivaan kohtaan syötteeksi niin paljon dataa, ettei se mahdu sille varattuun tilaan. Olkoon ohjelmakoodissa on funktio, joka ottaa parametriksi käyttäjän antaman merkkijonon (taulukon) ja kopioi sen toiseen muuttujaan jonka enimmäispituudeksi on määritelty vaikka 32 merkkiä. Kun funktiota kutsutaan, tallennetaan funktion paluuosoite pinoon, jonka jälkeen pinosta varataan tilaa funktion muuttujille eli tässä 32-tavuiselle taulukolle. Jos käyttäjä antaa syötteenä yli 32 merkkiä pitkän merkkijonon, tapahtuu puskurin ylivuoto. Ylijäävät merkit kirjoitetaan muistiin tämän taulukon perään, jossa nyt kuitenkin on funktion paluuosoite. Sopivasti valitsemalla hyökkääjä voi siis saada ohjelman suorituksen hyppäämään täysin vapaasti valitsemaansa osoitteeseen.

Juho Kiiveri (2014-k) Hyökkääminen natiivisti koottuihin ohjelmiin

Kokonaisluku heikkoudet tapahtuu kun ohjelma tekee jonkun aritmeettisen toiminon pituus arvon ennen kuin se tekee puskuri toiminon mutta epäonnistuu viemään tilille toimintoja joilla kääntäjä ja prosessori käsittelee kokonaislukuja. Kaksi tärkeintä kokonaisluku vikaa ovat ylivuoto ja etumerkittömyys. Kokonaisluku ylivuodot tapahtuvat kun toimenpide kasvattaa sitä yli sen maksimiarvon tai pienentää sitä alle sen minimiarvon. Kun tämä tapahtuu suuresta luvusta tulee pieni ja toisinpäin. Etumerkkittömyys virheet tapahtuvat kun ohjelma käyttää sekä etumerkillisiä ja etumerkkittömiä kokonaislukuja puskereiden pituuksien mittaamiseen ja sekoittaa ne jossain vaiheessa. Joko ohjelma tekee suoran rinnastuksen etumerkillisen ja etumerkittömän välillä tai se päästää etumerkillisen arvon parametrinä funktioon joka ottaa etumerkittömiä arvoja. Molemmissa tapauksissa etumerkillistä arvoa käsitellään niin kuin se olisi etumerkitön ekvivalentti jolloin negatiivisesta numerosta tulee iso positiivinen numero.

* 17. Attacking Application Architecture

Aki Mäkinen (2014-k): Hyökkääminen sovelluksen arkkitehtuuria kohtaan

Luku 17 käsittelee web-sovelluksen arkkitehtuuriin liittyviä haavoittuvuuksia. Monikerroksisessa arkkitehtuurissa yhdenkin kerroksen sisältämä haavoittuvuus voi vuotaa muihin kerroksiin ja auttaa sitä kautta hyökkäämään muita kerroksia vastaan. Hyökkäyksen periaatteen on siis käyttää hyväksi kerrosten välistä luottamusta toisiinsa ja edetä tasolta toiselle. Puolustuskeinoiksi kirjassa esitetään luottamussuhteiden minimointi, komponenttien eriyttäminen toisistaan ja puolustus-mekanismien käyttö kaikilla tasoilla.

Kappale käsittelee myös jaettujen palveluiden tietoturvaa ja hyökkäyksiä; miten virtuaalihosteja ja ohjelmistopalveluntarjoajia (ASP) voidaan käyttää hyväksi hyökkäyksissä. ASP:n tapauksessa, yhtä asiakasta kohtaan toteutettu onnistunut hyökkäys vaarantaa monien asiakkaiden tietoturvan, sillä sama menetelmä voi toimia myös heidän kohdalla.

Esimerkkeinä arkkitehtuuritasoihin kohdistuvista hyökkäyksistä Stuttard ja Pinto käyttävät tiedostopolkua ja komentojen suoritusta. Tiedostopolkuhyökkäyksessä tiedoston nimi määritellään esimerkiksi url-parametrina ja jos annettua tiedostonnimeä ei käsitellä mitenkään, on hyökkääjän mahdollista syöttää esimerkiksi tietokantatiedoston sisältävä polku nimeksi ja päästä käsiksi näin tietokannan sisältöön.

Petri Sandström (2015-s): Monitasoinen arkkitehtuuri huomattavasti yksinkertaista turvallisempi

Suurin osa web-sovelluksista käyttää monitasoista arkkitehtuuria, jossa käyttöliittymä, bisneslogiikka ja tietokanta on jaettu useampaan eri tasoon. Monitasoinen arkkitehtuuri on huomattavasti yksitasoista arkkitehtuuria tietoturvallisempi, sillä jakamalla kompleksiset prosessit yksinkertaisiin ja modulaarisiin funktioihin, voidaan funktio korvata uudella tai korjaa haavoittuvuus yhdestä osaa arkkitehtuuria. Monitasoinen arkkitehtuuri parhaimmassa tapauksessa pitää haavoittuvuuden sisällään hallittavana osana. Jos eri tasoja ei ole riittävissä määrin eriytetty vastuualueiltaan, voidaan eri tason arkkitehtuuriin murtautua esim. haavoittuneen autentikointikerroksen avulla.

Esimerkki edellä mainitusta hyökkäyksestä on esimerkiksi salasanojen tai muun kryptatun arkaluontoisen datan saaminen selkokieliseksi. Jos datakerrokseen on päästy käsiksi esimerkiksi SQL injektiota käyttämällä, voi hakkeri löytää kryptauksen purkufunktion helposti ja päästä käsiksi selkokieliseen dataan.

18. Attacking the Application Server

Henri Kuokkanen (2014-k) : Attacking the Application Server

Kirjan kohta käsittelee ja keskittyy tapoihin hyökätä web-serveri tason haavoittuvuuksiin web-sovelluksissa. Nämä jaetaan karkeasti kahteen eri kategoriaan; ongelmiin serverin asetuksissa ja määrittelyissä, sekä tietoturva ongelmiin web-sovelluksessa.

Web-serveri on erittäin merkittävä osa, kun katsotaan web-applikaatioihin kohdistuvia hyökkäyksiä. Ongelmat serverissä voivat heikentää paljonkin ohjelman turvallisuutta antamalla pääsyt erilaisiin hakemistoihin, sivujen suoritettaviin lähdekoodeihin, arkaluontoisiin conffaus-tiedostoihin, ajonaikaisiin tietoihin sekä mahdollisuuksiin ohittaa syötetarkastelut. Tämän kaiken torjuminen voi olla hyvinkin ongelmallista, sillä web-servereitä ja niiden versioita on lukematon määrä, jolloin niiden tunteminen ilman perehtymistä on mahdotonta.

Tätä ongelmaa kuitenkin helpottaa se, että automaattiset työkalut, jotka skannaavat tunnettuja haavoittuvuuksia sekä erilaisia ongelmia asetuksissa, ovat parhaimmillaan hyvinkin tehokkaita. Näiden käytöllä, sekä perehtymällä yksityiskohtaisesti käytettävän web-serveri ohjelman ongelmakohtiin voidaan pienentää web-sovellukseen kohdistuvia tietoturvaongelmia.

Aleksi Savijoki (2014-s): 3.Kuinka käyttää hyväksi web serveriä, joka on konfiguroitu käyttäytymään kuten web proxy?

Kirjan luvussa käsitellään asioita lähinnä hakkeroijan näkökulmasta ja siinä mainitaan, että hyökkääjä voi käyttää serveriä hyökkäämään kolmannen osapuolen systeemejä vastaan internetissä. Tämä onnistuu tahallisen liikenteen ohjauksella kohteeseen, joka saa alkunsa haavoittuvana olevasta proxy serveristä.

Toinen mahdollisuus hyökkääjällä on päästä käsiksi organisaation sisäiseen verkkoon proxyn avulla, ja näin ollen saada tietoa, joka ei välttämättä ole mahdollista saada suoraan internetistä. Tämä voi olla myös hyödyllistä silloin, jos hyökkääjän kohde sijaitsee yrityksen sisäisessä verkossa, jolloin on tarpeellista päästä ensin sisäverkkoon, ennenkuin pääsee varsinaisesti kohteeseen käsiksi.

Mahdollisia muita haavoittuvuuksia proxyssa voi tutkia käyttämällä connect -metodia määrittääkseen hostin tunnuksen ja porttinumeron. Riippuen siitä, miten serveri vastaa metodiin, voi päätellä onko yhteys proxyna vai ei. Tosin useimmilla proxy servereillä on rajoitukset porttien osalta (mihin portteihin on mahdollista päästä käsiksi connect -metodilla) ja saattavat hyväksyä vain yhteydet, jotka koskevat porttia 443.

SivuTiedotLaajennettu edit
Vaativuus Jatko
Valmius Kehitteillä
Tyyppi Ydin
Luokitus Uhkat
Mitä Useita
Miltä Tahallinen uhka
Missä Järjestelmä
Kuka Titu-ammattilainen
Milloin Muu
Miksi Muu

 
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback