[jnt]

Tervitused! Nimelt, seoses ühe suurema projektiga olen valmis kribanud ka enda andmebaasiklassi, millega siis päringuid andmebaasi teen. Kõik toimib ja paistab ideaalne, kuid kas see nii on? Nimelt huvitaks kõikvõimalikud variandid ja võimalused, kuidas teha üks päring turvaliseks, kui päringusse on ka juurde toodud erinevad $_POST, $_GET jt muutujad. Hetkel on turvalisus sinna kanti:
Mul on oma andmebaasi objekt $m. Päringu tekitan meetodiga $m->q();
Võtame alguses "koleda" ebaturvalise koodi:

[airm]

turvalisus turvalisuseks,
aga mis juhtub, kui get->id asemel on string, mitte number?

errorkontroll stringide ja numbrite üle toimub ennem või pärast info edastamist sinna hüpersuper objekti?
või objekti sees?

[jnt]

kui $_GET['id'] on string, siis tulemuseks on see, mille annab mysql_real_escape_string(intval($_GET)). See kontroll toimub juba q() meetodi sees, kui asendatakse [blabla] stuffi. (lisaks veel omasätitud kraam ka juures, nagu [pre] prefixi jaoks jne)

see, kas nt $_GET['id'] väärtust omab, toimub muidugi väljaspool klassi vastava if'iga, peale mida hakatakse edasi vaatama.

[mikk36]

Seega piirad sa $m->q() ära ainult int väärtustega selekteerimiseks ?

[jnt]

kui mul on [0], siis esimene parameeter peale sql stringi võetakse sellisena, nagu ta on, kui on [0:i], võetakse see integerina ja kui on [0:f], võetakse see floatina.

[k2iguvahetaja]

utf doctrine

[jnt]

k2iguvahetaja, iseleiutamine on ikka kõige huvitavam. Ei taha teiste kraami kasutada, tahan kõike ise teha.

[inzinz]

Noh kui loogikavigasid sul seal mysql klassis ei ole, siis põhimõtteliselt peaks kõik hästi töötama, kuna kõik parameetrid escapetakse ära ja alles siis pannakse sql lausesse sisse. Ehk näitad koodi ka ?
Aga üks küss ikkagi on veel: mis juhtub siis, kui su kood jookseb kusagil serveris kus on magic quotes peal ? Kas stringid muutuvad \\\\\\\\ sasipundardeks ?

Soovitaks mingi üldisema lisafunktsiooni teha millega võtad get/post parameetreid, vajadusel teed stripslashes kui magic quotes on peal ja siis otsa teed veel intval/floatval kui tegu numbriga.
Sellisel juhul sa saad ka mujal kui ainult sql klassi parameetrina sama väärtust kasutada ja on samamoodi turvaline/ühtne ka mujal koodis.

[jnt]

inzinz, magic quotes? Kohe lähen ja uurin selle kohta. Hetkel muidu asi paistab kenasti toimivat küll... Tuli jah lisaks idee teha klassiväline funktsioon, millega saab "valideerida" stringe. Et saab kontrollida, kas pikkus on vastav, kas tegemist on nr, stringi või e-mailiga jne.

Aga selle magic quotes'iga, et kui see peal, tuleb stripslashes kõigepealt siis ära teha, jah?


