M-am hotarit din mai multe motive sa ofer celor de la ejobs o consultatie pro bono pentru a intelege care este cauza si sa arat si ce ar trebui sa faca ca sa poata evita o noua problema de securitate.

Ceea ce s-a intimplat este un caz standard de SQL Code Injection. Parametrul http://www.ejobs.ro/arhiva/2007/august/PARAMETRU%20union%20select … nu este verificat. Atunci cind este interogata baza de date ceva de genul „select asta, siasta from mydatabase where zi = PARAMETRU”,  este modificat acest select si completat cu „union all select 1, concat (nume coloana,:,altnume coloana) from companies limit by nr” .  In construirea acestui statement este foarte important sa se cunoasca numele coloanelor, si numele tabelei. Modul in care se poate obtine este ori daca aplicatia intoarce erori sql, sau prin metoda de brute force.

Ce s-ar fi putut face?

1). La nivel de limbaj de programare este datoria programatorului sa scrie statementul SQL in asa fel incit sa nu permita continuarea lui. Recomand tuturor o documentatie mai veche dar buna si acum.

2) Defence in depht . Ceea ce inseamna un application firewall de genul mod_security pentru Apache care sa filtreze stringurile de genul „union all select”.

3) Design Flow. Nici o aplicatie nu ar trebui sa stocheze parolele in clar. Se pot stoca in format hash (SHA1) si verificat hash-ul parolei user-ului cind acesta o introduce.

4) Awareness. Compania ar fi trebuit sa implice pe cineva specializat in securitate pentru a testa aplicatia. Oricum se pare ca ejobs nu are nici o procedura de incident management, pentru ca lucrul pe care il face acum este sa treaca totul sub tacere.

Pentu cei care dau peste asemenea erori de securitate: exista conceptul de responsible disclosure.

O zi minunata

Anunțuri