Tämä aihe liittyy tarjouslaskelmasovellukseen. En löytänyt suoraan verrannollista aihetta, ja osaamiseni loppuu tähän kohtaan (enkä halua ottaa käyttöön kuusikulmaista pyörää), siksi tämä aihe.
Järjestelmässä on siis rahanarvoista dataa, joka ei saa päästä vuotamaan ulkopuolisille. Samaa dataa pitää päästä kuitenkin lukemaan/muokkaamaan useamman käyttäjän, joilla on siihen oikeus. Ajattelin toteuttaa sen tähän tyyliin:
1. Käyttäjä kirjautuu sisään, salasana laitetaan sessioniin selväkielisenä.
2. Käyttäjä pyytää jotain salattua dataa.
a) Tietokannasta haetaan avain ja sillä purettava data, jota käyttäjä pyysi.
b) Puretaan salattu data ja lähetetään se käyttäjälle.
3. Käyttäjä haluaa tallentaa tekemänsä muutokset dataan.
a) Tietokannasta haetaan avain ja salataan sillä tallennettava tieto.
b) Tallennetaan salattu tieto tietokantaan.
Eli, PHP tekee kaiken salaukseen ja sen purkuun liittyvän työn ja tietokanta näkee salaisen datan valmiiksi salattuna.
Salaus- ja purkuavain (algoritmista riippuen, samat tai erit) tallennetaan tauluun, jossa on käyttäjäID, näkyvyysalueID, salausavain ja purkuavain. Avaimet ovat näkyvyysaluekohtaisia ja ne on salattu käyttäjän salasanan avulla, ts. avaimet ovat salasanan takana. Lisäksi taulussa voisi olla jokaista näkyvyysaluetta kohden aina käyttäjä ID:llä -1, jonka salasanan (missä säilytetään?) vain järjestelmä tietää (tarvitaan, kun käyttäjä palauttaa unohtuneen salasanansa tai liittyy näkyvyysalueeseen).
Niin, ja salattu yhteys vaaditaan selaimen ja PHP:n välillä sekä PHP:n ja MySQL:n (tarkoitus ei ole olla MySQL-riippuvainen) välillä.
Mitä sanotte, mikä osa ei voi toimia tai onko tälle olemassa jokin algoritmi valmiiksi?
Lisäksi, mitä salausalgoritmia kannattaisi käyttää missäkin kohdassa?
Itselle tulee lähinnä mieleen, että miksi tuo salaus ja purkaminen, jos kerran kuitenkin tietokannassa on ne avaimet? Eli jos joku pääsee käsiksi tietokannassa oleviin tietoihin, niin ne tiedot pystyy purkamaan suoraan.
Ihan vaan PHP:llä toteutetun pääsyrajoituksen tietoihin pystyy toteuttamaan täysin ilman salaustakin.
Ei tässä muuten, mutta käärmeöljyratkaisut on pahasta.
Tarkoitin siis, että avaimet salataan käyttäjän salasanalla (tai siitä lasketulla paremmalla salasanalla). Mutta siitä taitaakin tulla se moninkertainen salaus, joka ei (välttämättä) paranna turvallisuutta yhtään. Koodista tulee monimutkaisempaa, mikä tarkoittaa myös kasvanutta bugien määrää.
Olisi kyllä todella mukavaa, jos voisi jättää salauksen pois.
Jaa, no sittenhän tuo toimii.
Kaikkein paras olisi, jos käyttäjien salaisia avaimia ei tallenettaisi lainkaan palvelimella. En tiedä mahdollistaako esim. SL Client Certificaten käyttäminen sellaista, että käyttäjän julkisella avaimella salattu tieto voitaisiin käydä purkamassa selaimen päässä salaisella avaimella.
Jos tuollainen ei ole mahdollista, niin käyttäisin ehkä käyttäjäkohtaisina avaimina jotain bcryptillä salasanasta tehtyjä avaimia ja varsinaiseen käyttäjän tunnistamiseen käytettäisiin esim. salasanaa käänteisenä bcryptin läpi.
Tuollainen tietenkin on niin heikko kuin heikoin käyttäjän salasana (ko. käyttäjän nähtävillä olevien dokumenttien osalta)
Tietokannan tiedot eivät mitenkään itsestään vuoda. On myös erittäin epätodennäköistä, että hyökkääjä pääsisi nimenomaan MySQL-palvelimen ja PHP:n väliin mutta ei muualle. Ohjelmoi kunnolla, niin tiedot ovat hyvässä turvassa aivan ilman salausta. Jos pelkäät fyysistä kovalevyvarkautta, on taas kätevämpää käyttää koko datalevyn salausta käyttöjärjestelmän tasolla. Omatekoisilla salausviritelmillä luultavasti vain aiheutat ongelmia, bugeja ja jopa uusia tietoturva-aukkoja etkä ollenkaan lisää turvallisuutta.
Mielestäni myös salasanan säilyttäminen selväkielisenä olisi tarpeeton ylimääräinen tietoturvariski. Käyttäjää pitäisi mieluummin kannustaa salasanan vaihtamiseen säännöllisesti, eikä ainakaan tehdä salausta, joka on tietystä käyttäjän salasanasta riippuvainen.
Ohjelman toiseen versioon voisi miettiä todella varmaa salausta, mikäli ohjelman suosio kasvaa niin paljon. Tähän versioon riittää mielestäni vielä perinteiset salasanamenetelmät. Käyttäjän salasanaltakin voi aika paljon vaatia, kun tallennetaan arvokasta tietoa.
Jospa käytän tallennettuja proseduureja, jotka vaativat toimiakseen käyttäjän tunnuksen ja salasanan. Silloin ei olisi kovinkaan vaarallista, vaikka joku saisikin varastettua tietokannan salasanan. (SELECT * FROM Anywhere ...; => Access denied!) :) Koko homma pysyy saman prosessin sisällä, ja PHP näkee vain salaamattoman tiedon (PHP:stä tulee lähinnä Ajax-linkki).
Edit. Ok. Eli ei mitään omatekoisia salausviritelmiä, kuten edellisessä kappaleessa. Ilman salausta käyttäjän salasanan pitäminen muistissa muuttuu täysin tarpeettomaksi.
Vielä on yksi mutta. Missä säilytän tietokannan salasanaa? config.php:ssäkö?
Konffeihinhan se on tapana tunkea, jotta ohjelma voisi sen lukea.
Yksi melko simppeli keino on hoitaa datan salaus/avaus täysin erillisellä "palvelulla". Oma dedikoitu palvelin tjms. mikä ottaa salatun yhteyden kautta dataa vastaan ja joko avaa tai salaa datan ja palauttaa tuloksen. Tämä palvelin kommunikoi vain ja ainoastaan host-palvelimen kanssa (sovelluksesi kanssa), muualta ei tule olla pääsyä salauspalvelimelle.
Käyttäjärajaukset hoidat sovelluksessasi perinteiseen tyyliin (miten sen sitten ikinä toteutatkaan). Eli jos tietty käyttäjä ei saa avata jotain tietuetta, niin tälle käyttäjälle sovelluksesi ei näytä tätä dataa. Jos käyttäjä saa nähdä datan, niin silloin haet (salatun) datan kannasta ja lähetät rajapinnan kautta salauspalvelimelle, mikä puoletaan palauttaa datan selväkielisenä sovelluksellesi.
Salauspalvelimen ainoa funktio on yksinkertaistettuna salata ja purkaa dataa. Toki tämä käsittää key rotaatiosta ja versioinnista huolehtimisen ja muut salaukseen liittyvät nyanssit. Myös lisänä voit esim. aikarajata milloin salauspalvelin ottaa pyyntöjä vastaan sovellukseltasi jne.
Tällä tavoin datan salaus on ikään kuin näkymätöntä ja ei monimutkaista itse varsinaista sovellustasi juuri lainkaan. Mutta itse sovelluksesi on kuitenkin kriittinen tekijä, eli joudut olemaan erityisen tarkkana käyttöoikeusbugien sun muiden suhteen. Tietokanta voi hoitaa myös tuota datan salausta, esim. Oraclessa on mahdollisuus lennosta salata dataa, katso esim. http://docs.oracle.com/cd/B28359_01/server.111/
Tällä hetkellä konkreettisen datan salauksen hoidat AES:lla.
Keskustelin tästä aiheesta opettajani kanssa, joka oli sitä mieltä, että salaisuudet pitää salata myös kannassa. Jatketaan siis...
Suurimmalle osalle on varmasti melko epäselvää, mitä salaista kanta todellisuudessa sisältää. Lyhyesti sanottuna tarjouksia, jotka sisältävät tuotteita, jne. Suurin osa datasta on varmasti vain luottamuksellista tietoa, mutta jokunen bitti saattaa olla huippusalaistakin.
Tuosta timohin mainitsemasta salauspalvelimesta tuli mieleen, että voisin tehdä salauksen hyvin yksinkertaisesti, eli yksi PHP:n luokka hoitamaan sitä asiaa.
Siinä on kylläkin yksi mutta, nimittäin symmetrisen avaimen säilytys. Olisiko jollakin tietämystä avainten asiallisesta säilyttämisestä? En nimittäin näe kovin suurena turvallisuusparannuksena laittaa avainta www-rootin ulkopuolelle ja säätää sen oikeuksia, jos sitä verrattaan kokonaan salaamattomaan kantaan.
Lisäys: Paksusta ja korkeasta muurista ei ole paljoa apua, jos se on vain metrin levyinen... :D
No missä ajattelit tietokannan salasanaa sitten säilyttää? Tietokannasako? Eiköhän se laiteta tuonne rootin ulkopuolelle tiedostoon.
Lisäksi en ymmärrä, että mitä järkeä on laskea salainen avain salaisen salasanan avulla.
Tuon salauspalvelimen suhteen on oleellista että sinne ei pääse mistä tahansa käsiksi (mitenkään). Käytännössä vain sovelluspalvelimesi voi käyttää salauspalvelimen "salausprotokollaa" (eli esim. HTTPS-yhteyttä mihin vastaa salauspalvelimella esim. tuo sinun PHP-sovelluksesi mikä salaa ja avaa dataa).
Tämä jo itsessään rajoittaa avainten vuotamista (kukaan muu ei näe avaimia kuin itse salauspalvelin). Tietysti sielläkin käsittelet avaimia niin että vain PHP-sovelluksesi pääsee niihin käsiksi.
Salauspalvelimella tulee ongelmaksi varmuuskopiot, mutta lienee helpoimmalla pääset kun hoidat avaintiedoston varmuuskopioinnin manuaalisesti. Joudut tietysti salaamaan sen tiedoston ennen varmuuskopiointia, ja jos teet sen manuaalisesti niin tähän käytetyn salausavaimen voit säilyttää jossain muualla turvassa, ja annat vain ennen varmuuskopiointia tehtävän salauksen yhteydessä. Et siis säilytä tätä avainta salauspalvelimella.
Tuossa on yksinkertainen kaavio miten tämä salauspalvelin näkyy muualle, se helpottanee tuon kokonaisuuden ymmärtämistä (palomuuri salauspalvelimen edessä on korostamassa että salauspalvelimeen, varsinkaan "salausprotokollaan", ei tule olla muualta pääsyä kuin sovelluspalvelimelta):
http://i6.aijaa.com/b/00773/9992483.jpg
Tein tuon pikakaavion ihan sen takia, kun hieman siristin tuota kommenttiasi
jukkah kirjoitti:
että voisin tehdä salauksen hyvin yksinkertaisesti, eli yksi PHP:n luokka hoitamaan sitä asiaa – – En nimittäin näe kovin suurena turvallisuusparannuksena laittaa avainta www-rootin ulkopuolelle ja säätää sen oikeuksia – –
Kunhan siis nyt ainakin hoidat sen salauksen eri paikassa kuin missä itse nettiin näkyvä sovellus pyörii ;)
timoh kirjoitti:
Tietysti sielläkin käsittelet avaimia niin että vain PHP-sovelluksesi pääsee niihin käsiksi.
Siinä se hankaluus juuri onkin, mikäli siinä mitään hankaluutta edes on. ;)
Ymmärrän, mitä haet erillisellä palvelimella, ja myös sen, etteivät taitoni riitä tekemään siitä tarpeeksi turvallista. Eli aion vieläkin pysyä saman prosessin sisällä, vaikka toteutus vastaakin luultavasti lähes itsenäistä serveriä.
Tuo riippuu mm. palvelinasetuksista. Mutta juuri noin miten sanoitkin, eli oikeudet kuntoon ja avaintiedosto sellaiseen paikkaan että se ei ole minkään luukun kautta tyrkyllä ulospäin. Esmes lähdekoodikansioon, missä kaikki muutkin PHP-komponentit ovat (nehän sinulla on varmaankin poissa www-rootista).
Tuon erillisen palvelun suhteen ei periaatteessa (verrattuna siihen että se "salausprosessi" olisi samaisella sovelluspalvelimella kuin muukin sovelluksesi) ole mitään lisämonimutkaisuutta. Sen voit aloittaa pystyttämällä palvelimen samaan tapaan kuin sovelluspalvelimesikin on laitettu tulille. Esim. ensiksi laitat salauksen ja purun kuntoon ja sitten luot jonkinlaisen rajapinnan mikä ottaa sovelluspalvelimeltasi dataa vastaan ja palauttaa dataa sinne.
Toki tuo kokonaisuus on monimutkaisempi, mutta kannattaa aloittaa pienistä palasista ja parantaa systeemiä pala kerrallaan.
timoh kirjoitti:
oikeudet kuntoon ja avaintiedosto sellaiseen paikkaan että se ei ole minkään luukun kautta tyrkyllä ulospäin.
No niin, nyt tajusin. Minulla on ollut (vanhentunut) käsitys turvallisuuden parantamistavasta, jossa avaimet laitetaan "kassakaappiin" käyttöjärjestelmän salaamaan rekisteriin tms. Olisihan tämäkin pitänyt arvata jo aikaisemmin; tunkeilija, joka pääsee järjestelmään sisään, pääsee myös tutkimaan vaikka kuinka salaisia rekistereitä.
Miksi muuten PHP-skriptien kuuluu yleensä olla www-rootin ulkopuolella? Tässä tapauksessa on yksi terminal.php, ajaxia varten ja samasta kansiosta löytyy ihan perus PHP-luokkia, joita kutsumalla tapahtuu vain virhe 403 tai 404. (Katso projektin suunnitelmista hakemistorakenteen terminal-hakemistoa.) Veikkaan, että tässä tapauksessa ei ole hyötyä siirtää luokkia www-rootin ulkopuolelle.
Morjens jukkah!
älä vaan hukkaa niitä kassakaappis avaimia...
Jukkah: tiesostot laitetaan www-rootin ulkopuolella siksi, ettei selaimella voi suoraan ladata kyseistä tiesdostoa. Jonkun palvelinvirheen tai ihan inhimillisen virheen sattuessa palvelin saattaakin tulostaa php-tiedoston sisällön suoraan näkyville.
jukkah kirjoitti:
Miksi muuten PHP-skriptien kuuluu yleensä olla www-rootin ulkopuolella?
Ei siellä missään tilanteessa tarvitse pitää kuin salaisia osia kuten tietokannan salasanaa. Kaiken varsinaisen koodinhan voi vaikka julkaista aivan huoletta, jos ei ole syytä hävetä koodin huonoa tasoa.
Vähä offtopiccina, mutta onko jotenki mahdollista muka nähdä PHP luokan sisältö jos se on esim. var/www/phpluokat kansiossa eli julkisesti saatavilla. Miten se on yhtään haavoittuvampi, kuin sillon jos se on var/phpluokat kansiossa eli ei julkisesti saatavilla. Saako palvelimen kenties bugaamaan eikä latamaan PHP-tiedostoja oikein jollain palvelunesto hyökkäyksillä vai mikä logiikka tuossa olisi takana?
Synomi: haavoittuvuus on täysin spekulatiivista huttua, ei perustu mihinkään todelliseen uhkaan. Jos palvelimen saa niin sekaisin, että se alkaa syöttää PHP-dokumentteja suoraan selaimelle, niin kyllä palvelimen saa myös niin sekaisin, että se alkaa tehdä sitä ihan mistä hakemistosta tahansa.
Onhan kyse toki melko mitättömästä vaivasta, jolla voi yrittää suojata omaa koodiaan, jos itse koodi on jonkin sortin liikesalaisuus. Järjestelmän tietoturvan kannalta sillä ei minun mielestäni saa olla mitään tekemistä, koska järjestelmä on koodattu huonosti, jos salasanoja tms. on ripoteltu koodiin.
The Alchemist kirjoitti:
Synomi: haavoittuvuus on täysin spekulatiivista huttua, ei perustu mihinkään todelliseen uhkaan. Jos palvelimen saa niin sekaisin, että se alkaa syöttää PHP-dokumentteja suoraan selaimelle, niin kyllä palvelimen saa myös niin sekaisin, että se alkaa tehdä sitä ihan mistä hakemistosta tahansa.
Onhan kyse toki melko mitättömästä vaivasta, jolla voi yrittää suojata omaa koodiaan, jos itse koodi on jonkin sortin liikesalaisuus. Järjestelmän tietoturvan kannalta sillä ei minun mielestäni saa olla mitään tekemistä, koska järjestelmä on koodattu huonosti, jos salasanoja tms. on ripoteltu koodiin.
Joo tuolla käsityksellä sitä about on PHP-sovelluksia vääntänyt. Niin olisi vähän yllätys, jos luokan sisällön voisi jotenkin nähdä ja pitäisi tehdä aika paljon muutoksia koodeihin.
Itse topicista kans aikalailla sitä mieltä että tietokannan sisällyksen salaaminen aika turhaa ja hankaloittaa ohjelmointia, ellei kyse sit ole jostain pankin tietokannoista. Eiköhän se https, hyvä kirjautumissysteemi, salatut salasanat ole tarpeeksi.
The Alchemist kirjoitti:
jos itse koodi on jonkin sortin liikesalaisuus
Tässä tapauksessa etusivulla (ja/tai jossakin alareunassa) tulee luultavasti olemaan Fork me on Github -linkki. Lisenssiä emme ole päättäneet, mutta MIT:issä on ainakin sopivasti tekstiä luettavaksi. :)
Synomi kirjoitti:
tietokannan sisällyksen salaaminen aika turhaa ja hankaloittaa ohjelmointia
Oikein toteutettuna se ei hankaloita yhtään.
Edit. Salauksella suojataan tietoa myös rehellisiltä ylläpitäjiltä. Jos vaikka joku yksittäinen ylläpitäjä jossakin ottaa minuun yhteyttä jonkun vian korjaamiseksi tietokannassa, en heti ensimmäisellä silmäyksellä tiedä (kannan rakenteen hyvin tuntien), millaisia tarjouksia yritys on tehnyt viimeisen kuukauden aikana. (Ja kun salaus tehdään, tehdään se kerralla kunnolla, eikä mitään ROT13-juttuja.)
jukkah kirjoitti:
Synomi kirjoitti:
tietokannan sisällyksen salaaminen aika turhaa ja hankaloittaa ohjelmointia
Oikein toteutettuna se ei hankaloita yhtään.
Jos tämä olisi totta, salausta varmaan käytettäisiin aina ja kaikkialla.
jukkah kirjoitti:
Jos vaikka joku yksittäinen ylläpitäjä jossakin ottaa minuun yhteyttä jonkun vian korjaamiseksi tietokannassa, – –
– – olet jo tehnyt suuren virheen, ja jos asiakkaalla oikeasti on jotain tärkeää tietokannassasi, hänen olisi syytä irtisanoa sopimus heti paikalla ja hankkia luotettavampi palveluntarjoaja.
Metabolix kirjoitti:
jukkah kirjoitti:
Synomi kirjoitti:
tietokannan sisällyksen salaaminen aika turhaa ja hankaloittaa ohjelmointia
Oikein toteutettuna se ei hankaloita yhtään.
Jos tämä olisi totta, salausta varmaan käytettäisiin aina ja kaikkialla.
En ymmärrä. Muuttuuko ohjelman rakenne oleellisesti hankalammaksi lisäämällä muutamaan kohtaan salaa(...) ja avaa(...)?
Metabolix kirjoitti:
olet jo tehnyt suuren virheen, ja jos asiakkaalla oikeasti on jotain tärkeää tietokannassasi, hänen olisi syytä irtisanoa sopimus heti paikalla ja hankkia luotettavampi palveluntarjoaja.
Vähän laajennusta, kiitos. Tällä hetkellä projektilla on yksi "asiakas" (eli mahdollinen tuleva käyttäjä), ja homma on menossa vasta melko alussa, joten kelkan suunnan muuttaminen on vielä helppoa.
Sillä ei sinällään ole mitään väliä, mitä sinä voit saada tietoosi asiakkaistasi. Vikatilanteissa voit joutua joka tapauksessa edellyttämään selkokielisen datan näkemistä, koska et voi muuten tietää, mikä rivi tietokannassa on virheellistä roskaa ja mikä ei.
Luonnollisesti joudut kuitenkin tekemään asiakkaidesi kanssa salassapitosopimuksen ja vaatimaan vastaavaa myös kaikilta työtovereiltasi, joille annat oikeudet kyseisiin tietokantoihin. Muutenkin on päivänselvää, ettei sinulla saa olla mitään asiaa heidän tietojaan lukemaan ilman pakottavaa tarvetta. Mikäli asiakkaasi eivät voi tähän NDA:han ja palveluntarjoajan rehellisyyteen luottaa, niin silloin heidän ei pidä sinun asiakkaiksesi alkaa alun perinkään.
HALOO!
Tämän säikeen aloittajalle suosittelisin kyllä todella VAHAVASTI TERAPIAA!
jukkah kirjoitti:
Vähän laajennusta, kiitos.
Keksi esimerkki tilanteesta, jossa systeemi on hyvin koodattu ja toimii oikein mutta silti ilmenee pakottava tarve muuttaa käsin asiakkaan salaisia tietoja. Minusta sellaista tilannetta ei pitäisi koskaan tulla.
Joo, nyt ymmärrän, ettei salaus kuulu tähän kohtaan.
neau33: No, aloitetaan terapia. Saat olla terapeutti. ;)
The Alchemist kirjoitti:
Synomi: haavoittuvuus on täysin spekulatiivista huttua, ei perustu mihinkään todelliseen uhkaan. Jos palvelimen saa niin sekaisin, että se alkaa syöttää PHP-dokumentteja suoraan selaimelle, niin kyllä palvelimen saa myös niin sekaisin, että se alkaa tehdä sitä ihan mistä hakemistosta tahansa.
Lebe sen tuolla ylempänä sanoi, palvelinvirhe tai inhimillinen virhe. Spekulatiivistä huttua tuollainen tapahtuma ei missään nimessä todellisuudessa ole. Esim. Facebookille on päässyt niin käymään, ja ellen aivan väärin muista, niin luulen että olen täällä Ohjelmointiputkassakin tuollaisen lähdekoodivuodon itse todistanut.
Se oleellinen ero on siinä, onko lähdekoodivuoto teknisesti ottaen epätodennäköistä, vai täysin mahdotonta (tarkoitan tilanteita missä webbipalvelin jättää PHP:n suorittamatta ja pukkaa sen tekstinä ulos). Siinä voi äkkiä hymy jos toinenkin hyytyä, jos privaatti bisneslogiikka karkaa maailmoille (vaikka konfiguraatioparametrejä ei mukana olisikaan).
Timoh:
No jos tuommoinen tilanne nyt tulisi, mikä on erittäin epätodennäköistä ja tietokanna salasanat vuotaisi (mikä nyt itsellä voisi olla se ongelma), niin eihän siinäkään olisi haittaa, jos tietokantaan pääsee käsiksi vain localhostista eli pelkkä PHP. PHP ei tällöin toimisi ja kukaan ei pääsisi tietokantaan käsiksi. Ongelman huomatessa salasanat voisi vaihtaa.
Synomi: Entä, jos samalla PHP-palvelimella on vielä vaikka phpMyAdmin asennettuna, niin kuin monesti. Ongelma muuttaa silloin hiukan luonnettaan.
Mutta tuollaiset salaiset tiedostothan pitää blokata jo heti htaccessista lähtien, jolloin ne eivät pääse vuotamaan yhtä "helposti".
timoh kirjoitti:
Ellen aivan väärin muista, niin luulen että olen täällä Ohjelmointiputkassakin tuollaisen lähdekoodivuodon itse todistanut.
Luultavasti muistat väärin, koska itse en ole tällaisesta kuullutkaan. Joka tapauksessa jos noin on, vika on varmaan Louhessa, joka nyt on muutenkin osoittautunut tekniseltä tasoltaan surkeaksi webhotelliksi.
Jos itse tekisin tärkeään palvelimeen muutoksia, joissa olisi todellinen konfigurointivirheen riski, estäisin yhteydet verkosta muutostyön ja testauksen ajaksi – ongelma on näin eliminoitu. En myöskään usko, että palvelimesta käytännössä löytyy bugia, joka sallii tiedostojen lukemisen www-rootista mutta ei sen ulkopuolelta; todennäköisemmin bugi sallii saman tien minkä tahansa tiedoston lukemisen.
Jos saan sopivat systeemit pystyyn ja jaksan kehitellä, voidaan järjestää Putkassa kilpailu, jossa on murrettavana muutama erilainen järjestelmä. Sittenpä nähdään tilanne käytännössä. Ehdotuksia kilpailuun liittyen voi lähettää vaikka palautelomakkeella.
Jukkah: phpMyAdminki vaatii PHP:n toimiakseen. Tuskin se toimisi jos muuallakin olisi PHP virheitä, mutta tosiaan phpMyAdminiin pitäisi olla julkisesti rajoitettu pääsy. Tietty jos virhe olisi tilapäinen ja kestäisi vaan tunnin esimerkiksi ja jäisi huomaamatta. Niin tietokanta voisi vaarantua jos phpMyAdmin on julkisesti kaikille saatavilla.
Synomi kirjoitti:
Tuskin se toimisi jos muuallakin olisi PHP virheitä
Tuota en kyllä hoksannut. :)
Kun ylläpitäjä huomaa vian, hän buuttaa serverin ja on tyytyväinen, kun kaikki taas toimii kunnolla, eikä tiedä mitään tunnuksen ja salasanan leviämisestä netissä. Heh.
Synomi: Se on siitä kiinni haittaako se jos lähdekoodi vuotaa. Jos konfiguraatioparametrit vuotaa, se voi olla fataalimpaa (ja se huomataanko ovatko ne vuotaneet).
Pienellä ratkaisulla voidaan kuitenkin kokonaan eliminoida tuo ongelma, joten miksei sitä sitten kannattaisi käyttää.
Heippa taas!
suurella mielenkiinnolla kysyisin jukkah:lta, että missähän vaihessa se aiheeseen liittyvä (???) tarjouslaskelmasovellus nyt oikein menee elikä onko jo täysin valmis?
neau33: Se on menossa jotakuinkin sekoita(["vaatimusmäärittely", "suunnittelu"])-vaiheessa. Tässä on vielä linkki lisäinformaatioon.
Ethän vain ajatellut, että miettisin tietoturva-asioita vasta ylläpidon aikana. ;D
Aihe on jo aika vanha, joten et voi enää vastata siihen.