Siin siis query funktsioon, mis on privaatne. Sellele teevad päringuid funktsioonid q (tavaline query), qfa (esimene tulemus mysql_fetch_array'ga läbi), qfa2d (eelmine, kuid kõik tulemused, kokku 2d array), qfo (nagu qfa, aga mysql_fetch_object funktsiooniga) ja qfoa (nagu qfa2d, ainult et array siis nö objektidest). See query sööb argumente juba array'na, kus esimene liige on query ise.

[inzinz]

Natuke uurides tekkis paar küsimust:
esiteks miks sa teed stringidele trim funktsioonis, mis peaks andmeid baasi edastama. Nii tekivad ju olukorrad kus mingil juhul läheb infot kaduma, ilma etteteatamiseta. Trim tuleks ideeliselt teha ikka seal kohas kus infot ette annad, kui tead et kindlalt tahad trim teha mingile parameetrile.
teiseks, mis saab siis, kui tekstivälja/stringiparameetri väärtuses on kasutaja sisendist tulnud [mingiparam] või [2] jne. Praegusel juhul tekib data integrity probleem, kuna stringis teed järjest replacemisi. Kui kasutaja kogemata/meelega paneb teksti välja sisse stringi [1] siis tekib tema teksti sisse [1] asemele mingi väärtus. Üks lähenemine oleks sql järjest märkhaaval/parameeterhaaval läbi käia ja siis uus string koos väärtustega kokku ehitada. Säiliks andmete ühtsus ning töötaks endiselt turvaliselt.
kolmandaks, kas stringidele hakkad ise alati etteantavas päringus quotesid ümber panema stiilis: q('select * from tabel where nimi="[0]"', 'nimi'). Kui sul asendav loogika juba teab et tegu stringiga, siis oleks kergem sealsamas asendamise loogikas kohe "" ümber lisada ja mujal koodis keerukust kokku hoida pluss ei saa tekkida unustamisest tulenevaid vigasid.

minu 5 senti

[jnt]

inzinz, Suured tänud, eile õhta tulin ka järsku idee peale, et mis siis saab, kui järsku keegi [0] nt ise sisestab... Lahendaksin ma hea meelega seda asja 2x explode'imise teel (algul [ järgi ja siis : järgi. siis saan kätte nr ja tüübi saan : explode'i teise elemendi esimesest tähest), kuid siis oleks jama ikkagi olemas. Üks võimalus oleks kasutajal [ ja ] märk ära keelata, mis polegi liiga halb variant, kuid kuidas sa täpselt seda tähthaaval läbi käimist ette kujutad, et kasutaja stuffi ei hakataks "parsima"?

Hetkel olen natuke tegelenud üldise turvalisusega ka. olen teinud funktsiooni, millega saab kontrollida, kas sisestatu on str, int, aadress või e-mail ja juures veel min ja max pikkus. Veel olen teinud token'ite süsteemi, kus funktsiooni käivitades genereeritakse suvaline string-jada ja tagastatakse see ning pannakse too ka sessiooni. Kui kontrollida, kontrollid $_POST['token']/$_GET['token']'it selle sama funktsiooniga, andes argumendiks true, mis läbi tagastab funktsioon token'i sessioonist, kuid kustutab sessioonist tokeni ära. (Iga kord, kui ilma argumendita token'i funktsioon käivitatakse, vaadatakse, kas token on juba genereeritud ja kui pole, siis see genereeritakse ning lõpuks tagastatakse viimane) Lisaks veel olen kokku klopsinud kerge captcha. Et sellised lood veel turvalisuse teema pealt.

Kuid tulles tagasi mysql päringute juurde, siis jah, olekski küsimus, et kuidas sa käiksid selle sql päringu tähthaaval läbi? Kas tõesti mingi keemiaga for tsükliga (näiteks) käia $q{0} - $q{length} läbi ja siis seal tegeleda? Kui kiire selline lahendus oleks?

EDIT: Kas mõtlesid midagi sellist muidu, et "ehitada" uude muutujasse täht haaval uut query't ja niimoodi siis asi ära teha? Kas umbes nii?

[inzinz]

Umbes midagi sellist jah aga sul see kood seal hetkel töötab ainult ühekohaliste numbritega [1], [2:f] jne, kui aga tuleb sisse [12:f] siis loogika enam ei tööta.
Üks variant oleks jah explodeda stiilis:

[jnt]

Hetkel leiutasin ise ka seda enda esialgset koodi, et toetaks mitmekohalisi numbreid ja välja tuli selline süsteem:

[inzinz]

Aga ühe asja kaotasid sa ära, mysql_real_escape_string'i sa enam ei tee miskipärast.
Rida
case 's': $pq.="'".trim($args[$nr+1])."'"; break;
vajaks ikkagi escapemist ka

[jnt]

inzinz, yup, kuid see funktsioon ei toimi, kui pole database'iga ühendust. Seepärast mainisingi, et see kood hetkel "niisama" pandud tööle. Nüüd, kui asi on mul db klassis, on mysql_real_escape_string kenasti igal pool olemas, kus vaja.

