Tarkoituksena on parantaa php:llä tehdyn asiakasrekisteri-tyyppisen sovelluksen tietoturvaa. MySQL-taulut on nyt tallennettuna palvelimelle selkokielellä joten tietoturvariski on olemassa, vaikka SQL:n salasana onkin palvelimella hyvin suojattuna ja tietysti sovellukseen kirjautumiseen tarvitaan salasana, "käyttöoikeus" tallentuu sessioniin. Datan liikkuminen verkossa selväkielisenä on riski. Sovellusta kuitenkin pitää päästä käyttämään periaatteessa miltä tahansa netissä olevalta koneelta, mutta siis vain valtuutettujen ihmisten!!!
Sen kummemmin asioita tuntematta ajattelin ratkaisuksi jotakin sellaista että MySQL:ssä data on kryptattuna ja kun miltä tahansa koneelta käytetään sovellusta nettiselaimella, tapahtuu tiedon muunto selkokieliseksi selainkoneella esimerkiksi Javascriptillä, jolle annetaan salasana. Jotakin tämän tapaisia scriptejä löytyi helposti googlettamalla - niissä tosin tekstit olivat html-muodossa mutta. Vastaavasti käsitelty data tallennetaan palvelimelle kryptattuna paikallisesti syötetyllä salasanalla. En tiedä voiko Javascriptissä tallentaa jotakin pidemmäksi aikaa kun ei salasanaa viitsisi joka välissä syöttää, mielessä kävi tallentaa sessionilla php:lla.
Mielessä kävi myös että pitäisiköhän tällaisessa käyttää Javaa Javascriptin asemesta - kokemusta Javasta ei kyllä ole.
Osaakos joku fiksu kommentoida jotakin asiasta ennen kuin rupean virittelemään systeemiä? PHP:n laajuus - kuinka yhdellä käskyllä tehdään ihmeitä ja kaikenmaailman lisäkirjastot päälle - ei lakkaa hämmmästyttämästä mutta ilmeisesti sieltä ei ainakaan tähän löydy apuja.
Jos tarvitset tietoturvaa nimenomaan verkkoliikenteen tasolla, pystytä HTTPS-palvelin ja homma on sillä selvä. Mitään omia salausviritelmiä ei kannata tehdä, koska viisaammat ovat jo tehneet parempia.
Toki salaus (tai ensisijaisesti sen purku) on mahdollista toteuttaa myös JS:llä, jos ihan välttämättä haluat. Silloin pitää myös muuntaa kaikki sivuston linkit ja lomakkeet toimimaan JS:llä niin, että linkistä ei mennäkään uudelle sivulle vaan kutsutaan JS-funktiota, joka lataa uuden sivun, purkaa salauksen ja korvaa vanhan sisällön uudella. Mutta kun kerran asiaa noin kysyit, luultavasti vaiva on turhan suuri ja bugit moninaiset.
Verkkoliikennettä enemmän olisin kuitenkin huolissani palvelun muusta tietoturvasta, erityisesti SQL-injektioiden mahdollisuudesta.
Metabolix kirjoitti:
Mitään omia salausviritelmiä ei kannata tehdä, koska viisaammat ovat jo tehneet parempia.
Tämä on tietoturvallisuuden raamatun ensimmäinen laki.
Metabolix kirjoitti:
Jos tarvitset tietoturvaa nimenomaan verkkoliikenteen tasolla, pystytä HTTPS-palvelin ja homma on sillä selvä. Mitään omia salausviritelmiä ei kannata tehdä, koska viisaammat ovat jo tehneet parempia.
Toki salaus (tai ensisijaisesti sen purku) on mahdollista toteuttaa myös JS:llä, jos ihan välttämättä haluat. Silloin pitää myös muuntaa kaikki sivuston linkit ja lomakkeet toimimaan JS:llä niin, että linkistä ei mennäkään uudelle sivulle vaan kutsutaan JS-funktiota, joka lataa uuden sivun, purkaa salauksen ja korvaa vanhan sisällön uudella. Mutta kun kerran asiaa noin kysyit, luultavasti vaiva on turhan suuri ja bugit moninaiset.
Verkkoliikennettä enemmän olisin kuitenkin huolissani palvelun muusta tietoturvasta, erityisesti SQL-injektioiden mahdollisuudesta.
Hyviä kommentteja!
En ehkä tarpeeksi selkeästi tuonut esille että yksi huolenaihe on sql-käyttäjätunnuksen ja salasanan joutuminen vääriin käsiin. Tauluissa data on salaamatonta. Tunnukset kyllä haetaan includella www-sivujen "ulkopuolelta" kuten taisi täällä olla neuvottu suojaamaan ne. Mutta onhan tunnukset selväkielisenä kuitenkin esimerkiksi omalla työkoneellani (jossa alkuperäiset php:t) ja onhan mahdollista tietovuodot jopa web-hotellifirman päässä. Siksi ajattelin että tauluissa olisi tiedot kryptattuna niin että vaikka joku ulkopuolinen pääsisi niitä katsomaan, ei ainakaan kovin helpolla saisi niitä selkokieliseksi.
Olisiko tähän mitään ideoita?
PHP-koodisi pitäisi pystyä purkamaan salaus. Jos joku varastaa tietokantasi, luultavasti hän varastaa samalla PHP-koodisikin – siis juuri sen, jota itse käytät salauksen purkamiseen. Salauksesta ei siksi ole mitään apua.
Ainoa tapa salauksen hoitamiseen on, että jotain salausavaimista ei ole lainkaan tallennettu levylle, vaan avain syötetään koneelle käsin ja se pysyy vain koneen keskusmuistissa. Käytännössä tähän ratkaisuun sisältyy yleensä koko datalevyn salaus, jolloin edellytyksenä luonnollisesti on oma palvelin. (En tiedä, onko webhotelleissa yleensä tällaista. Voi toki jossain ollakin.)
Koko datalevyn salauksesta palvelimella tuskin on mitään konkreettista hyötyä muussa tilanteessa, kuin että se palvelimen kiintolevy käydään pöllimässä sieltä palvelinhotellista. Siis jos koneelle murtaudutaan systeemien ollessa käynnissä, niin silloinhan se salaus on auki siellä.
slowhand kirjoitti:
Mutta onhan tunnukset selväkielisenä kuitenkin esimerkiksi omalla työkoneellani (jossa alkuperäiset php:t) ja onhan mahdollista tietovuodot jopa web-hotellifirman päässä.
Mitäs jos laittaisit ne kooditiedostot työkoneellasi kryptatulle levylle?
Metabolix kirjoitti:
PHP-koodisi pitäisi pystyä purkamaan salaus. Jos joku varastaa tietokantasi, luultavasti hän varastaa samalla PHP-koodisikin – siis juuri sen, jota itse käytät salauksen purkamiseen. Salauksesta ei siksi ole mitään apua.
Ainoa tapa salauksen hoitamiseen on, että jotain salausavaimista ei ole lainkaan tallennettu levylle, vaan avain syötetään koneelle käsin ja se pysyy vain koneen keskusmuistissa. Käytännössä tähän ratkaisuun sisältyy yleensä koko datalevyn salaus, jolloin edellytyksenä luonnollisesti on oma palvelin. (En tiedä, onko webhotelleissa yleensä tällaista. Voi toki jossain ollakin.)
Jeps juuri tämä olikin idea että kryptauksen salasana syötetään aina käsin eikä sitä tallenneta kooditiedostoihin. Tietysti olisi mahdollista että datan kryptaus ja purku hoidetaan php:lla mutta salasana syötetään selaimesta josta sovellusta käytetään.
Sellainenhan olisi mahdollinen että tekisin sivuille sisäänkirjautumissysteemin jossa kysytään sql:n käyttäjätunnus ja salasana. Eli niitä ei ole tallennettu php-koodiin. Tämä ei kuitenkaan käy mm:
- osan tauluista pitää olla selkokielisiä ja niitä pääsee käyttämään myös "tavalliset käyttäjät" kun php-sovellukset hakevat sieltä dataa, no tietysti olisi mahdollista kiertää tämä kahdella sql-tietokannalla (palvelimella?)
- sql:n tunnukset olisivat myös ainakin web-hotellin tiedossa, ja salasanat ovat kai siellä jossakin tallennettuna, joten sitä kautta vuotoriski
Kaiken datan kryptaukseen perustuvat vaihtoehdot eivät toimi järkevästi, koska silloin kaikilla käyttäjillä pitäisi olla käytössä sama globaali salausavain, mikä ei ole mielekästä tietoturvan kannalta. Sitä paitsi kryptattua dataa ei voi käsitellä tietokannassa järkevästi, joten tietokannan hyödyt käytännössä menetetään. Läpinäkyvä levyn salaus on nähdäkseni ainoa todellinen mahdollisuus.
Kuten Grez totesi, mikään ei suojaa siltä mahdollisuudelta, että joku onnistuisi kirjautumaan koneelle pääkäyttäjänä. (Paitsi salauksen purku JS:llä, mutta siinä on mm. tuo edellä mainittu globaalin salausavaimen ongelma.) Kuitenkin kaikenlaiset sähköpostivaroitukset vääristä salasanoista ym. vähentävät koneelle murtautumisen todennäköisyyttä, joten ei se levyn salaaminenkaan ihan turha juttu ole.
Jos nyt vain lopettaisit sen kikkailun ja korjaisit edes tavalliset tietoturva-aukot. Jotenkin tästä hommasta jää sellainen tuntuma, että niitäkin on varmaan ihan tarpeeksi.
Jos webhotellin epärehellisyys tai turvattomuus oikeasti painaa mieltäsi noin paljon, osta oma palvelin, oma UPS, oma palvelinlaajakaista ja omat valvontalaitteet ja pidä palvelinta kotona.
Metabolix kirjoitti:
Kaiken datan kryptaukseen perustuvat vaihtoehdot eivät toimi järkevästi, koska silloin kaikilla käyttäjillä pitäisi olla käytössä sama globaali salausavain, mikä ei ole mielekästä tietoturvan kannalta. Sitä paitsi kryptattua dataa ei voi käsitellä tietokannassa järkevästi, joten tietokannan hyödyt käytännössä menetetään. Läpinäkyvä levyn salaus on nähdäkseni ainoa todellinen mahdollisuus.
Kuten Grez totesi, mikään ei suojaa siltä mahdollisuudelta, että joku onnistuisi kirjautumaan koneelle pääkäyttäjänä. (Paitsi salauksen purku JS:llä, mutta siinä on mm. tuo edellä mainittu globaalin salausavaimen ongelma.) Kuitenkin kaikenlaiset sähköpostivaroitukset vääristä salasanoista ym. vähentävät koneelle murtautumisen todennäköisyyttä, joten ei se levyn salaaminenkaan ihan turha juttu ole.
Jos nyt vain lopettaisit sen kikkailun ja korjaisit edes tavalliset tietoturva-aukot. Jotenkin tästä hommasta jää sellainen tuntuma, että niitäkin on varmaan ihan tarpeeksi.
Jos webhotellin epärehellisyys tai turvattomuus oikeasti painaa mieltäsi noin paljon, osta oma palvelin, oma UPS, oma palvelinlaajakaista ja omat valvontalaitteet ja pidä palvelinta kotona.
Kaiken datan ei pidäkään olla kaikkien käytössä, muutama taulu erikseen "yleisessä" käytössä. Tietoturva-aukkojen pitäisi kyllä olla suurimmalta osalta tilkitty hyvinkin tarkasti, ja esimerkiksi syötetty data tarkistetaan erittäin huolella ja vain oikeanlaiset syötteet hyväksytään.
Keskustelu alkaa nyt mennä hieman asiattomaksi, ei taida olla faktapohjaa kun arvelet että tavallisia tietoturva-aukkoja olisi paljon? Oma palvelin taisi myös olla "heitto", mutta itse asiassa se on ollut myös yksi vaihtoehto, johon ei ole kuitenkaan ryhdytty. Osin siksi, että palvelin olisi työpaikalla josta välillä pidetään jopa lomaakin.
En voi kertoa tarkemmin millaisesta aineistosta on kyse, mutta ihmisten erittäin henkilökohtaista tietoa, niin että mitenkään liioittelematta todennäköisesti pääsisimme lehtiin mikäli materiaali karkaisi. Tietomurroista kerrotaan vain vähän julkisuuteen, mutta muutamissa tapauksissa on kiinnittänyt huomiota se että esimerkiksi käyttäjätiedot kuten sähköpostit ja salasanatkin ovat olleet tallennettuna selkokielisessä muodossa. Jonkinlaisella kryptauksella olisi edes vähän enemmän vaikeuksia ja työtä hakkerilla.
slowhand kirjoitti:
Tietomurroista kerrotaan vain vähän julkisuuteen, mutta muutamissa tapauksissa on kiinnittänyt huomiota se että esimerkiksi käyttäjätiedot kuten sähköpostit ja salasanatkin ovat olleet tallennettuna selkokielisessä muodossa. Jonkinlaisella kryptauksella olisi edes vähän enemmän vaikeuksia ja työtä hakkerilla.
Lähinnähän noissa uutisoinneissa kritiikki kohdistuu siihen, että salasanat on olleet selväkielisinä, koska niiden ei olisi mitään tarvetta olla selväkielisinä eikä edes kryptattuina. Sähköpostiosoitteita taas järjestelmä tyypillisesti tarvitsee, joten niitä ei voida säilyttää tiivisteinä. Kai sinulla kuitenkin on ne salasanat kannassa riittävän laadukkaasti suojattuina?
slowhand kirjoitti:
Kaiken datan ei pidäkään olla kaikkien käytössä, muutama taulu erikseen "yleisessä" käytössä.
Kyllähän nyt jokaisessa kunnollisessa DBMS:ssä voi määritellä useita käyttäjätunnuksia ja salasanoja niille sekä rajoittaa pääsyn tiettyihin tauluihin vain tietyille käyttäjätunnuksille. Joissakin tietokannoissa on mahdollista tehdä käyttöoikeudet jopa rivikohtaisesti enemmän tai vähemmän helposti. Asiassa, että käyttäjä autentikoisi itsensä tunnuksella ja salasanalla tietokannalle ei siis ole periaatteessa mitään ongelmaa. Itse verkkoliikenteen salaamiseksi kannattaa käyttää sitä HTTPS:ää. Myös tietokannan ja PHP:n välisen liikenteen voi kryptata SSL:llä (tms).
slowhand kirjoitti:
Tietoturva-aukkojen pitäisi kyllä olla suurimmalta osalta tilkitty hyvinkin tarkasti, ja esimerkiksi syötetty data tarkistetaan erittäin huolella ja vain oikeanlaiset syötteet hyväksytään.
Ei millään pahalla, mutta "syötteiden tarkistaminen" kuulostaa pahalta. Oikea tapa olisi käsitellä syötteet. Toki jos tarkoitat sitä että tarkistetaan esimerkiksi onko käyttäjällä oikeasti oikeus lukea tietuetta 73 jos käyttäjän selaimelta tulee id=73, niin se on oikein. Mutta jos syötteistä pyritään tarkistelemaan löytyykö sieltä jotain "drop table" tyylistä, niin ollaan vahvasti WTF-osastolla. Tai no, voihan tuollaistakin tutkia ja raportoida ylläpidolle jos moisia yrityksiä esiintyy, mutta SQL Injektioiden torjuntaan se on väärä(tm) keino.
Myöskin koko tietokannan voi kryptata läpinäkyvästi. Tämä auttaisi tilanteeseen, jossa koko tietokantatiedosto onnistuttaisiin varastamaan, mutta ei kuitenkaan onnistuttaisi varastamaan tietokannan salausavainta. MySQL:ssä tämä ei taida onnistua suoraan, mutta muiden tekemiä ratkaisuja asiaan löytyy, esimerkiksi http://www.gazzang.com/products/ezncrypt-standard-edition
Näissä ratkaisuissa näkisin ongelmaksi sen salausavaimen säilyttämisen. Jos kaikki käyttäjät voidaan olettaa luotetuiksi ja voidaan pakottaa käyttämään riittävän monimutkaisia salasanoja, niin tietokannan salausavaimen voisi tallentaa kunkin käyttäjän salasanalla salattuna.
Mikään edellämainituista ei tietenkään auta jos hyökkääjä pääsee murtautumaan koneelle ja lykkäämään omaa koodiaan PHP:n joukkoon niin, että se vaikka lokittaa tietokanta-avaimen kun joku oikeutettu vierailee palvelussa. Siksi omasta mielestäni nämä salausratkaisut menee vähän "snake-oil" kategoriaan, eli kuvitellaan että kaikki on suojattu vaikka näin ei todellisuudessa olekaan.
slowhand kirjoitti:
Keskustelu alkaa nyt mennä hieman asiattomaksi, ei taida olla faktapohjaa kun arvelet että tavallisia tietoturva-aukkoja olisi paljon?
No vaikka et minulle kommentoinutkaan, niin sen verran täytyy sanoa, että kirjoittamasi perusteella kaikki tietoturvan perusasiat ei ole ihan 100% hallussa, joten ei olisi hirveän suuri yllätys vaikka jotain "tavallisia aukkoja" siellä olisikin. Itse kuvittelisin että jos olisit tietoturva-ammattilainen niin kysymyksesi ja oma pohdintasi olisi hieman eri tasolla. Tämä ei siis millään pahalla - mielestäni tietoturva-asioissa on parempi olla rehellinen kuin kertoa valkoisia valheita ettei vaan pahoittaisi toisen mieltä.
Oletteko auditoineet lähdekoodia jollain tietoturva-ammattilaisella?
slowhand kirjoitti:
Oma palvelin taisi myös olla "heitto", mutta itse asiassa se on ollut myös yksi vaihtoehto, johon ei ole kuitenkaan ryhdytty. Osin siksi, että palvelin olisi työpaikalla josta välillä pidetään jopa lomaakin.
No vähän ristiriitaista sinänsä, kun jossain viestissä et ollut luottamassa hostaajaan. Väittäisin että jos hostaaja oikeasti on epärehellinen niin et pysty tekemään mitään idioottivarmaa suojausta. Vaikka hostaaja olisi 100% luotettava, niin kannattaa myös hostaajan kanssa selvittää päivitysten ajopolitiikka että kaikki komponentit varmasti pysyy ajan tasalla ja se millä tavalla hostaaja suojaa pääsyn palvelimellesi.
Kaiketi parasta aloittaa tuolla aiemmin mainitulla salatun yhteyden käyttöönotolla. Jos käytät self-signed sertifikaattia, sinun täytyy vielä erikseen huolehtia sertifikaatin levittämisestä asiakaskoneille (ennen kuin kyseisiltä koneilta ensimmäistä kertaa kirjaudutaan sovellukseen).
Datan salaaminen palvelinpäässä on kinkkisempi juttu. Kannattaa miettiä mitä tietoja aiot säilyttää salattuna, esim. email-osoitetta tuskin tarvitsee salata? Jos asiakkaista tallennetaan jotain yksittäisiä tietoja (mitkä olisi syytä säilyttää salattuna), niin lienee järkevintä tallentaa nämä tiedot yhteen paikkaan kyseiselle käyttäjälle (esim. omalle rivilleen tietokantatauluun, mahdollisesti serialisoituna arrayna tjms) ja salata käyttäen avainta mikä johdetaan käyttäjän sisäänkirjaustiedoista. Näin tiedot tulevat vain käyttöön kyseiselle käyttäjälle. Suunnittele tarkkaan tarvitseeko "juuri tätä" tietoa todellisuudessa tallentaa järjestelmään.
Asioita monimutkaistaa jos esim. ylläpidon pitäisi päästä näihin asiakkaan salattuihin tietoihin käsiksi. Tosin jos suunnittelet systeemin joustavaksi, voi olla että ylläpidonkaan ei tarvitse päästä kaikkeen salattuun käsiksi kokonaisuudessaan. Vaikea sanoa tarkemmin tuntematta enempää järjestelmääsi.
Oman webhostauksen pystyttäminen on 99,9 prosentin varmuudella ojaan ajoa. Tärkeämpää on valita hostaajaksi luotettu taho, mielellään sellainen minkä järjestelmissä data pysyy fyysisesti Suomen rajojen sisäpuolella. Vrt esim. Amazonin pilvipalvelut, mistä datasi mahdollisesti voidaan luovuttaa USA:n erinäisille virastoille (jos heidän mielestään siihen on riittävän hyvä syy).
Ja tosiaan vielä lopuksi, lähdekoodin auditointi mitä luultavimmin paljastaisi ainakin jonkinasteista korjattavaa/parannettavaa. Toki riippuen sovelluksen koosta (enemmän koodia = enemmän tilaa virheille). Myös mahdolliset "arkkitehtuuriset suunnitteluvirheet" jäävät haaviin luultavimmin, jos muutkin auditoivat sovellusta kuin pelkästään sovelluksen kehittäjät.
Kiitoksia hyvistä kommenteista ja katselen kyllä tuleeko tänne vielä lisää keskustelua aiheesta. Tarkennuksia / kommentteja: Salattava tieto on vapaamuotoista tekstiä sekä nimi/osoite-tietoja, jota järjestelmän ylläpitäjän (minun) pitää päästä tarvittaessa käyttämään miltä tahansa koneelta, joten kaiken pitää olla kyllä palvelimella, ei localina. Ylläpidon yksi tehtävä on käsitellä tätä salattua aineistoa ja sen jälkeen "painaa nappia", jolloin salatusta aineistosta tehdään päivitys "yleisölle avoimeen tauluun" josta kuka tahansa sivulla käyvä käyttäjä saa tietoja (ei siis tietenkään hae itse tietokannasta vaan php noutaa tietoja ja suoltaa html:ää sen mukaan).
Meni vähän semanttiseksi saivarteluksi syötteiden ja tietojen tarkistelu, mutta tarkoitan siis esimerkiksi että kun lomakkeella annetaan vaikka postinumero, se tarkistetaan myös php:lla ja niin, että postinumeroksi hyväksytään vain data jossa on viisi numeroa. Jos siellä on mitä tahansa muuta kuin numeroita, ei hyväksytä. Vastaavasti esimerkiksi nimissä ei hyväksytä mitään muuta kuin aakkosia. Kaikki heittomerkit, & ja muut temput käskevät korjata syötteet tai tarpeeksi monta kertaa yritettynä päättyy die:llä tyhjään sivuun. Palvelimella on myös asetukset mm niin ettei php-virheilmoituksia näytetä jne jne jne. Mahdollisesti joku asiantuntija voisi löytää sieltä jotakin, mutta tämä nyt on tietysti myös taloudellinen kustannuskysymys.
Täällä on myös esitetty kommentteja mikä on suurempi ja mikä pienempi tietoturvauhka. Turvallisuutta parantaakseni en voi kuitenkaan ajatella niin; vaikka riski että joku onnistuu saamaan sql:n tunnukset käsiinsä ja lukemaan taulusta selkokieliset tekstit on pieni, se on kuitenkin olemassa. On ehkä vainoharhaisuutta ajatella näin, mutta mietitäänpä nyt vaikka Soneran urkintajuttua - teleoperaattori seurasi mitä henkilökunta ja toimittajat viestittivät Soneralle epämiellyttävistä asioista. Kun minulla on salasana omassa päässä niin tiedän että sitä ei voi kovin helposti varastaa, mutta jos salasana on operaattorilla, on se kuitenkin MAHDOLLISTA viedä sieltä, enkä minä voi olla 100% varma että se pysyy siellä, enkä edes voi tietää onko salasana viety sieltä. Onhan tietysti mahdollista varastaa sekä sql:n tunnukset ja lisäksi "ulkopuolinen" kryptausavain, mutta ainakin se on huomattavasti työläämpää ja vaatii suunnittelua, kun taas sql-tunnukset joku voisi saada tai löytää puolivahingossa ja yllättyä kun menee katsomaan mitä sieltä löytyy.
slowhand kirjoitti:
Meni vähän semanttiseksi saivarteluksi syötteiden ja tietojen tarkistelu, mutta tarkoitan siis esimerkiksi että kun lomakkeella annetaan vaikka postinumero, se tarkistetaan myös php:lla ja niin, että postinumeroksi hyväksytään vain data jossa on viisi numeroa. Jos siellä on mitä tahansa muuta kuin numeroita, ei hyväksytä. Vastaavasti esimerkiksi nimissä ei hyväksytä mitään muuta kuin aakkosia. Kaikki heittomerkit, & ja muut temput käskevät korjata syötteet tai tarpeeksi monta kertaa yritettynä päättyy die:llä tyhjään sivuun.
No sinänsä kyse ei ole saivartelusta, että ainakin alkuperäisessä viestissä tarjosit syötteiden tarkistamista tietoturvaa edistäväksi asiaksi. Nuo mainitsemasi asiat ei liity tietoturvaan ja jos miellät rakentavasi tuolla tavalla parempaa tietoturvaa, niin olet valitettavasti hakoteillä.
slowhand kirjoitti:
Täällä on myös esitetty kommentteja mikä on suurempi ja mikä pienempi tietoturvauhka.
Niin no pointtihan on se, että jos on käytettävissä aikaa x tuntia ja siinä ajassa saadaan korjattua joko hyvin vaikeasti hyödynnettävä aukko tai jokaisen skript-kiddien läpäisevä aukko, niin kumpi omasta mielestäsi kannattaa paikata?
Toisaalta olet kyllä oikeassa siinä että jos tiedossa on vaikeasti hyödynnettävä aukko ja se olisi paikattavissa kohtuullisella vaivalla eikä ole mitään kriittisempää tiedossa tai selvitettävissä, niin tokihan se kannattaa korjata. Korjauksen pitäisi kuitenkin olla sellainen, että se oikeasti torjuu uhan.
slowhand kirjoitti:
Turvallisuutta parantaakseni en voi kuitenkaan ajatella niin; vaikka riski että joku onnistuu saamaan sql:n tunnukset käsiinsä ja lukemaan taulusta selkokieliset tekstit on pieni, se on kuitenkin olemassa.
Mielestäni tuon asian suhteen oli pikemminkin kyse siitä että niitä ei välttämättä millään toteutuskelpoisella keinolla ole muuttaa sellaisiksi, että ne käytännössä olisi vaikeampi saada. En oikein näe miksi B olisi parempi seuraavista skenaarioista:
A) pahis saa käsiinsä tietokannan tunnukset ja pääsee lukemaan selväkieliset tekstit
B) pahis saa käsiinsä tietokannan tunnukset ja salausavaimen ja pääsee dekryptaamaan ja lukemaan tekstit
slowhand kirjoitti:
Kun minulla on salasana omassa päässä niin tiedän että sitä ei voi kovin helposti varastaa
Ja olet väärässä. Eli kuten aikaisemminkin sanoin niin kyse on ns. "snake oil" -ratkaisusta. Luulet että asia on paremmin vaikka se ei oikeasti ole ja tästä harhaluulosta on todellisuudessa haittaa. Vähän sama kuin syövän hoito homeopatialla.
slowhand kirjoitti:
Onhan tietysti mahdollista varastaa sekä sql:n tunnukset ja lisäksi "ulkopuolinen" kryptausavain, mutta ainakin se on huomattavasti työläämpää ja vaatii suunnittelua, kun taas sql-tunnukset joku voisi saada tai löytää puolivahingossa ja yllättyä kun menee katsomaan mitä sieltä löytyy.
No, ihan konkreettisesti ero on 5 minuuttia vs. 15 minuuttia. Jos olisin hostaajana päättänyt väärinkäyttää asemaani riskeeraten asiakassuhteen sekä maineeni, niin luuletko tosiaan että ylimääräinen 10 minuuttia vainvannäköä saisi minut luovuttamaan?
Se hyvä puoli tuossa kuitenkin on että jos varmuuskopiot tai fyysinen palvelin jossain vaiheessa joutuvat vääriin käsiin (esim. varastetaan) niin niitä ei saa auki kun avainta ei ole talletettu mihinkään. Lisäksi jos esimerkiksi olet virtuaalipalvelimella ja virtualisoinnissa on tietoturvaongelma joka mahdollistaa sinun osioosi pääsyn jollekin epärehelliselle, niin silloinhan tuosta on ihan oikeasti apua.
Eli en missään tapauksessa sano etteikö vain muistissa säilyvän kryptausavaimen käytöstä ole hyötyä, mutta on silti parempi tietää mihin riskeihin se auttaa ja mihin ei.
Grez vastasikin jo useimpiin asioihin hyvin, joten en ota enää niihin kantaa.
Tuo tarkistamisesi kuulostaa olevan suurelta osin juuri sitä, mitä Grez pahoin pelkäsi. On toki hyvä kertoa käyttäjälle, jos syöte on väärässä muodossa, mutta lisäksi pitää käsitellä syötettä niin, että vahinkoa ei tapahdu, vaikka tarkistus pettäisi tai joku muuttaisi tarkistusta.
slowhand kirjoitti:
Vastaavasti esimerkiksi nimissä ei hyväksytä mitään muuta kuin aakkosia. Kaikki heittomerkit, & ja muut temput käskevät korjata syötteet tai tarpeeksi monta kertaa yritettynä päättyy die:llä tyhjään sivuun.
Hylkäätkö siis myös nimet "Anna-Liisa" (sisältää viivan), "Castrén" (sisältää erikoismerkin), "af Hällström" (alkaa pienellä ja sisältää välilyönnin) ja "O'Brien" (sisältää heittomerkin)? Vastaavia löytyy Suomesta huomattava määrä.
slowhand kirjoitti:
Palvelimella on myös asetukset mm niin ettei php-virheilmoituksia näytetä jne jne jne.
Mutta kai olet kehitysvaiheessa pitänyt näkyvissä kaiken, myös varoitukset ja huomautukset? Luottaisin tietoturvan puolesta enemmän systeemiin, jossa kaikki mahdolliset ilmoitukset ovat julkisesti esillä, kuin systeemiin, jossa niitä ei ole viitsitty katsoakaan.
Niin noista virheistä vielä, että kai kuitenkin lokitat ne ja seuraat lokia säännöllisesti? Tai sama tietty jos ne tulee sulle sähköpostilla tms.
Jos palveluntarjoajaan ei voi luottaa, vaihtoehtoja ei taida jäädä muita kuin että asiakaspäässä salaat datan symmetrisellä salauksella (satunnaisesti luodulla avaimella) ja tämän avaimen clientti salaa sinun omalla julkisella avaimella (public-key salaus). Tämän rimpsun (salatun datan ja salatun avaimen) sitten clientti lähettää palvelimelle ja itse saat purettua datan avaamalla omalla privaatilla avaimellasi sen "salausavaimen" ja käyttäen tätä avainta sitten purat varsinaisen datan auki.
Tällaiseen tarkoitukseen webbiselain ei enää ole omiaan. Joten joutunet tekemään client-softan jotain muuta kautta.
Jos salausta ei tehdä jo clientin puolella (ja purkua sinun puolella), et voi käytännössä kaiketi mitenkään "täysin varmasti" estää etteikö vihamielinen palveluntarjoaja pääsisi halutessaan käsiksi dataan.
Jos palveluntarjoajaan ei voi luottaa, niin sitten olisi pitänyt halvimman sijaan ottaa joku parempi.
Tuo on hieman kinkkistä. Voi olla tilanteita että luottaminen palveluntarjoajaan on yksi ns. "turha lisärasite". Siihen että onko se tässä slowhandin tapauksessa sitä, en ota kantaa.
Yleisesti ottaen tuollaisista asioista ei murehdita (luotettavien palveluntarjoajien kanssa), mutta näin nyanssina se jokatapauksessa lisää pinta-alaa mitä vastaan "voidaan hyökätä / mistä potentiaalisesti voi aiheutua harmia".
timoh kirjoitti:
Yleisesti ottaen tuollaisista asioista ei murehdita (luotettavien palveluntarjoajien kanssa), mutta näin nyanssina se jokatapauksessa lisää pinta-alaa mitä vastaan "voidaan hyökätä / mistä potentiaalisesti voi aiheutua harmia".
Väärin. Ei yksin voi toimia jokapaikan höylänä ja olettaa saavansa yhtä hyvän tuloksen kuin eri alojen ammattilaiset yhteensä. Jos aikoo päivät käyttää tietoturvauutisten pläräämiseen ja servun virittelyyn, niin sitten jää koodaus tekemättä tai tulee hutiloitua.
Kotiservu parimegaisen kaistan päässä on myös aina suurempi tietoturvariski kuin kunnon klusteri (moni)gigaisella verkkoyhteydellä. 4chanin teiniarmadat ovat suurempiakin palveluita kellistäneet.
Sovellusten kehitystyö on tehty pitkälti omalla "serverillä" joka ei ole netissä kiinni ollenkaan, silloin tietysti virheilmoituksia näytetään. Web-hotellissa ei näy, joten muutaman kerran onkin ollut työlästä pienen koodimuutoksen jälkeen löytää mistä se ; tai } puuttuu....
Nimissä tosiaan sallitaan -, mutta tosiaan esimerkiksi aksenttimerkit ja heittomerkin olen jättänyt sieltä pois. Näin on yllättävän monissa rekisterissä, jotta nimiä ei voisi kirjoittaa liian monella eri tavalla, ja monesti käytetään vain versaaleja (suuraakkosia). Kysykääpä joltakin O'Brienilta kuinka monessa rekisterissä hän on OBRIEN. Tosin asiakasrekisterissä harvemmin haetaan mitään suoraan nimellä, vaan postinrolla ja katuosoitteella. Nämä alkaa mennä vähän detaljipuolelle.
Vääriä arvoja ei tietenkään toisteta ruudulle, vaan kaikki virheilmoitukset ovat vakiotekstejä. Minun mielestä netistä löytyy hyvin tietoturvavinkkejä, tietysti pahat on aina edellä, mutta kuitenkin.
Minusta ei ole realismia luottaa sokeasti palvelutarjoajaan. Oli se pieni tai iso firma, yhden miehen tai 5000 hengen firma, kaikissa on riskinsä. Tietysti joku palvelutarjoajan työntekijä voisi katsoa taulukoita. Yhtä lailla on mahdollista että sql-tunnukset (vaikka kaikkien asiakkaiden) joutuvat ulos firmasta vaikka väärään roskikseen heitetyssä paperissa tai kiintolevyllä. Niin eihän tällaisia pitäisi käydä, mutta se jonka mielestä niin ei voi käydä, suosittelen tutustumista Murphyn lakeihin. Ihmisiä kaikki ollaan, virheitä sattuu, huolimattomuutta ja ajattelemattomuutta. Arkaluontoisia tietoja kuten potilasasiakirjoja löytyy roskalavoilta. Monista tietovuodoista selviää, mutta on olemassa myös sellaisia tietoja ja palveluita että niiden päästyä julkiseksi täytyykin vaihtaa henkilöllisyys ja ala.....
slowhand kirjoitti:
joten muutaman kerran onkin ollut työlästä pienen koodimuutoksen jälkeen löytää mistä se ; tai } puuttuu....
Köh. Virheiden lokittaminen... Köh.
slowhand kirjoitti:
Nimissä tosiaan sallitaan -, mutta tosiaan esimerkiksi aksenttimerkit ja heittomerkin olen jättänyt sieltä pois.
Onko tähän jokin syy? Tietoturva ei ole mikään validi syy, koska niiden pois jättö ei lisää tietoturvaa.
slowhand kirjoitti:
Näin on yllättävän monissa rekisterissä, jotta nimiä ei voisi kirjoittaa liian monella eri tavalla, ja monesti käytetään vain versaaleja (suuraakkosia). Kysykääpä joltakin O'Brienilta kuinka monessa rekisterissä hän on OBRIEN.
[rant]Mielestäni järjestelmästä ei kannata tehdä paskaa ihan vaan sen takia että muutkin järjestelmät on paskoja. Joissakin järjestlemissä toki kelpaa vain 7-bittiset merkit sen takia kun ne taustalla toimivat systeemit joihin järjestelmät kytkeytyy on tehty joskus 1970 -luvulla. Jos tehdään kokonaan uutta järjestelmää 2010 -luvulla, niin minusta ei ole syytä käyttää 1970-luvun tekniikan rajoituksia.[/rant]
Olennainen pointti kuitenkin on edelleen se, että jos tietoturva on tehty oikein, niin syötteiden rajoittaminen tuolla tavalla ei lisää tietoturvaa.
slowhand kirjoitti:
Minun mielestä netistä löytyy hyvin tietoturvavinkkejä, tietysti pahat on aina edellä, mutta kuitenkin.
En nyt näe miten pahat on edellä, jos puhutaan koodin kirjoittamisesta. Ei siellä sun koodissa ole tietoturva-aukkoa ennen itse teet sen, joten miten "pahis" voisi olla edellä? Jos tarkoitat alustojen (PHP, MySQL tms) tietoturva-aukkoja, niin harvoin niitä kannattaa lähteä kiertämään omassa koodissa, kun yleensä siinä vaiheessa kun niistä on tieto, tulee korjaus ennen kuin ehtisi tehdä omaa toimivaa workaroundia.
slowhand kirjoitti:
Minusta ei ole realismia luottaa sokeasti palvelutarjoajaan.
Jos et voi luottaa palveluntarjoajaan niin sitten joudut todennäköisesti pistämään sen oman palvelimen pystyyn. Kuten jo sanoin niin inhimillisten virheiden varalta vain muistissa säilytettävä salasana ei ole huono asia, mutta jos palveluntarjoaja on oikeasti pahantahtoinen niin mikään 10 minuutin lisävaiva ei sitä pidättele.
The Alchemist kirjoitti:
Väärin. Ei yksin voi toimia jokapaikan höylänä ja olettaa saavansa yhtä hyvän tuloksen kuin eri alojen ammattilaiset yhteensä. Jos aikoo päivät käyttää tietoturvauutisten pläräämiseen ja servun virittelyyn, niin sitten jää koodaus tekemättä tai tulee hutiloitua.
Pointtini kaiketi hukkui matkalle. Tarkoitin että jos data on paikassa A (olkoon se sitten esim. mikä vaan webhost, Mähösen kellari jne), niin jos data saadaan purettua kaappaamalla kone/kuuntelemalla nettiliikennettä tjms, niin hyökkääjällä on enemmän "pinta-alaa" mitä vastaan hyökätä. Tietysti tämän "pinta-alan" laatuun vaikuttaa suuresti se että onko kyseessä kunnolla hoidettu hostausinfrastruktuuri, vai se Mähösen silloin tällöin päivittämä kellarin Pena. Mutta joka tapauksessa sitä pinta-alaa on enemmän.
Jos taas data on salattu palvelimesta riippumattomasti, niin vaikka hyökkääjä ottaisikin palvelimen haltuun, hän ei suoraan pysty silti purkamaan dataa (edes silloin kun käyttäjät kirjautuvat palveluun), koska data on jo salattu valmiiksi clientin puolella. Tätä tarkoitin tällä että hyökkääjällä on enemmän "pinta-alaa mitä vastaan voidaan hyökätä". Tietysti hyökkääjä voi alkaa hyökkäämään konkreettisesti sitä salattua dataa vastaan (minkä hän saa kun ottaa palvelimen haltuunsa), mutta tämä menee jo toisen aiheen puolelle.
timoh kirjoitti:
The Alchemist kirjoitti:
Väärin. Ei yksin voi toimia jokapaikan höylänä ja olettaa saavansa yhtä hyvän tuloksen kuin eri alojen ammattilaiset yhteensä. Jos aikoo päivät käyttää tietoturvauutisten pläräämiseen ja servun virittelyyn, niin sitten jää koodaus tekemättä tai tulee hutiloitua.
Pointtini kaiketi hukkui matkalle. Tarkoitin että jos data on paikassa A (olkoon se sitten esim. mikä vaan webhost, Mähösen kellari jne), niin jos data saadaan purettua kaappaamalla kone/kuuntelemalla nettiliikennettä tjms, niin hyökkääjällä on enemmän "pinta-alaa" mitä vastaan hyökätä. Tietysti tämän "pinta-alan" laatuun vaikuttaa suuresti se että onko kyseessä kunnolla hoidettu hostausinfrastruktuuri, vai se Mähösen silloin tällöin päivittämä kellarin Pena. Mutta joka tapauksessa sitä pinta-alaa on enemmän.
Eihän tällä selitysyritys B:llä ole mitään tekemistä sen kanssa, käyttääkö erillistä palveluntarjoajaa vai kotikutoista palvelinta. Aivan sama missä se palvelin sijaitsee, uhat ovat silti samat salausta käyttäville kuten myös niille, jotka eivät käytä salausta.
Siis se ero on siinä (mistä aiemmin tähän ketjuun kirjoitin), että jos data on palvelimella valmiiksi salattuna (data on salattu jo ennen kuin se ikinä saapuukaan palvelimelle), niin hyökkääjälle ei riitä vaikka hän ottaisi koko palvelimen ja palvelimen verkkoliikenteen haltuunsa, koska hänen silti täytyisi murtaa se clientin luoma salaus.
Vertaa tätä siihen, että data salataan siellä palvelimella (mahdollisesti käyttäen clientin lähettämiä tietoja). Tämä tarkoittaa sitä että jos hyökkääjä ottaa palvelimen ja palvelimen verkkoliikenteen haltuunsa, niin hän pääsee käsiksi plaintextiin siltä istumalta (ainakin kun clientit kirjautuvat tjms. palveluun). Ero on huomattava, eikö?
Kun kirjoitit että "uhat ovat silti samat salausta käyttäville kuten myös niille, jotka eivät käytä salausta", niin juuri tässä tullaan siihen oleelliseen pointtiin. Eli siihen, _missä_ se salaus suoritetaan.
Siitä tosin tulee tiettyjä haittoja jos palvelin ei osaa/voi purkaa salausta. Esimerkiksi tietokannasta ei voida hakea vain tiettyjä tietoja jonkin rajauksen mukaan vaan joudutaan lähettämään koko salattu tietomassa clientille joka sitten purkaa salauksen ja suorittaa rajaukseen sopivien tietojen poiminnan. Toki tähän voisi olla ratkaisu laittaa jotkin vähemmänsensitiiviset sarakkeet tai vaikka sarakkeen alun selväkielisenä, jolloin niiden perusteella voisi hakua rajoittaa jo palvelinpäässä.
Tuo on totta. Tilanne ei ole mitenkään aivan triviaali ratkaistava.
Jos turvavaatimuksia hieman lasketaan, kysymykseen voisi tulla toinen palvelin mikä hoitaa salauksen ja salauksen purkamisen. Käytännössä varsinaisella sovelluspalvelimella ei pureta eikä salata dataa, vaan data lähetetään fyysisesti toiselle palvelimelle missä muunto tehdään (sovelluspalvelimella ei tule olla minkäänlaista pääsyä tämän toisen palvelimen avaimiin jne). Tilanne on käytännössä sama kuin salasanojen hashauksessa käytetty "local parametrization".
Tällä ehkäistään jos itse sovelluspalvelin varastetaan tjms, niin data on salattuna eikä kyseisellä palvelimella ole mitään minkä avulla data voitaisiin purkaa. Tosin tämä ei auta jos hyökkääjä pystyy purkamaan sovelluspalvelimen ja "salauspalvelimen" liikenteen, koska silloin hän voi napata plaintextin lennosta (kun se saapuu "salauspalvelimelta"). Ja tosiaan myös nuo Grezin mainitsemat ongelmat ovat olemassa.
Slowhandin täytyy tehdä riskianalyysi ja suunnitella millaiset "riskit" menevät yli sallitun rajan, ja tämän pohjalta suunnitella ratkaisu ongelmaan. Tässä on jälleen yksi esimerkki että käytettävyys ja tietoturva eivät aina kulje käsikädessä, ainakaan aivan triviaalisti.
Pupesoftin asennnusohjeissa on GNUPG salauksen asentaminen:
https://github.com/devlab-oy/pupesoft/wiki/Asennusohje
PHP:n tietoturvan tueksi voi asentaa Suhosin Hardened PHP -palikan:
http://www.hardened-php.net/suhosin/
JavaScript ei ole sama kuin Java. Java on käyttöjärjestelmäriippumaton ohjelmointikieli, joka ajetaan käännettynä (Maven 2, Ant, yms.) JVM:ssä, eli Java Virtual Machinessa, jonka käyttöjärjestelmän Java-tuki (J2SE) ajaa tietokoneessa. Serveri-puolella on käytössä J2EE, JavaServlet ja JSP, jotka ajetaan mm. Tomcat Servlet Containerissa tai sitten EJB Containerissa kuten JBoss AS. JavaScript on selaimen scriptauskieli, millä voidaan scriptata WWW-selaimen toimintoja.
Aihe on jo aika vanha, joten et voi enää vastata siihen.