Interfete 4 Web - Carcoteala zilnica despre interfete web: SQL injectors si best practices in interfetele web. Exemplu curs.cs.pub.ro

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?


Reblog this post [with Zemanta]

6 comentarii:

  1. Unde ai vazut articolul initial?
    Nu de alta, dar frumos e sa citezi si sursa.

    RăspundețiȘtergere
  2. Am adaugat in articol. Este vorba despre http://web-volution.blogspot.com/2008/11/interfete-web-care-inghit-orice.html.

    RăspundețiȘtergere
  3. Am vazut si eu cum se testeaza sql injection pe site-ul de la evenimentul zilei...care mai presus de toate, daca dadeai view source page, vedeai toate interogarile bazei de date ca si comment-uri, care mai erau si functionabile... =)) sincer nu stiu ce fel de programator ar face asa ceva...sa lase toate interogarile la indemana oricui...si la un site destul de vizitat, pot spune... Concluzia, nu toti sunt programatori...multi se joaca pe bani grei in programare...

    RăspundețiȘtergere
  4. @Parazitu
    Ai dreptate. :)
    Am gasit ca si comentariu in sursa HTML de pe evz.ro asa ceva:

    SELECT a.id_article, a.title, a.description, a.status, a.teaser, a.date, a.id_category FROM `articles_has_positions` ap, articles a WHERE ap.id_article = a.id_article AND a.code & 1 AND ap.id_position = '1'AND ap.date between '2008-11-08 00:00:00' AND '2008-11-08 23:59:59' AND a.active = '1' ORDER BY ap.date DESC LIMIT 1

    Ceea ce ofera un hint ca, daca nu se fac validari de caractere in insasi baza de date, in principiu ar fi posibil un SQL injection. In plus, ne spune cat de amatori sunt minunatii programatori care au scris siteul.

    Daca vii cu demonstratie de atac incununat cu succes ( pe privat totusi) ai o bere de la mine (chiar mai multe).

    RăspundețiȘtergere
  5. O sa primesti.... =)) e facuta o parte din ea publica pe un forum... :D

    RăspundețiȘtergere
  6. Thank you very much for this article, it is so rare to see nowadays written as fervently article. I enjoyed reading it and I learned a lot of things. I will go and continue reading your blog =). Good luck for the future and another one for the quality of it.You can also check out this (http://www.sqiar.com).

    RăspundețiȘtergere