Soluţii - PC Magazine Romania, Iulie 2004

Securitatea aplicaţilor JSP

Mircea Scărlătescu

Securitatea siturilor web este o problemă mereu la modă în această perioadă. Dacă la începutul anilor ´90 siturile web erau doar o înlănţuire de texte şi imagini, reprezentând mici şi nesemnificative prezentări ale unor idei sau servicii, astăzi majoritatea serviciilor oferite de firme sunt dublate de o variantă electronică, disponibilă pe web. Din păcate insă, securitatea este o problemă care devine din ce în ce mai greu de asigurat, o dată cu diversificarea serviciilor electronice şi cu accesul la acestea.

Tocmai accesul pe diferite canale (din ce în ce mai multe) la paginile web, începând cu "clasicele" calculatoare, şi continuând cu device-urile de gen PDA, sau telefoane mobile face ca problema cea mai mare a securităţii să devină restricţionarea acestui acces pentru cei rău intenţionaţi. Un hacker va încerca mai intâi să spargă un sit prin canalele pe care un utilizator corect le foloseşte pentru a comunica cu situl (formulare de preluare a datelor etc). Doar dacă aşa nu va reuşi va încerca şi metode ceva mai avansate, sau şi mai bine, va renunţa.

Metoda imediată de protejare a siturilor împotriva acestui gen de atacuri este reprezentată de validarea input-ului de la utilizator.

În cele ce urmează încercăm să prezentăm o serie de strategii de implementare a aplicaţiilor web privind în special validarea input-ului de la utilizator.

Tehnologiile JSP facilitează, aşa cum ştiţi deja, realizarea de conţinut dinamic pentru mediul World Wide Web prin introducerea de cod Java în cadrul documentelor de tip HTML. Paginile JSP sunt parsate şi convertite de motorul Java în Servlet-uri (serverul web JavaEnabled). Aşa cum aţi putut vedea în numerele anterioare, JSP-ul oferă multe tag-uri asemănatoare cu HTML care interacţionează cu baze de date şi obiecte Java pentru a produce conţinutul dinamic.

Pentru cei care sunt familiarizaţi cu modul de lucru CGI, tehnologia JSP îmbunătăteşte mult acest protocol, în domeniul sesiunilor, a conexiunilor persistente. Se ştie că în general un proces CGI era distrus mereu odată cu închiderea parsării scriptului, însă în JSP conexiunile persistente permit o implementare mult mai eficientă a acestor procese.

Trebuie precizat faptul că Java rezolvă multe din problemele de securitate pe care le aveau limba-jele de programare mai vechi. Colectarea variabilelor nefolosite, accesul la pagini etc. sunt mult mai bine tratate, facând astfel ceva mai grea spargerea unei aplicaţii web JSP.

Nu trebuie înţeles că este foarte greu să scrii cod JSP care să nu fie securizat suficient. De asemenea trebuie avut în vedere că arhitectura JSP este destul de complexă şi complicată pentru cei neexperimentaţi, iar din interacţiunea incorectă între acestea pot apărea găuri de securitate.

Despre utilizatori, îmi aduc aminte de un stimat profesor al catedrei de calculatoare din Facultatea de Automatică Bucureşti, care ne spunea la cursurile lui că toţi utilizatorii trebuie consideraţi în cadrul etapei de programare ca fiind stupizi şi rău intenţionaţi. J Desigur, toţi am luat-o atunci ca pe o glumă, dar dupa ani şi ani de experienţă sfatul lui nu mai pare chiar aşa de neadecvat. Aşadar cam orice input de la utilizator trebuie să fie validat şi verificat astfel încât să conţină doar elementele ce nu pot pune în pericol intergritatea datelor din sistem.

Dar, de fapt, ce înţelegem prin input de la utilizator? Orice informaţie venită prin: URL-uri (protocolul GET), formulare (protocol POST), cookie-uri şi altele.

Problemele apar atunci când un atacator încearcă să execute diferite comenzi sau scripturi care nu trebuie să fie executate decât de persoane autorizate.

Spre exemplu, prin intermediul clasei Runtime metoda exec() poate executa o comandă pe server, ceea ce pentru un hacker reprezintă o ocazie excelentă de a accesa părti ale sistemului, care în nici un caz

nu-i sunt permise. Să ne imaginăm doar cazul în care acesta încearcă şi reuseşte să schimbe parola de root a unui server web ce rulează pe Linux. Consecinţele sunt uşor de imaginat, iar munca de reparare a pagubelor de multe ori înseamnă refacerea întregului sistem.

Un alt exemplu de atac este încercarea de a identifica resursele pe care un script le utilizează pentru a funcţiona corect. De exemplu, un hacker poate încerca să afle parola de acces la o bază de date folosită de script, având acces astfel direct la date (e uşor de ghicit în ce scop: rularea de interogări şi comenzi SQL pentru a prelua sau distruge informaţii senzitive pentru sistem). Un exemplu în acest sens este reprezentat de mediatizatul caz în care un hacker din Marea Britanie a reuşit să acceseze baza de date a companiei de telefonie mobilă unde era abonat, şi a vorbit pe gratis destul de mult timp - nu încercaţi aşa ceva acasă! ☺

Validarea datelor trimise de un utilizator reprezintă verificarea sintactică a input-urilor (uneori şi semantică). Dacă apar erori sau elemente neconforme, sunt mai multe posibilităţi de a "ataca" situaţia:

• eliminarea (ignorarea) elementelor neconforme;
• înlocuirea elementelor nesigure sau nelegale cu altele acceptate;
• raportarea unei erori către utilizator (cel mai întâlnit caz);

