IPRO - PC Magazine Romania, Aprilie 2004
SOLUŢII PENTRU PROGRAMATORII ŞI DESIGNERII WEB

Securitatea aplicaţiilor Web

Mircea Scărlătescu

Nu mai sunt prea mulţi cititori de ziare sau telespectatori care să nu fi aflat de viruşi, despre atacuri asupra paginilor web, asupra calculatoarelor şi alţi astfel de termeni care se vehiculează în presa noastră, nu întodeauna în cunoştinţă de cauză.

Atacurile informatice reprezintă un subiect la modă peste tot, şi împreună cu spamul probabil că oferă o sursă bună de venituri companiilor care se ocupă cu soluţii de securizare infromatică.

Vei găsi sute de cărţi, unele de calitate îndoielnică despre securitatea siturilor web, şi cum să vă transformaţi situl într-unul aproape imposibil de spart sunt însă destul de triste: situl 100% securizat nu există. Pentru că întodeauna se va găsi cineva care să ştie o portiţă de evitare a vreunei politici de securitate. Ceea ce poţi face însă este să încerci să reduci riscul de a fi afectat, aplicând o serie de strategii care deşi sunt simple, sunt ignorate de cei ce construiesc un sit, şi de cei care-l administreaza ulterior.

Ceea ce vei citi în cele ce urmează reprezintă o serie de sfaturi utile şi la obiect, fiind aplicabile pentru majoritatea siturilor prezente online la această oră.

O primă regulă nescrisă a securităţii web este să nu ai niciodată încredere în utilizatorii sitului tău. Şi asta pentru că dacă 90% din cei ce intră pe un sit, o fac pentru a afla câte ceva nou, sau pentru a găsi materiale interesante pentru ei, rămân 10% care îţi poate da o durere serioasă de cap J. Sunt acei vizitatori care încearcă să descopere diferite vulnerabilităţi ale sistemului, începând cu găsirea de parole şi spargerea de conturi ale utilizatorilor "cinstiţi" şi până la distrugerea sitului (blocarea acestuia, alterarea informaţiilor de pe sit, sau copierea bazei de date, dacă aceasta prezintă interes).

Interacţiunea cu utilizatorii capătă prin prisma celor de mai sus o importanţă deosebită. Astfel, orice formular în care un user îşi introduce date, sau poate stoca în baza de date informaţii trebuie să fie bine procesat, din punctul de vedere al conţinutului. Este nerecomandabil să accepţi pe un sit ca un utilizator să încarce cod HTML sau JavaScript. Un utilizator rău intenţionat poate încerca să încarce cod care ulterior accesat poate să blocheze diferite secţiuni ale sitului, sau mai rău, să transmită informaţii către locaţii unde nu ar trebui să ajungă. De asemenea, dacă baza de date nu acceptă valori nule în înregistrările sale, trebuie să verifici ca datele introduse corespund acestei cerinţe. Datele care au un format specific, cum ar fi date calendaristice, ore, coduri poştale, adrese de e-mail trebuie să fie validate pentru a corespunde unor formate standard. Validarea din acest punct de vedere se va face cu uşurinţă utilizând JavaScript.

O greşeală frecventă care trebuie evitată este reprezentată de utilizarea altor extensii în numele fişierelor, în afara celor recunoscute de server. Să dăm un mic exemplu. Dacă într-o aplicaţie web dorim să introducem un fişier care să conţină date de gen parole de conectare la baza de date, sau alt tip de constante, atunci foarte mulţi programatori vor face greşeala de a redenumi acel fişier şi a-I asigna o extensie de gen inc, txt, con sau alte denumiri de acest gen. Surpriza neplăcută pe care o vor avea este că dacă serverul web nu recunoaşte tipul fisierului, atunci îl va trata ca şi fişier text, şi-l va afişa ca atare. Astfel, date critice ale aplicaţiei vor fi disponibile pentru oricine. Această greşeală poate fi uneori fatală pentru aplicaţii care folosesc baze de date. Compromiterea bazei de date reprezintă pentru un sit dinamic imposibilitatea de a mai funcţiona corect. Pe lângă funcţionalităţile care se pierd, datele pot fi exploatate de către o persoană rău-voitoare, iar pagubele în acest caz se pot mări considerabil.

Un alt exemplu de cod nesecurizat, mult prea întâlnit pe siturile româneşti este reprezentat de includerea de nume de fişiere sau de date confidenţiale în transferul datelor din formulare prin metoda GET. Fără a intra în detalii trebuie să spunem că metoda GET concatenează la URL-ul scriptului de prelucrare a datelor şi conţinutul formularului apelant. Spre exemplu putem întâlni un apel după cum urmează:

http://www.site.ro/login.php?
user=user2004&parola=pcmagazine.

Nu e nevoie să mai insistăm asupra consecinţelor pe care o astfel de metodă o poate avea asupra securităţii unui sit. Conturile de acces pot fi compromise extrem de uşor, un browser cu opţinea de "history" putând să reţină extrem de multe parole în acest mod. Accesul la fişiere ce nu sunt accesibile utilizatorilor (şi nici nu e cazul să fie) poate fi înlesnit de implementări de genul:

http://www.site.ro/display
php?file=pcmagazine.html

Aşadar, utlizarea metodei GET pentru transmiterea datelor din formulare trebuie să fie facută cu mult discernământ.

Pentru că în exemplul de mai sus avem parte de "clasicul" deja tandem username - parolă, trebuie să mai facem o precizare despre acest sistem de autentificare. Dacă stocarea acestui tip de date se face în baze de date, aşa cum se întâmplă în majoritatea cazurilor, atunci mare atenţie trebuie să fie acordată modalităţii de interogare a bazei de date la autentificare. Un programator (nu foarte valoros) vă poate spune că e uşor să realizezi un program scurt care să încerce să afle o parolă folosind un "dicţionar", adică un fişier care conţine foarte multe cuvinte, iar metoda de găsire este reprezentată de "ghicirea" parolei (se testează rând pe rând fiecare cuvânt din dicţionar). O protecţie pe cât de simplă pe atât de eficientă este reprezentată de numărul limitat de încercări de autentificare în sistem. Astfel, după 3 încercări nereuşite de autentificare, sistemul poate să afişeze direct mesaj de eroare, fără a mai verifica dacă parola este corectă. Astfel, pentru a putea să se autentifice, un user trebuie să reiniţializeze sesiunea, prin închiderea ferestrei browserului. Un program care încearcă să fure o parolă nu poate realiza acest lucru prea uşor, deci problema este eliminată. Poate vă întrebaţi de ce accesăm baza de date de doar trei ori… răspunsul este că numărul 3 pare să se fi impus în acest tip de scripturi de autentificare. Sistemul s-a extins şi la autentificarea SIM-urilor pentru telefoanele mobile. Desigur, puteţi să înlocuiţi numărul de încercări cu orice valoare dorită, chiar şi 1.

Exemplele de mai sus sunt desigur doar elemente menite să pună bazele în securizarea unui site. Munca depusă poate să fie destul de anevoioasă, şi este posibil să descoperi că multe module ale aplicaţiei nu corespund cererilor din ziua de azi în ceea ce priveşte securitatea. Dar dacă am reuşit să te facem să te gândeşti cel puţin 5 minute la cât de important este să realizezi situri calitative din punctul de vedere al securităţii, atunci vizitează situri precum www.securityfocus.com unde tehnicile de protecţie sunt explicate mult mai pe larg, şi nu numai pentru aplicaţii web.

Mult succes!