PHP svetainių saugumas

Sveiki,

Iškilo tos klausimas, nors ištikrųjų jis visuomet mane kamuoja kai mėginu sukurti kokią PHP svetainę visai nuo nulio. Taigi dabar esu susikūręs savo TVS, kuris turi jau pagrindines funkcijas, jau galima pasigaminti informacinę svetainę. Žadu šį TVS dar labai plačiai plėsti, bet galvoju, kad reikia neskubėti. Kadangi dabar yra taip, kad aš nežinau ar mano sukurtas TVS yra saugus, ar saugi prisijungimo sistema, ar tokiu būdų kokiu aš aprašau visas PHP funkcijas yra saugu ir panašiai, nes kad nebūtų taip, kad sukuri plačių funkcijų TVS, bet jis būna nesaugus ir reikia viską perašyti, ar to galima ir išvengti?

O gal galbūt kas nors gerai išmano PHP ir galėtų mane pakonsultuoti? Ar bent šiek tiek padėti, pasakyti kur galima visą tai sužinoti?

 

Iš anksto dėkoju.

10 svarbiausių saugumo skylių. Nespecializuota PHP, tačiau svarbu suvokti pačias spragas, o ne kaip saugotis nuo jų būtent PHP.

Sveiki,

Iškilo tos klausimas, nors ištikrųjų jis visuomet mane kamuoja kai mėginu sukurti kokią PHP svetainę visai nuo nulio. Taigi dabar esu susikūręs savo TVS, kuris turi jau pagrindines funkcijas, jau galima pasigaminti informacinę svetainę. Žadu šį TVS dar labai plačiai plėsti, bet galvoju, kad reikia neskubėti. Kadangi dabar yra taip, kad aš nežinau ar mano sukurtas TVS yra saugus, ar saugi prisijungimo sistema, ar tokiu būdų kokiu aš aprašau visas PHP funkcijas yra saugu ir panašiai, nes kad nebūtų taip, kad sukuri plačių funkcijų TVS, bet jis būna nesaugus ir reikia viską perašyti, ar to galima ir išvengti?

O gal galbūt kas nors gerai išmano PHP ir galėtų mane pakonsultuoti? Ar bent šiek tiek padėti, pasakyti kur galima visą tai sužinoti?

 

Iš anksto dėkoju.

 

Kadangi tu pats rasei savo TVS tokiu atveju niekas kitas be taves to programinio kodo neturi ir negales isigilinti tiek, kad visas tas klaidas atrastu.

 

Kas liecia pazeidziamumus tai dazniausiai pasitaikantys yra XSS ir mysql injection visi kiti "pazeidziamumai" gali buti tiesiog logines klaidos ar dar kazkas kaip pvz jeigu svetaineje galima ikelti nuotraukas o tavo scriptas leidzia ikelti netik nuotraukas, bet ir php failus na esme vnz aiski.

 

Noredamas tapti geru programuotoju turi nebijoti klaidu, tu niekad neparasysi gero kodo neturedamas patirties. Vnz daryk tai ka darai o jeigu ir nulaus tai nulaus atrasi klaida ir daugiau jos nebekartosi.

 

Netgi ir geriausi programuotojai palieka klaidas uz kurias poto reikia moketi nieko cia nepadarysi.

10 svarbiausių saugumo skylių. Nespecializuota PHP, tačiau svarbu suvokti pačias spragas, o ne kaip saugotis nuo jų būtent PHP.

 

Dėkoju, kas dar turite kokių pasiūlymų?

 

Kadangi tu pats rasei savo TVS tokiu atveju niekas kitas be taves to programinio kodo neturi ir negales isigilinti tiek, kad visas tas klaidas atrastu.

 

Kas liecia pazeidziamumus tai dazniausiai pasitaikantys yra XSS ir mysql injection visi kiti "pazeidziamumai" gali buti tiesiog logines klaidos ar dar kazkas kaip pvz jeigu svetaineje galima ikelti nuotraukas o tavo scriptas leidzia ikelti netik nuotraukas, bet ir php failus na esme vnz aiski.

 

Noredamas tapti geru programuotoju turi nebijoti klaidu, tu niekad neparasysi gero kodo neturedamas patirties. Vnz daryk tai ka darai o jeigu ir nulaus tai nulaus atrasi klaida ir daugiau jos nebekartosi.

 

Netgi ir geriausi programuotojai palieka klaidas uz kurias poto reikia moketi nieko cia nepadarysi.

 

Dėkui už palaikyma, bet dėl to, kad niekas nematys to kodo. Ištikrųjų nelabai taip bus, matote aš kai baigsiu kurti TVS, tai su juo kursiu svetaines pagal užsakymus, nes man tai bus lengviau, nei naudoti kitų sukurtus TVS. Taigi kai paplis šis TVS, tai bus galima įsigilinti į kodą ir tada jau bus daug svetainių su tuo TVS ir su tomis spragomis. Aišku aš sakau daug, o gal ištikrųjų tik kelietas, bet vistiek.

