SQL injectors si best practices in interfetele web. Exemplu curs.cs.pub.ro

Am citit de curand pe un blog un articol despre posibilitatea de atac asupra scripturilor de autentificare ce primesc parametrii din shell, precum: "auth.sh user parola" si userul malitios introduce o parola de genul "auth.sh user parola;rm -rf /"

Aceeasi idee este intalnita in foarte, foarte multe cazuti de atacuri asupra interfetelor web, dar sub o alta forma - SQL injection. Cum majoritatea interfetelor web au in spate o baza de date, orice actiune de login se va solda cu un query de genul:
"select from users where name=\"" + txtUser.text + "\" and password = \""+ txtPassword.text + "\";"
unde txtUser si txtPassword sunt doua campuri de tip text pe care le completeaza userul. Pentru utilizatorul gigi cu parola 1234, acest query va deveni, inlocuind datele select from users where name="gigi" and password = "1234"; .

Daca utilizatorului i se permite sa introduca parola sau user care sa includa caracterul ", atunci acest query se poate transforma in:
select from users where name="gigi" and password = "12";drop table users;select from log where transaction_id=""; . In acest caz, userul si-a ales parola foarte inspirat: 12";drop table users;select from log where transaction_id=" .

De la aceasta idee simpla a pornit o intreaga industrie a hackerilor. Sunt faorte multe posibilitati de ataac, toate cu aceeasi baza. Daca va intereseaza subiectul, puteti citi mai multe aici.


Totusi, lucrurile nu sunt atat de rele pe cat par; majoritatea interfetelor web sunt sigure:

• Hackerul trebuie sa conoasca structura tabelelor, cel putin un pic. Acesta se poate ghici dar nu e chiar asa de usor.
• De obicei nu se trimite parola in clar, ci se aplica asupra ei, local, pe masina utilizatorului, o functie care produce un hasth al acesteia. La server se compara hashurile pentru acordarea accesului. Cum controlul asupra hashului nu apartine hackerului, este destul de greu sa mai foloseasca pentru atac campul parola. Ramane campul utilizator.
• Daca programatorul foloseste un framework de dezvoltare web si nu scrie codul de la 0, probabilc a exista deja protectie impotriva acestui tip de atatc. Daca acest lucru nu se intampla insa, protejarea cade in sarcina programatorului. Daca acesta nu este foarte junior ;) probabil va interzice prezenta caracterelor \ si " in campurile sensibile (care ajung sa fie introduse intr-un query, sau le va escapa inainte. Nu doar cele care ajung in query-ul de log in, ci in toate query-urile,c a sa nu alse vreo gaura in securitate.) E bine sa programezi defensiv.)

Sa analizam cazul curs.cs.pub.ro, care foloseste aplicatia CMS (Course Management System, nu Content Management System de aceasta data) Moodle. Conturile sunt facute de un admin specializat la noi in facutalte. Parola in schimb, se poate schimba la discretie. Un coleg mi-a povestit, acum cateva luni cum si - a schimbat el parola sa includa " . Si a mers. Doar ca mai apoi, nu s-a mai putut loga pe site deloc. :) Interesant. Problema a fost expusa la nivelurile superioare de decizie. Ce s-a intamplat de atunci , nu stiu si pe siteul Secunia nu a mai aparut o avertizare de posibil SQL injection pentru Moodle din 2005.

Voi ati intalnit personal situatii in care atacuri de acest tip, au provocat probleme?
Interfetele web facute de voi cum stau la capitolul asta? In ce layer puneti codul de verificare?