[nene]

Mainin, et sedasorti kood on just selline, mille arendamisel tuleks vägagi kasuks unit-testide kasutamine. Eriti veel siis kui su eesmärgiks on turvaline kood.

Sul on üsna rangelt piiritletud probleem. Funktsiooni sisend ja väljund on lihtne, kuid sisemine loogika on keerukas. Mis on unit-testimiseks ideaalne.

[kapa24]

Minu panus, preg_replace_callback funktsiooni kasutades...

[d3t]

Esiteks peaks sinna klassi saama pöörduda ainult sinu programmi siseselt, seega hea oleks kui sa nt lipuga ära määraks klassi suremise kui sinna otse pöördutakse.

Teiseks võiksid valideerida sisendi enne protsessi ja kurjad comandid nagu table drop jne välja filtreerida

[inzinz]

[d3t]

inzinz, kui nt includida seda faili kus klass sees on, siis annab seda ju kasutada?

Pahad requestide filterdamisest, mõtlesin midagi sellist: http://firewallscript.com/

[inzinz]

No aga see ei anna suurt midagi juurde turvalisusele kas lasta includeda või mitte, kuna baasi klass on niikuinii eraldi failis klassina, sisse includides mingit kriitilist loogikat ei tohiks jooksutada ning baasi connectimise info peaks ka kuskil eraldi olema.
Niisama klassi sisaldava faili sisse includemine ei kvalifitseeru küll kuidagi häkkimisena
PHPBB foorumi puhul on küll oluline kas lubada includeda ja aadressiribalt ligi saada, kuna failid on funktsioone ja tavakoodi täis, mida igal includemisel jooksutatakse ja võib igast huvitavaid olukordasid tekitada.

Nonde blokkijate/filtrijate koha pealt ütleks et väga tihti need keeravad käru. Põhiprobleemiks see, et too vaheskript/filtreerija ei tea halligi sellest mida sinu php kood teeb kui saab näiteks ette väärtuse admin"#
Kui sinu kood sisestab selle ilusti tabelisse või kasutab päringus normaalselt (escapeb ära) on kõik korras sinu poolt tegelikult, kui aga filtreerija eeldab et selle peale vaja alati errorit visata või ei tea mida veel teha (asendada) siis tekivad andmekaod ja muidu segadust.
Seepärast ongi soovituslik kasutada miskit sellise parameetritega sql asjandust algusest peale, mis teeb by default kõik päringud turvaliseks ja kogu moos, ei mingit häkkimist ja ei mingeid imelikke olukordasid kus mingi kolmas kooditükk andmeid näperdab vahepealt ära.

[andresv]

miks mitte kasutada parameetrite "bind"-imist?

http://ee.php.net/manual/en/mysqli-stmt.bind-param.php

[d3t]

inzinz, mina nt kipun kirjutama extends class config ja enne seda faili algusesse include config ala ja minu puhul oleks nt turvaauk kui saaks otse includida

[nene]

[inzinz]

Peamine probleem nende keerukamate komponentidega, mis on süsteemi sisse ehitatud, ongi see, et nad käituvad mitte nii nagu sina tahad vaid nii nagu nende tegijad arvasid et oleks hea. Näiteks PHP enda DateTime klass oli veel mingi aeg suht jama, ning kuna ise seda muuta/overrideda ei saa, siis pidin tegema DateTimeBase klassi omale mis võimaldaks teha just täpselt niimoodi asju nagu vaja.
Ja lisaks kui antud komponendil on mingi bugi (mysqli extension näiteks, kus on neid bugisid aja jooksul ikka jagunud) siis pead ootama uut php versiooni või hakkama ise patchima ja kokku kompileerima.

mysql_query jms tavalised põhilised asjad on kindla peale töötavad ja nende peale oma klassi ülesse ehitades on esiteks hea näpuharjutus turvalise koodi kirjutamise jaoks ja teiseks kui tekib bugisid, saad alati ise kiirelt ära parandada ilma kolmandate osapoolte taga ootamata.