
Pribrendo antra straipsnio dalis, pirmąją straipsnio dalį rasite čia. Toliau tęsiame trumpą pokalbį apie dažnai daromas PHP programuotojų klaidas, kai kurios klaidos liečia ne tik PHP, bet ir programavimą apskritai.
Klaida 9. Pernelyg pasitiki lankytojais
Kai kurie pradedantieji programuotojai per daug nekreipia dėmesio į visokius patikrinimus tinklapyje – turiu omeny formų laukus, URL parametrų teisingumą ir kt. Jie galvoja, kad vartotojai nekvaili ir neįvedinės nesamonių. Bet, be įžeidimo, galima pasakyti, kad vartotojai yra tikrai kvaili!
Nemetu akmenų į jų daržą, bet juk atsitinka taip, kad nepataikai į klavišą klaviatūroje ir tada dėl vienos klaidelės pasikeičia gana daug. Tai čia geriausias variantas, o jeigu lankytojas ką nors negero padarys tyčia? Ar dėl smalsumo, ar norėdamas pakenkti – ne tiek svarbu, bet kuriuo atveju jūsų kodas turi atsilaikyti. Trumpas reziumė – reikia kurti tokius tinklapius, kad nei maži vaikai, nei visiškai su kompiuteriu nedraugaujantys žmonės, nei hakeriai negalėtų pakenkti. Na čia idealiame variante, realiai kas per daug tas irgi nesveika, taip besirūpinant saugumu galima niekada neužbaigti kurti
Klaida 10. Klaidų išvedimo išjungimas
Kalbant apie programavimą, klaida klaidai nelygi. Daug PHP programuotojų mano, kad jei ekrane pasirodo koks nors warning ar notice, tai lengviausias būdas ištaisyti padėtį – išjungti jų išvedimą. Aš jau nekalbu apie rimtesnes klaidas, kurių išjungimas yra iš viso beprasmiškas. Bet ir kalbant apie įspėjančias klaidas, kurios teoriškai netrukdo skriptui būti įvykdytam, patarimas – taisykite ir tokias klaidas, visus warning’us ir notice’us. Nes juk ne veltui PHP interpretatorius rodo tas klaidas. Trumpai tariant, jei bent kokia klaida pasirodo ekrane – ją reikia taisyti.
Klaida 11. Nepakankamas funkcijų testavimas su visais įmanomais argumentais
Šita klaida būdinga visų kalbų ir visų profilių programuotojams, ir net ne tik programuotojams. Aš dabar kalbėsiu ne apie tai, kad “reikia testuoti, testuoti ir dar kartą testuoti”. Mintis tokia: jei yra funkcija arba klasės metodas ir jis turi parametrų, reikia iš anksto numatyti, kokie parametrai gali būti. Dabar kalbu net ne apie saugumo spragas (apie jas vėliau) – bet bendrąja prasme, pvz. Kas bus jei pas jus atskiri puslapiai generuojami pagal jų ID numerius, bet vartotojas įves URL ne http://www.jusupuslapis.lt/index.php?id=6 o http://www.jusupuslapis.lt/index.php?id=abcde. Trumpai tariant – jei yra funkcijos, reikia apgalvoti jų parametrus ir pratestuoti funkcijas su įvairiais parametrais.
Klaida 12. Regexp’ai nelaiku ir ne vietoj
“Regular expressions” (lietuviškai vadinami įvairiai: reguliarūs reiškiniai/išreiškimai ar kt.) yra gana patogus būdas darbui su eilutėmis. Neverta rašyti 10 eilučių kodo, kuris atlieka tą pačią funkciją, kurią atlieka viena regexp’o eilutė. Tačiau nereikia pamiršti ir kito dalyko: regexp’o funkcijos dirba ilgiau negu įprastas PHP kodas. Aišku, dažnai mes to skirtumo net nejaučiame. Bet jei tinklapiui plius/minus 0.2 sekundžių skriptų darbo yra svarbu, tada verta permąstyti regexp’ų naudojimą – ar visur jie vietoj, ir ar negalima kartais to paties rezultato pasiekti be jų. Neminėsiu konkrečių pavyzdžių, bet tiesiog patestuokite puslapių užsikrovimo laiką su regexp’ais ir su analogiškais PHP elementais – dažniausiai rezultatas bus antrojo varianto naudai.
Klaida 13. Nepakankamas dėmesys saugumo klausimams
Na apie tai reikėtų parašyti atskirą straipsnį, manau taip ir padarysiu artimu laiku. Čia paminėsiu tik bendras tendencijas. Pirma taisyklė, kurią jau kažkiek minėjau aukščiau – niekada nepasitikėk lankytojais. Jei tinklapyje yra įmanoma pridaryti ką nors negero, taip būtinai atsitiks (vienas iš Merfio dėsnių). Populiariausia saugumo spraga yra SQL-injekcijų spraga. Pvz., užklausa mysql_query("SELECT * FROM users WHERE login='".$_GET['login']."' AND password='".$_GET['password']."'") yra puikus ir lengvas kasnelis hakeriams (apie SQL-injekcijas bus atskiras straipsnis). Toliau – jei nejauti kad pakankamai apsaugojai tinklapį iš programavimo pusės, daryk bent jau duomenų bazės ir skriptų kopijas reguliariai, jausies ramesnis. O apskritai, kaip sakiau, parašysiu apie saugų PHP programavimą atskirą straipsnį, čia tik pasakysiu, kad tie, kuriems atrodo, kad šiam klausimui nereikia skirti dėmesio, klysta. Kita vertus, yra neblogas posakis: nėra nieko nenulaužiamo, tik kai kurie nulaužimai per daug užtrunka, kad būtų verta laužyti.
Klaida 14. Nepatikriname failų
Dar vienas su saugumu susijęs dalykas: jei kur nors tinklapyje yra failų įkėlimo funkcija (foto, avatarai, tekstiniai failai – nesvarbu), prie jos būtiniausiai turi būti patikrinimų funkcija. Dažnai vėlgi tinklapių autoriai per daug pasikliauja lankytojais, parašo prie formos, kad tinka pvz tik JPG failai ne didesni už 2 MB. Ir galvoja, kad lankytojai šventai laikysis sąlygų. O aš galiu uploadindamas paveiksliuką, net pamiršti pažiūrėti, kad ten png o ne jpg, ir kad jis sveria 3 MB vietoj dviejų. Kas tada? Vienu žodžiu, turi būti patikrinimas pagal failo plėtinį, jo dydį, o kartais ir pagal kitus parametrus.
Klaida 15. Bandymas “dirbtinai ištaisyti” klaidas
Na ir pabaigai dvi dažnos klaidos, būdingos ne tik PHP programuotojams. Įsivaizduokite, kad sukūrėte tinklapį, kuriame pvz 50 svarbių PHP failų po kelis šimtus eilučių. Ir staiga reikia pataisyti kažkokią vieną smulkmeną, kuri kažkiek prieštarauja bendrai logikai. Na tarkime, atsiranda papildoma vartotojų grupė, kuriai reikia suteikti teises, būdingas kelioms seniau buvusioms grupėms. Jeigu tai nebuvo apmąstyta iš anksto, o reikia padaryti skubiai, tada dažniausiai kas daroma? Taip, teisingai, krūva if’ų per visą projektą, “tam, kad tiesiog veiktų”. Tai vadinčiau bandymas užlopyti skyles arba “dirbtinai ištaisyti” klaidas. Jeigu tokių atvejų būna ne vienas ir ne du, arba jei taip daroma nuolat, tada po pusės metų tinklapio kodas gali tapti visai nevaldomas. Patarimas: jei reikia padaryti kažką labai staigiai ir tai pjauna bendrą tinklapio logiką, tai galima pradžioje padaryti ir “negražiu” būdu, kurį paminėjau aukščiau, bet prie to būtinai reikia sugrįžti vėliau ir permąstyti situaciją globaliau, kad po to nebūtų dvigubai daugiau problemų.
Klaida 16. Pasirinkime teisingus pagalbinius įrankius
Ir paskutinis patarimas. Nereikia vadovautis mintimi – “Man reikia komentarų rašymo įrankio – paimsiu savo mėgiamiausią biblioteką, sveriančią 7 MB, juk ji tinka viskam”. Turiu omenyje, kad nereikia kišti į tinklapį “svetimų” klasių, bibliotekų ar funkcijų, kurių veikimas nepakankamai išnagrinėtas arba jų naudojimas per daug apkrauna puslapį. Tas pats principas tinka tinklapių kūrimui apskritai – dažnai autoriai, norintys gauti kuo daugiau naudos iš tinklapio, prikišą į jį tiek visko (skaitliukų, banerių, Google Analytics ar kitokio JavaScripto), kad tinklapis vos kruta. Bendra mintis: naudokite tik tuos įrankius, kuriuos verta naudoti.
Baigiamasis žodis: jokiu būdu nepaminėjau visų įmanomų PHP klaidų ir nepretenduoju į guru vietą, o ir pačias klaidas paminėjau tik bendrais žodžiais ir nepakankamai detaliai. Bet tikslas buvo tiesiog trumpai apžvelgti, kaip nereikėtų programuoti. Jei kam nors perskaičius šį straipsnį, norėsis pakeisti kokią nors savo tinklapio detalę arba savo PHP programavimo stilių į geresnę pusę – reiškia mano mažas tikslas pasiektas. Ateityje planuoju daugiau straipsnių apie kiekvieną paminėtą klaidą smulkiau.




