WWW-ohjelmointi ANTTI SAND TIETA12

Transkriptio

1 WWW-ohjelmointi ANTTI SAND TIETA12

2 Turvallisuus 2

3 Älä koskaan luota käyttäjiisi 3 Muutama yleinen haavoittuvuus SQL Injektio XSS (Cross Site Scripting) CSRF (Cross Site Request Forgery) Salasanojen huolimaton tallennus

4 SQL Injektio 4

5 SQL Injektio 5 Lähde:

6 SQL Injektio 6 Halutaan päivittää käyttäjän nimi vastaamaan lomakkeelta tullutta nimeä Syöte kirjoitetaan sellaisenaan SQL kyselyn osaksi Toimii oikein, jos lomakkeelle kirjoitetaan Saku Mutta jos lomakekenttään kirjoittaisi Sami, last_name= Sammakko ; -- Kysely päivittää jokaisen käyttäjän nimeksi Sami Sammakko. WHERE jätetään suorittamatta eikä id:tä rajata

7 SQL Injektio 7 Tämä esimerkki olisi harmillinen, mutta ei kovin vaarallinen Mutta samalla tavalla oltaisiin voitu poistaa kaikki tiedot tietokannasta Tai antaa itselle pääkäyttäjäoikeudet Tai tulostaa muiden käyttäjien tiedot Miten SQL Injektio torjutaan? Oikeastaan olemme varautuneet siihen koko ajan Käytetään PDO luokan prepare() ja bind() metodeja Muuttujia ei tulkita osaksi sql kyselyn merkkijonoa, vaan ne sidotaan

8 8 XSS Cross Site Scripting

