Filip Cherecheș-Toșa • Web Professional and Entrepreneur

16
Mar 08

Sfat banal pentru securitatea aplicațiilor web

Îl dă un prieten, pe noul său blog.

Pe scurt, este vorba de a avea mai mulți useri pe baza de date, cu drepturi diferite și reduse la minim ca să funcționeze OK. De exemplu, un user pentru admin panel (cu drepturi depline) și alt user pentru partea publică a site-ului (limitat doar la drepturile de care chiar are nevoie).

Pare evident să faci așa, iar atunci de ce nu am făcut-o până acum (vorbesc de mine)?
Păăăi, în primul rând, din lene. )

Glumeam…
Nu, pur și simplu nu cred că e o soluție foarte practică, în multe cazuri. Sigur, la site-uri simple la care în partea publică e nevoie doar de SELECT și, poate, INSERT, să zicem că ar merge așa ceva. Dar deja când ai un sistem de useri, cu profile, atunci ai nevoie și de UPDATE și DELETE. Iar toată ideea de useri diferiți se bazează pe restricționarea acestor instrucțiuni SQL, nu?

Problema sql injection trebuie rezolvată la sursă și anume la input-ul acceptat de la utilizatori, fie el printr-un formular, URL sau XSS. Un site securizat nu ar trebui să permită nici unui cod malicios să treacă de procesul de filtrare și validare.

Așa, pe scurt, tu ce metode de securizare folosești?

Filip Lepus

MDB2 si apoi $mdb->prepare .

Referitor la folosirea instructiunilor DELETE nu am gasit inca nici o aplicatie la care sa fie necesar delete-ul pe baza unei comenzi din front-end. Teoria pe care incerc sa mi-o impun in pracitca ar fi un UPDATE is_active=0. Decat sa stergi si sa pierzi datele mai bine le marchezi spre a nu mai fi afisate.

O alta varianta daca nu vrei MDB2, ar fi macar sa faci un class mysqli_secure extends mysqli care sa includa la absolut orice query cateva validari de baza plus un sistem de logare al query-urilor.

Cam atat, nici eu nu cred in metoda expusa de Mihai.

Adi Andreias

E adevarat ca problema trebuie rezolvata la sursa adica validari si escape-uri pe tot ce vine de la utilizator/browser.

Dar limitarile nu sunt doar pe tipuri de query-uri, cum scriai, ci si pe tabele.

justlikethat

Sincer si eu am facut faza cu userii si drepturile, adminul are un user, si front end-ul are drepturi doar de select ...

Gyorgy Fekete

MySQL predomina piata open source. In rest MSSQL.

Personal cred ca compania care inca nu a facut un update macar la MySQL 5.0 nu merita sa faci hosting...

Mihai Brehar

Din pacate multe servere de hosting ruleaza inca MySQL* 4.x unde... dupa cum bine stiti, nu exista SP-uri. In cazul in care faci o aplicatie pe care vrei s-o distribui pe o piata larga, nu prea ai de ales si renunti la SP-uri. La fel renunti la triggers, views, etc. si se pierde tot farmecul unei programari elegante.

*Nu vreau sa vorbesc despre alte DBMS pentru ca MySQL-ul predomina :P

Filip

Good point cu stored procedures! Cam aceeasi idee ar fi si cu prepared statements, nu?
Hmmm, chiar am avut la un moment dat o discutie despre utilitatea reala a SP si nu s-a adus in discutie argumentul asta, al securitatii care, cred eu, e foarte bun!

Gyorgy Fekete

Eu cred ca securitatea trebuie aplicata nu numai pe code level ci si server level. Nu neaparat prin restrictionarea userilor. Inteleg aici folosirea view-urilor, stored procedures, dar si backup.

Mihai Anca

Si eu sunt de acord cu verificarea datelor la intrare nu protejarea prin restrangerea drepturilor.
In PHP la orice query dadeam mysql_real_escape_string. In Rails folosesc validations pentru toate atributele iar la query-urile construite prin ActiveRecord face singur escaping.