Skip to content

Securitatea scripturilor PHP partea 1

  • by

lant Nu stiu câţi au apelat la firme externe pentru a realiza un site cu conţinut dinamic. În majoritatea cazurilor in România site dinamic se confunda cu LAMP ( Linux+Apache+MySQL+PHP ). Aparent toate bune si frumoase. Pînă cînd vine vorba de security.Multe firme sint în stare sa creeze un design decent pentru site. Cosmarul incepe in momentul in care acel site trebuie pus online. Majoritatea nu au NICI o verificare de variabile. Si acele site-uri ajung online. In 90% din cazuri sufera de buguri incepind cu path disclosure si terminind cu SQL injection sau remote scripting inclusion.

Erorire cele mai frecvente sint constructii de genul:

$sql = "SELECT * FROM newstable WHERE nid = ".$id." LIMIT 1"; $sqlresult = execute_sql($sql);

Imaginati-va ca un “binevoitor” apeleaza scriptul cu id=0 and 1=0 union select user,password from MySecretAuthTable /*

Si uite asa se pot obtine o gramada de informatii “interesante”.
Faceti un mic test. Luati primele 10 site-uri facute in php din oricare top vreti si intrati pe cite un site si incercati sa inlocuiti variabilele numerice cu “a” . De exemplu daca un paramentru este id=123423 inlocuriti cu id=a

Cite ati gasit cu erori de genul asta? Eu am gasit alarmant de multe.
Adevarata problema incepe in moementul in care notifici “ownerii”. Incepe un adevarat circ . In prima faza tratementul de care beneficiaza cineva care raporteaza buguri este ceva de genul:

“io-te’l ba si p’asta . Crede ca a descoperit un bug in super site-ul nostru. ce idiot … n-are ce face decit sa stea toata ziua sa sape dupa prostii.”

Dupa care incepe faza de negare: “Asemenea erori nu exista…. Nu se poate domnule greşiti dumneavoastră …. Dar cine v-a dar voie sa va jucati cu parametrii asa?!?!”
In 90% din toate cazuri s-a incercat minimizarea efectelor potentiale? ” Si ce daca afla hash-ul parolei de administrare? E criptat. Nu poate sa faca nimic cu el” ( asta era unul din cazurile in care parola era “test1” ) sau “N-am domnule date importante pe serverul ala. E la provider. Eu imi tin documentele pe laptop”.

Ce se poate face? Parerea mea este ca trebuie dusa o lunga munca de lamurire cu beneficiarii site-urilor. In al doilea rind un minim de verificare de securitate este absolut necasar. Este adevarat ca un audit de securitate pentru un web site creste pretul produsului. Dar beneficiile sint mari. Nu sint beneficii directe. In prima faza clientului care plateste mai mult i se pare nerentabil , dar in momentul in care i se modifica informatiile de pe site, incepe sa urle si sa se agite. Prea târziu însă.

3 thoughts on “Securitatea scripturilor PHP partea 1”

  1. Si mai frumos e cind ii auzi pe unii… altii .. “e pe linux/php.. deci e securizat”.. “se sparge greu ma unix-u”.

    S-a dus vremea cind pentru a instala o distributie de linux trebuia sa-ti compilezi singur modulele… si aveai nevoie de cunostinte serioase de tcp-ip … traiasca wizzarduu…

Comments are closed.