9 Cross Site Scripting 9 Suoritetaan ulkopuolista koodia järjestelmän sisällä Esimerkiksi koodissa toteutettu reititys /index.php?page=about Require $_GET[ page ]..php ; Hyökkääjä voi vaihtaa GET parametrin ja saada sivun suorittamaan oman koodinsa järjestelmän osana Tavoite on siis luoda uusi linkki (index.php?page= Ja saada tämä linkki jonkin sivuston käyttäjän klikkaamaksi Kokematon käyttäjä näkee, että osoite todella alkaa tunnetun sivun osoitteella, joten hänen kannaltaan se näyttää turvalliselta Klikattaessa ohjelma ajetaan hänen ollessa kirjautunut käyttäjä

10 Cross Site Scripting 10 Jaetaan DOM pohjaisiin, ei-pysyviin ja pysyviin DOM pohjaiset Käyttäjä saa syöttää HTML tai JavaScript koodia Ei-pysyvät Hyökkäävä koodi ei tallennu järjestelmään, vaan toimii vain sen yhden pyynnön ajan Käyttäjällä on oikeus nähdä luottokorttitietonsa, kun hän on kirjautunut Pysyvät Haitallinen koodi saa siis myös nähdä nämä tiedot Hyökkäävä koodi tallentaa muutoksia järjestelmään Käyttäjällä on oikeus kirjoittaa kommentteja, jotka tulevat muiden nähtäville Haitallinen koodi saa kirjoittaa sisältöä, joka näytetään kaikille muille sivun käyttäjille

11 Cross Site Scripting 11 Miten puolustaudutaan? Ei koskaan luoteta käyttäjään Mitään ulkopuolelta tulevaa sisältöä ei oteta osaksi koostettavaa sivua ilman sen sanitoimista Aiemmin mainitut htmlspecialchars() ja htmlentities() Jos halutaan sallia jotkin koodit (esim. Kommenteissa yksinkertaiset HTML muotoilut), voidaan sallia rajattu joukko turvallisia koodeja Aina kun $_GET, $_POST tai tietokannasta tuleva muuttuja tulostetaan ruudulle Echo htmlspecialchars($_get[ nimi ]); Muutama tunnettu onnistunut XSS hyökkäys:

12 12 CSRF Cross Site Request Forgery

13 XSS ja CSRF 13 XSS hyödynsi käyttäjän luottamusta sivustoon Sivusto on tunnettu, se ei voi olla vaarallinen CSFR hyödyntää sivuston luottamusta käyttäjään Käyttäjä on tunnettu, sallitaan toimenpiteet

14 CSRF 14 Jos käyttäjä on kirjautunut, hänellä on voimassa istunto Jos käyttäjä haluaa tehdä toiminnon X ja hänellä on oikeus tehdä toiminto X ei ole syytä estää häntä tekemästä toimintoa X Mutta halusiko käyttäjä oikeasti tehdä toiminnon X? Kuvitellaan, että meillä on reitti GET /deleteuser, joka poistaa kirjautuneen käyttäjän tilin Jos käyttäjä saadaan klikkaamaan linkkiä vaikkapa kuvasta samalla kun hänellä on istunto voimassa, ei ole syytä estää tilin poistamista Todellisuudessa tietoa muokkaavat reitit eivät saisi vastata GET pyyntöön Mutta JavaScriptin avulla voidaan tehdä POST /deleteuser

15 CSRF 15 Jos GET kutsu muokkaa tietoja, ei tarvitse edes klikata linkkiä Tiedetään, että sivuston X käyttäjä käy keskustelualueella Y Lisätään keskustelualueelle kuva <img src= > Kun käyttäjän selain yrittää ladata kuvaa, se tekee GET pyynnön kuvan srcosoitteeseen Jos käyttäjä oli kirjautuneena sisään, tili poistettiin

16 CSRF 16 Miten suojaudutaan? Tietoja muuttavat reitit eivät kuuntele GET kutsuja Kirjaudu ulos linkki on siinä rajoilla. Helppo arvata polku, melko pieni haitta. GET tai POST, molemmille on perusteensa Käytetään CSRF tokenia Luodaan satunnainen merkkijono $token Tallennetaan $token istunnon muuttujaksi $_SESSION[ token ] = $token; Lisätään $token tulostettavan lomakkeen piilokentäksi <input type= hidden name= token value= <?= $token;?> > Pyynnön saapuessa tarkistetaan ensin, että $_SESSION[ token ] == $_POST[ token ]

17 Defensiivinen ohjelmointi 17

18 Defensiivinen ohjelmointi 18 Aiemmassa esimerkissä luotiin ohjelma, jolla voi lisätä taskeja listalle Sovitaan, että taskien lisääminen sallitaan vain kirjautuneilta käyttäjiltä Vierailijalle ei näytetä linkkiä lisäyslomakkeeseen Jos lomakepolkua yritetään ladata, tarkistetaan, onko kirjautunut käyttäjä Jos resurssia yritetään tallentaa, tarkistetaan onko kirjautunut käyttäjä Lisätään polku resurssin poistamiselle, muistettiinko lisätä tarkistus kirjautumisesta? Muutetaan ajattelua siten, että metodi estetään aina, paitsi jos on kirjautunut Eli kaikki on kiellettyä, paitsi siinä tapauksessa, että se on sallittua On pienempi ongelma, jos sallittua asiaa ei saa tehdä, kuin että jos kielletyn asian saa tehdä. Ensimmäisen useammin muistaa testata.

19 Sovelluskohtainen 19 poikkeustenkäsittelijä Poikkeuksien tulostaminen näytölle on kätevää kehitysvaiheessa, mutta tuotannossa poikkeukset tuottavat hyökkääjälle tietoja järjestelmän rakenteesta Anna poikkeusten kuplia yhteen koko sovelluksen laajuiseen poikkeustenkäsittelijään, jossa kehityspavelimella voidaan näyttää poikkeukset ruudulla, mutta tuotantopalvelimella ne kirjoitetaan lokiin Näin voit myös antaa käyttäjälle vähemmän kryptisiä virheilmoituksia

20 Salasanojen tallentamisesta 20

21 Tietokantoihin murtaudutaan 21 Aina joskus Tästä tekee hyvin ison ongelman se, että tietokannassa saattaa vuotaa kerralla hyvin iso määrä dataa Jos käyttäjien kirjautumistiedot vuotavat, hyökkääjä saa paljon sähköpostiosoite/salasana pareja, joista iso osa todennäköisesti toimii muillakin sivuilla Koska käyttäjät eivät jaksa keksitä uutta salasanaa joka sivustolle Tästä syystä tietokannoissa ei koskaan tule säilyttää salasanoja Jos jokin käyttämäsi sivu tarjoaa sinulle mahdollisuuden nähdä oman salasanasi vaikkapa sähköpostitse, kannattaa miettiä salasanojen vaihtamista

22 Tietokantoihin murtaudutaan 22 Vain muutama viimeaikainen käyttäjätietojen vuoto: LindedIn vuoti kuuden miljoonan käyttäjän tiedot vuonna 2012 Yahoo! vuoti käyttäjän salasanat vuonna 2012 Nvidia vuoti salasanaa vuonna 2012 Adobe vuoti salasanaa vuonna 2012 eharmony vuoti salasanaa vuonna 2013

23 Ei salasanaa tietokannassa 23 Älä koskaan tallenna käyttäjän salasanaa tietokantaan! Jos emme tiedä käyttäjän salasanaa, miten voimme tietää, onko annettu salasana oikea? Kun käyttäjä asettaa salasanansa, siitä lasketaan yhdensuuntaisella tiivistefunktiolla tiiviste (hash) Tämä tiiviste voidaan tallentaa tietokantaan Kun käyttäjä kirjautuu sisään, lasketaan annetusta salasanasta jälleen tiiviste ja verrataan sitä tietokannassa olevaan Tiivistefunktio on yhdensuuntainen. Funktiota ei voida ajaa tiivisteelle siten, että alkuperäinen tieto palautuisi Pelkkä yksinkertainen tiivistefunktio avaa kuitenkin oven rainbow table - hyökkäykselle

24 Tiivisteistä 24 Tiivistefunktio palauttaa tietyn määrän bittejä annetun datan pohjalta Md5 tiiviste palauttaa 126 bittiä, eli 16 tavua, eli 32 hexadesimaalimerkkiä echo md5("salasana"); //e7e941b1f09f266540c6780db51d5f58 Tiivistettä ei saada enää alkuperäiseen muotoonsa, mutta funktio palauttaa samalla salasanalla aina saman tiivisteen Voidaan siis laskea valmiiksi tiivisteet kaikille mahdollisille merkkijonoille tiettyyn maksimiin asti ja sitten verrata tietokannasta vuotanutta tiivistettä taulukkoon, jossa on kaikki mahdolliset permutaatiot ja salasana, joka siihen johti (rainbow table -hyökkäys) Voidaan lisätä tiivistefunktiolle suola (salt), eli ylimääräistä dataa, jolloin valmis rainbow table ei ole suoraan hyödynnettävissä

25 Tiivistefunktioita 25 MD5, SHA1, SHA256, SHA512, SHA-3, Nämä ovat yleiskäyttöisiä tiivistefunktioita, jotka laskevat tiivisteen isosta tietomäärästä mahdollisimman tehokkaasti Tästä syystä moderni tietokone voi laskea >300mb/s tiivisteitä Jos salasana on vain pieniä kirjaimia ja numeroita ja se on 6 merkkiä pitkä, kaikki permutaatiot voidaan laskea alle minuutissa Suola menettää merkitystänsä laskentatehon kasvaessa eikä muutenkaan suojaa sanakirjahyökkäyksiltä

26 Rainbow Table 26 a => 0cc175b9c0f1b6a831c399e aa => 4124bc0a9335c27f086f24ba207a4912 ab => 187ef d1cc2f40dc2b92f0eba0 ac => e e013ee4dd2201c7a73 ad => 523af537946b79c4f8369ed39ba salasana => e7e941b1f09f266540c6780db51d5f58 Jos saamme kaapattua tietokannasta tiivisteen e7e941b1f09f266540c6780db51d5f58, voimme etsiä sitä vastaavan salasanan (salasana).

27 Hitaus on hyväksi 27 Nopeasti laskettava tiiviste tekee rainbow table:n laskennasta nopeaa Haluamme siis algoritmin, joka on mahdollisimman hidas Mutta Mooren lain mukaan halvasti toteutettavien mikropiirien transistorien määrä kaksinkertaistuu noin kahden vuoden välein Ja tämä on jokseenkin pitänyt paikkansa jo vuodesta 1965 Eli laskenta nopeutuu ja aiemmin hidas algoritmi muuttuu nopeaksi Eli tarvitsemme algoritmin, jonka hintaa voidaan kasvattaa laskentatehon kasvaessa

28 BCrypt 28 BCrypt käyttää Blowfish salauksen varianttia EksBlowfish On luonteeltaan paljon kalliimpi operaatio ja tuo mukanaan work factor ominaisuuden, jolla laskennan hintaa voidaan kasvattaa tietokoneiden tehojen kasvaessa Näin ollen se ei vanhennu Mooren lain mukaisesti Salt on sisäänrakennettu ja muodostuu osaksi tiivistettä BCrypt on tällä hetkellä suositeltu ja on PHP:n password_hash funktion oletussalaaja Mutta onko se turvallinen? CIA maksoi RSA -salausta hallinnoivalle RSA:lle algoritmin pitämisestä juuri sen verran heikkona, että he voivat sen murtaa PHP:n password_hash funktio on toteutettu siten, että kielen uudemmassa versiossa voidaan vaihtaa BCrypt parempaan salaukseen, jos sellaiselle ilmenee tarvetta

29 BCrypt 29 BCrypt julkaistiin vuonna 1999 ja sitä on tutkittu kattavasti. Koska sen laskenta on hitaampaa, se tarjoaa pienen lisäsuojan tiivistetaulukoiden valmiiksi laskemista vastaan. Tällä hetkellä sitä pidetään kryptografisesti turvallisena. BCrypt:llä voi tiivistää vain 72 merkkiä, joten se asettaa ylärajan salasanoille Mutta vaikka käyttäjä kirjoittaisi pidemmän salasanan, siitä voidaan tarkistaa vain ensimmäiset 72 merkkiä, joten se ei haittaa BCrypt:n turvallisuuden puolesta puhuu sekin, että se on BSD - käyttöjärjestelmän ja joidenkin suosittujen Linux jakeluiden oletustiivistefunktio salasanoille.

30 SCrypt 30 SCrypt on uusi kisaaja, se julkaistiin vuonna SCrypt on muisti-intensiivinen derivaattafunktio. Teoriassa SCrypt:n pitäisi olla turvallisempi kuin BCrypt:n, koska sen algoritmi on hitaampi. Haittapuolena on uutuus. Yleensä kryptografiassa uusi funktio on "huonompi", koska sitä ei ole vielä taistelutestattu niin kauaa. Tästä syystä BCrypt saattaa olla vielä parempi valinta. Tämä tilanne saattaa kuitenkin muuttua tavallista nopeammalla aikataululla, sillä SCrypt:iä käytetään muutamissa kryptovaluutoissa, kuten Litecoin ja Dogecoin, joka puolestaan tarkoittanee sitä, että se tulee kohtaamaan huomattavan määrän murtoyrityksiä nopeammin, kuin edeltäjänsä.

31 Tiivisteiden tallentamisesta 31 BCrypt tuottaa joka kerralla erilaisen tiivisteen, koska salt muuttuu Näin rainbow table menettää tehonsa Mutta salt on osa tiivistettä, joten voidaan varmistaa onko salasana oikein password_verify( salasana, $tiiviste); Vaikka tiivistefunktio tuottaisi aina täsmälleen x merkkiä pitkän tiivisteen, tietokannan käyttäjätaulussa kannattaa varata salasanatiivisteelle aina turhaa tilaa Esimerkiksi tiiviste on 60 merkkiä ja kenttä on 255 merkkiä Jos (ja kun) funktiot kehittyvät ja vaihtuvat toisiin, tietokantaa ei tarvitse muuttaa, riittää, että tiivisteet lasketaan uudestaan

32 Lisätään käyttäjätilit 32

33 Siivotaan koodia hieman 33 Nyt kontrollerimetodit vastaavat näkymien lataamisesta Lisätään globaali näkymänlatausfunktio Luodaan tiedosto core/helpers.php, johon voidaan sijoittaa apufunktioita Koska nämä eivät ole luokkia, täytyy määrittää niiden autoload erikseen composer.json - tiedostoon

34 Apufunktio näkymän lataamiselle 34 Funktiolle annetaan näkymän nimi ja mahdolliset muuttujat, jotka halutaan tuoda tämän tietoon Compact ja extract funktiot Compact( myvar ) == [ myvar => $myvar] Extract($data) --> $myvar Voidaan paketoida muuttujat yhteen taulukkoon, muuttujan nimi ei vaihdu, vaikka funktio ottaakin vastaan tiedon muuttujassa $data

35 Käyttäjät -taulu 35 Luodaan käyttäjiä varten users taulu tietokantaan PostgreSQL: vaihda auto_increment => serial

36 Lisätään vaaditut reitit 36 GET /register = näytä lomake POST /register = käsittele lomakkeen tiedot

37 Lisätään lomake rekisteröitymiselle 37 Kolme kenttää: Name Password Lomake tekee POST pyynnön /register -reittiin

38 TLS/SSL l. HTTPS 38 Nyt pyynnön osana on POST muuttujassa sähköpostiosoite ja salasana (i.e. Sensitiivistä dataa) On siis meidän vastuullamme pitää huoli siitä, etteivät tiedot vuoda Avoimessa verkossa salaamattomilla yhteyksillä kaikki samassa verkossa olevat voivat tarkastella pyyntöjä On kehittäjän vastuulla pitää huoli siitä, että tällainen data siirtyy vain TLS salatussa yhteydessä (eli Mutta enää tänä päivänä ei ole varsin perusteita olla käyttämättä TLS:ää kaikessa tiedonsiirrossa, vaikka meillä ei olisikaan mitään sensitiivistä dataa Esim. Google haku sijoittaa salattua yhteyttä käyttävät sivut ylemmäs tuloksissa

39 Käyttäjän tallentaminen 39 Käyttäjä voitaisiin nyt tallentaa perimällä Model luokasta uusi User luokka Mutta mitä jos käyttäjä ei antanut tietoja? Mitä jos kentät olivat tyhjiä? Tarvitaan validaattori, jolle voidaan antaa validointisääntöjä ja joka kertoo, olivatko syötteet kelvollisia TIETA A.S.

40 40 Yksinkertainen validaattori Luodaan Core/Validator.php ja lisätään sinne validaattoriluokka Validaattori hakee DiC:sta pyynnön parametrit ja saa rakentajansa kautta assosiatiivisen taulukon kentän_nimi => sääntö Jos annettu ehto ei täyty annetulla kentällä, lisätään virheviesti $errors -muuttujaan, jonka validaattori palauttaa TIETA A.S.

41 41 Validator ->validate() Käydään läpi taulukko ja kutsutaan annetulle kentälle sille annetun säännön nimistä metodia, jos sellainen on määritetty validaattori-luokalle Validate() metodi palauttaa mahdolliset validointivirheet takaisin kutsuvalle metodille TIETA A.S.

42 Yksinkertainen sääntö 42 Jos sääntö ei mene läpi, lisätään virhetauluun uusi virheilmoitus Kukin sääntö tarkastelee kenttää jollain tavalla ja lisää haluamansa virheilmoituksen, jos tarpeen

43 Lisätään validointi tallennukseen 43 Jos validointi tuottaa yhtään virhettä, palataan lomakkeelle virheilmoitusten kera Muussa tapauksessa voidaan tallentaa tieto Kuvassa tallennusreitti palauttaa lomakkeen Tämä rikkoo SRP:tä Oikeampi tapa olisi kirjoittaa virheet istuntoon ja toteuttaa uudelleenohjaus, kuten aiemminkin Mutta tämä mahtui paremmin kuvaan

44 Lisätään virheilmoitukset lomakkeelle 44

45 Validaattorin jatkaminen 45 Nyt jos haluttaisiin yhdelle kentälle useampi sääntö, tulisi määrittää jokainen omaksi rivikseen => required => valid => unique Voitaisiin sopia säännön nimeen konventio, joka ketjuttaa samaan merkkijonoon useita metodeja => required valid unique Ja voitaisiin sopia konventio, jolla metodille voitaisiin antaa parametreja Name => required min:10 max:150 Validator->validate() tulkitsisi tämän esim. $methods = explode(, $rule)

46 Valmiit validointisäännöt 46 Useat arvot validoidaan aina samalla tavalla Esimerkiksi sähköpostiosoite on aina saman säännön mukainen, mutta sääntö on yllättävän monimutkainen Tällaisissa yleisissä tapauksissa on onneksi valmiita toteutuksia Filter_var($var, FLAGS); palauttaa joko $var tai FALSE, jos validointi epäonnistuu Tässä oletettiin, että arvon puuttuminen on aiemmalla säännöllä tarkistettu TIETA A.S.

47 Valmiit validaattorit 47 Validointi on tärkeä osa sovellusta Se on siis myös yleinen ongelma, johon moni muukin on miettinyt ratkaisua Valmiita validointikomponentteja packagist.org:sta Respect/validation Aura/filter Symfony/validator

48 Sisäänkirjautuminen 48 Sisäänkirjautuminen onnistuu JOSS tietokannasta löytyy käyttäjä annetulla sähköpostiosoitteelle JA löydetyn käyttäjän salasanan tiiviste menee läpi password_verify funktiosta annetulla salasanalla Siinä tapauksessa merkataan istuntoon jotain, millä voidaan tunnistaa käyttäjä

49 Kontrollerilla on liikaa vastuuta 49 Kontrollerin ei pitäisi joutua kirjoittamaan SQL komentoja Siirretään vastuu tietomalliluokalle Lisätään Model luokalle findwhere($field, $value) metodi Nyt Model luokalla on kaksi metodia, jotka palauttavat yhden rivin eri ehdoilla Pitäisi kirjoittaa find($id tai $ehtoja) metodi, jolle voisi antaa joko id:n tai assosiatiivisen taulukon ehtoja TIETA A.S.

50 Uloskirjautuminen 50 Uloskirjautumisessa poistetaan istunnosta käyttäjään viittaavat tiedot ja tuhotaan istunto Jälleen, näkymän lataaminen tässä reitissä ei ole järkevää, vaan tulisi toteuttaa uudelleenohjauksella

51 Käyttöoikeuden tarkistaminen 51 Jos järjestelmä on niin yksinkertainen, että käyttöoikeus riippuu siitä, onko käyttäjä kirjautuneena, voidaan esimerkiksi uuden taskin luontiin liittää hyvin yksinkertainen suojaus Useimmiten eri oikeuksia halutaan kuitenkin useampia Käyttäjällä tietokannassa käyttäjätaso (admin, editor, moderator, ) Roolit ja oikeudet: käyttäjällä on rooleja, rooleilla on oikeuksia Tarkistetaan, onko käyttäjä roolissa, jolla on oikeus muokata tietoja TIETA A.S.

52 Käyttöoikeuden tarkistamisesta 52 Pelkkä kirjautuminen harvoin riittää, tarvitaan eritasoisia käyttäjiä Kaksi yleistä tapaa: ACL ja RBAC Access controll list Käyttäjä id: 1, ryhmä id: 1 JOS resurssi->omistaja == 1 tai resurssi->ryhmä == 1 Aivan kuten Unix pohjaisissa käyttöjärjestelmissä rwxrwxrwx Role-based access controll Onko käyttäjällä X rooli Y jolla on oikeus toimintoon Z Kaikki roolissa 1 saavat tehdä A ja B, kaikki roolissa 2 saavat tehdä C ja D Käyttäjällä voi olla useita rooleja Helppo lisätä rooleja, helppo antaa tai poistaa käyttäjän rooleja Voidaan tarkkaan määritellä kaikki, mutta johtaa helposti todella monimutkaiseen hallintaan, jos toimintoja on satoja

53 Käyttöoikeuksista 53 Meillä on yleensä jokin pääkäyttäjä, jolla on kaikki oikeudet Tavallisella kirjautuneella käyttäjällä tulee usein olla oikeus muuttaa omia tietojaan, mutta ei toisen kirjautuneen käyttäjän tietoja ACL:n tapauksessa meillä voisi olla normaali käyttäjä, editori ja admin, joilla kaikilla olisi hieman edellistä enemmän oikeuksia Mutta usein on tarve määritellä tarkasti tarpeen mukaan tietylle käyttäjälle tietty oikeus Tällöin voidaan lisätä kullekin käyttäjälle 1-* (one-to-many) relaatio oikeuksiin Mutta sitten pitäisi käsitellä kunkin yksittäisen käyttäjän oikeuksia käyttäjä kerrallaan Laajemmissa kokonaisuuksissa onkin usein järkevää käyttää RBAC toteutusta, jolloin voidaan käsitellä kokonaisia käyttäjäryhmiä

54 Lisää luettavaa 54 Lyhyt kirja tämän luennon aiheista, mutta hieman laajemmalla taustoituksella. Esimerkit PHP kielellä. Ben Edmunds, Securing PHP Apps (Apress, 2016)

55 Kysymyksiä? 55