Dėkui už palaikyma, bet dėl to, kad niekas nematys to kodo. Ištikrųjų nelabai taip bus, matote aš kai baigsiu kurti TVS, tai su juo kursiu svetaines pagal užsakymus, nes man tai bus lengviau, nei naudoti kitų sukurtus TVS. Taigi kai paplis šis TVS, tai bus galima įsigilinti į kodą ir tada jau bus daug svetainių su tuo TVS ir su tomis spragomis. Aišku aš sakau daug, o gal ištikrųjų tik kelietas, bet vistiek.

Kodo nematymas dar nieko nereiškia... SQL injekcija, XSS, CSRF, netinkami autentikacijos mechanizmai - visa tai ir dar daugiau puikiai galima atrasti iš išorės. Tikrai ne priežastis atsainiai žiūrėt į saugumą :)

Kodo nematymas dar nieko nereiškia... SQL injekcija, XSS, CSRF, netinkami autentikacijos mechanizmai - visa tai ir dar daugiau puikiai galima atrasti iš išorės. Tikrai ne priežastis atsainiai žiūrėt į saugumą :)

 

Bet su tais SQL injekcijomis gal nieko nepadarys, jei pas mane net sistemiškai nėra naudojamos nuorodos pvz.: index.php?id=2 Yra iškart naudojama pvz.: /naujienos ir tikrinama pagal juos kokį puslapį rodyt. Nežinau kodėl kitos TVS rašo pagal tuos id. Pavyzdžiui kad ir šio forumo nuoroda susidaro iš index.php?app=forums...&qpid=1924483, o aš kuriu TVS, kad tokie dalykai iš vis nebūtų naudojami, manau taip geriau. Bet gal kaip tik dar blogiau darau?

Bet su tais SQL injekcijomis gal nieko nepadarys, jei pas mane net sistemiškai nėra naudojamos nuorodos pvz.: index.php?id=2 Yra iškart naudojama pvz.: /naujienos ir tikrinama pagal juos kokį puslapį rodyt. Nežinau kodėl kitos TVS rašo pagal tuos id. Pavyzdžiui kad ir šio forumo nuoroda susidaro iš index.php?app=forums...&qpid=1924483, o aš kuriu TVS, kad tokie dalykai iš vis nebūtų naudojami, manau taip geriau. Bet gal kaip tik dar blogiau darau?

Daug variantų gali būti. Visada reikia saugotis, o ne galvoti, kad kažkokia magija suveiks. Jei pas tave yra tiesiog

pavadinimas | id 

naujienos   | 1
renginiai   | 2

ir t.t., ir užklausi jau paėmęs tą id - tada gerai, vartotojas prie užklausos pats neprisilies. Jei užklausinėji pagal tą 'naujienos' žodį duomenų bazėje, tada nelabai. O turėk dar omeny tokius dalykus, kaip paiešką. :)

 

Žodžiu, tavo URL struktūra yra joks ne pakaitalas būtinoms apsaugoms. Apskritai, visur, kur kažkas gaunama iš vartotojo, tu turi būti didžiausias paranojikas, turi mąstyti, kad kiekvienas jo įvestas simbolis gali būti nesaugus :)

Daug variantų gali būti. Visada reikia saugotis, o ne galvoti, kad kažkokia magija suveiks. Jei pas tave yra tiesiog

pavadinimas | id 

naujienos   | 1
renginiai   | 2

ir t.t., ir užklausi jau paėmęs tą id - tada gerai, vartotojas prie užklausos pats neprisilies. Jei užklausinėji pagal tą 'naujienos' žodį duomenų bazėje, tada nelabai. O turėk dar omeny tokius dalykus, kaip paiešką. :)

 

Žodžiu, tavo URL struktūra yra joks ne pakaitalas būtinoms apsaugoms. Apskritai, visur, kur kažkas gaunama iš vartotojo, tu turi būti didžiausias paranojikas, turi mąstyti, kad kiekvienas jo įvestas simbolis gali būti nesaugus :)

 

Bet juk jei bus siunčiama 'naujienos' ir nebus nieko rasta bus rodoma neegzistuojantis puslapis. Bet kokiu atveju reiks siūsti ar tai skaičių ar tai žodį, tai ką žodis gali padaryti blogiau?

Bet juk jei bus siunčiama 'naujienos' ir nebus nieko rasta bus rodoma neegzistuojantis puslapis. Bet kokiu atveju reiks siūsti ar tai skaičių ar tai žodį, tai ką žodis gali padaryti blogiau?

Ne žodį vs. skaičių turėjau omeny. Turėjau omeny kažką tokio tavo pusėj, kad pagal 'naujienos' susigaudai statiškai, jog id yra 1, ir tada tu PATS tą id įterpi, vartotojas pats nekiša argumento į tavo užklausą.

 

Na, bet nesvarbu. Žodžiu, SQL argumentus tvarkyti reikia VISADA. Net jei galvoji „ai, čia tik aš pats naudosiu, tai visad įvesiu gerai“. Galiausiai metas naudoti normalius mysql client libus, kur nebe escape'ais viskas eina, o pribindinami argumentai prie užklausos - ir ta dalis už tave atlikta bus :)

 

Bet kaip sakiau - pasižiūrėk OWASP sąrašą, ten kaip ir viskas svarbu :) Na gerai, gal išskyrus kokį SSL, kuris ne nuo tavo TVS priklauso (nebent tiek, kad jei SSL palaikymas YRA, tai jį turėtų tavo TVS forcinti).