Datele transmise prin protocolul GET reprezintă cea mai veche metodă de transmitere a datelor, şi în mod cert cea mai demodată şi nerecomandată. Astfel GET-ul încapsulează datele transmise în URL, şi este cam cel mai uşor mod de a-ţi face public date ce nu ar trebui să ajungă aşa. În primul rând, datele pot fi citite "cu ochiul liber", pot să fie memorate de browser (în secţiuni precum HISTORY, sau altele de acest gen), şi cel mai grav pot să fie logate (trecute în log-uri de activitate) atât de servere proxy, cât şi de routere sau alte echipamente inteligente de reţea. Astfel, transmiterea de parole, date de acces la baze de date sau alte date senzitive prin GET reprezintă o invitaţie evidentă pentru un hacker. O precizare importantă aici, din punctul de vedere al JSP, datele din GET sau POST (metoda recomandată în acest caz) sunt tratate la fel, deci programarea nu devine mai dificilă dacă nu folosim GET.

Conceptul de cookie a fost introdus de Netscape, şi reprezintă o informaţie stocată la client, care este folosită la o reaccesare a unui sit pentru a continua o sesiune începută înainte, sau în diferite alte scopuri. Şi JSP foloseşte metode specifice cu acest tip de date (mai bine zis tip de stocare a datelor). Există o clasa specială pentru lucrul cu ele, denumită javax.servlet.http. Cookie. Sunt două motivele pentru care nu trebuie să vă bazaţi prea mult pe cookie-uri atunci când lucraţi la un site web. Datele stocate sunt vizibile oricând local pentru utilizator, deci datele sensibile nu trebuie stocate astfel, şi în al doilea rând, un hacker poate modifica oricând aceste date în scopuri maliţioase.

Folosirea JavaBeans

Componentele reutilizabile JavaBeans oferă o funcţionalitate sporită siturilor realizate în JSP. Un Bean va conţine proprietăţi care sunt iniţializate de către situl respectiv prin transmiterea de parametrii, iar funcţionalitarea unui Bean respectă conceptul de "cutie neagră" (black box): ne interesează doar rezultatul operaţiilor, nu şi modalitatea de realizare. Astfel, proprietăţile unui bean se vor iniţializa prin declaraţii de tip nume=valoare. Iată şi un exemplu:

 <jsp:useBean id="boabaJava1"
class="BoabaJava">
<jsp:setProperty name=" 
boabaJava1" 
property="*"/>
<jsp:useBean>

Prin declaraţia de mai sus, toate proprităţile beanului se iniţializează prin URL (notaţia *). Prin această metodă, toate datele vor fi construite din sit şi transmise în clar. Problema apare în momentul în care un hacker încearcă să transmită date eronate care vor afecta funcţionalitatea acestui bean, şi-l vor face să nu mai funcţioneze corect, să dea rezultate neaşteptate sau chiar ascunse în mod normal. Soluţia în acest caz este reprezentată de metode de verificare a datelor introduse.

O problemă sensibilă în cadrul implementării cu multe variante de JSP este reprezentată de ascunderea codului JSP. Desigur, orice aplicaţie web trebuie să prezinte doar rezultatul rulării codului, nu şi sursa. Însă într-o variantă Allaire´s JRun spre exemplu, dacă URL-ul de apel conţinea la sfârşit .jsp%00 atunci server-ul nu recunoştea această pagină ca fiind una JSP, nu o parsa şi trimitea pagina ca fişier text la client, afisând astfel tot codul JSP (se ştie că orice server web, atunci când întâlneşte o extensie pe care nu o cunoaşte, interpretează cererea ca fiind una pentru un fişier text, şi trimite ca atare răspunsul la client). Într-o problemă similară, sever-ul Tomcat (o versiune a acestuia) avea un bug de acest gen: la tastarea adresei:

http://server/page.js%2570

serverul era păcălit, pentru că în codarea URL a lui % este de fapt %25 iar 70 este codarea lui p. Dar, pentru că extensia nu era clar .jsp, server-ul nu invoca maşina Java pentru parsare, ci returna documentul în clar.

De asemenea, dificultatea de a învăţa la început JSP-ul a fost rezolvată parţial de producătorii de servere web prin prezentarea unor exemple de scripturi, şi includerea lor în distribuţii. Problema e că de multe ori aceste scripturi conţineau bug-uri de securitate importante, care în cele mai multe cazuri au devenit publice, şi într-un mediu precum Internetul au fost exploatate.

De aceea, aceste exemple se recomandă a fi eliminate la instalarea unei maşini pe web.

De asemenea, după alegerea unui server pentru rularea de aplicaţii JSP, administratorii de sistem trebuie să verifice cât mai des siturile producătorilor, pentru a instala eventuale patch-uri pentru servere, sau pentru a respecta anumite indicaţii din partea producătorilor.

Concluziile, după acest scurt studiu de caz al problemelor de securitate ce afectează tehnologia JSP (dar nu numai), sunt că nici un server nu este perfect, şi că scăpări în programare au şi cei mai importanţi producători, dar şi că programarea web este din punct de vedere al securităţii poate cea mai dificilă ramură a programării. Sfaturile de mai sus, sunt desigur doar începutul. Tristul adevăr este că întodeauna hacker-ii vor fi cu un pas în faţa celor ce programează.

Desigur, reversul medaliei este că încet-încet prin învăţarea din alte atacuri reuşite, situl propriu poate să fie aproape perfect…

Mult succes!