2008-10-27





Spalis 27th, 2008 10:40 am
Klaida 13: SQL užklausa ne tik, kad nesaugi, bet net ir neveikianti (nebent vartotojų vardai bei slaptažodžiai būtų vien tik iš skaičių). Trūksta kabučių. Na ir aiškų escape’inimo.
Klaida 16: dviračio išradinėti iš naujo neverta. Jei reikia kažkokios funkcijos ir ji yra būtent tokia kokioje nors bibliotekoje, nėr nieko blogo imti ją ir panaudoti. PHP biliotekos, sveriančios 7 MB nėra blogai, jei bus kraunami tik reikalingi failai. Vartotojo pusėje aišku reiktų pamąstyti, ar kiekvienas javascriptas ten reikalingas, nes jis gali ir trukdyti vartotojui. Tačiau nelaikyčiau to klaida - PHP programuotojai niekuo dėti, kad svetainėje reikia ir statistikos, ir reklamų, ir dar šiokių tokių pagražinimų… O dar labiau tai jau nebe PHP programuotojų problema, o techninių dizainerių…
Spalis 27th, 2008 10:46 am
Dėl klaidos 13 - čia ant smūgio sumečiau tą užklausą, tuoj pataisysiu kad būtų aiškiau
Spalis 27th, 2008 11:00 am
Taip ir neištaisei
mysql_query(”SELECT * FROM users WHERE login=”.$_GET['login'].” AND password=”.$_GET['password'])
Rezultatas būtų pvz.:
mysql_query(”SELECT * FROM users WHERE login=petras AND password=slaptaszodis)
Taip turėtų būt:
mysql_query(”SELECT * FROM users WHERE login=’”.$_GET['login'].”’ AND password=’”.$_GET['password'].”‘”)
O tada jau galima pradėt galvot apie SQL injection’us šioje užklausoje…
Spalis 27th, 2008 11:01 am
Uu, sorry, pirmadienį iš pat ryto darbe galva nelabai veikia
pataisysiu tuoj
Spalis 27th, 2008 11:02 am
na tik aišku kabutės su šiuo fontu tai linksmai žiūrisi.. na ką padarysi
Spalis 27th, 2008 11:04 am
Jos ne tik linksmai žiūrisi, bet ir man rodos wordpressas jas sugadina (nesu tikras dėl šito), nes ten panašu, kad ne tos viengubos kabutės $_GET['login'] pas tave įrašytos, kurias kode naudoji… (Įdomu, kaip šitam komentare atrodys)
Spalis 27th, 2008 11:04 am
Čia jos berods gerai…
Spalis 27th, 2008 11:06 am
Hm, rimtai Wordpressas.. Na ok, pažiūrėsiu po poros valandų, dabar biški busy
Spalis 27th, 2008 8:41 pm
Kai kurie punktai susiję ne tik su programuotojų “klaidomis”, bet ir su saugumo reikalavimų realizacija.
Plačiau apie tinklalapių saugumą: http://lescinskas.lt/lt/blog/entry/paulius/tinklalapiu-saugumas