joi, octombrie 11, 2012

Posibile probleme de securitate (Web - Java)

Enumar un set de probleme de securitate care pot afecta aplicatiile Web si posibile solutii (in particular aplicatii Java bazate pe containerul de servlets). Am pastrat titlurile tipurilor de atac in engleza. Am sa incerc sa mentin lista si sa adaug si altele noi.

SQL INJECTION

Problema: din cauza crearii de query-uri SQL, HQL, JPQL concatenate folosind String-uri este posibil ca continutul introdus de utilizator sa expuna date din baza de date

Solutie: trebuie verificat ca toate query-urile sunt parametrizate folosind engine-ul de persistenta care escapeaza caracterele speciale in mod automat.  

XSS - STORED 

Problema: continutul introdus in pagina este salvat in baza de date si apare in paginile altor utilizatori (pe comments, etc); odata incarcata pagina scriptul se executa si poate trimite SESSION ID sau alte informatii la o adresa data

Solutia: escape in momentul randarii continutului dinamic (Grails: encodeAsHTML(); encodeAsURL() sau folosind ESAPI); Trebuie urmarit ca utilizatorii cu drepturi mai putine sa nu infecteze pe cei care au drepturi mai multe; spre exemplu un form de sugestii accesibil fara autentificare poate ataca prin injectare direct aplicatia de administrare; utilizatorii se pot infecta intre ei printr-un forum in care isi trimit unul altuia comentarii

XSS REFLECTED

Problema: un parametru proaspat introdus este afisat pe site fara escape; un user poate forma un url folosind acest parametru pentru a injecteaza JS in pagina si invita pe altii sa vada acest URL; la randare se executa scriptul respectiv (se poate fura session id)

Solutia: escape in momentul randarii valorii parametrilor care vin direct din request (Grails: encodeAsHTML(); encodeAsURL() sau folosind ESAPI)

MAN IN THE MIDDLE

Problema: chiar daca unele pagini au SSL (pagina de login sa zicem sau cele care contin date despre carduri - IBAN-uri) si nu se poate vedea spre exemplu parola sau alte date confidentiale de pe aceste pagini, pe paginile care nu au SSL pe acel site se pot totusi vedea alte date precum SESSION ID cookie care pot fi folosite pentru session hijacking;

Solutie: tot site-ul trebuie pus pe SSL pentru a evita orice furt de session id; trebuie stabilit daca site-ul contine date de business care pot afecta grav pe utilizator caz in care se face total SSL (exemplu ar fi aplicatiile Google care sunt total sub SSL certificat) sau este un site de entertainment caz in care se poate pune SSL doar pe unele pagini; in orice caz in site este recomandat ca schimbarea de parole sau date importante sa se faca cu parola curenta


DENIAL OF SERVICE

Problema: un user rau intententionat poate incarca sistemul prin apelari succesive de operatii costisitoare facandu-l sa cada sau sa se blocheze (se poate folosi orice tool de load prin inregistrare de scenariu via proxy si repetarea lui paralelizata); chiar daca aplicatia nu este blocata, se pot incarca costurile de hosting daca plata se face per resurse consumate (rularea injectorului poate fi fara sfarsit spre exemplu)

Solutie: folosirea de form token-uri (mecanism deja implementat in Web frameworks: Struts sau Grails) care ar face ca request-urile de pe aceeasi sesiune sa se execute oarecum secvential; trebuie tinut cont ca sesiunile/IP cu care sunt trimise cererile pot fi diferite si deci aceasta solutie este doar partiala; introducerea de limite clare pentru a diminua complexitata operatiei

BRUTE FORCE

Problema: este posibila incercarea de a face brute force pe pagina de login (sau orice pagina care implica credentials) prin incercarea repetitiva a unui numar mare de parole (folosind dictionare si/sau rainbow tables)

Solutiii: introducerea de CAPTCHA pe pagina dupa un numar de incercari (per IP si/sau session); suplimentar, folosirea de token-uri ca in Denial of service (ar opri paralelismul doar la nivel de sesiune); cea mai buna idee este audit pe login pentru a vedea IP-urile de unde vin atacurile (cereri multiple) si a le bana pentru un timp; o alta solotie este blocarea contului dupa un numar de incercari si deblocare la cerere; de tinut cont ca request-ul se poate face prin proxy care poate schimba ip-ul la nivel de protocol inainte de a atinge aplicatia tinta; de asemenea id-ul de sesiune poate fi schimbat mai ales daca pagina atacata nu este sub autentificare


GUESSABLE ID's

Problema: in aplicatie se vehiculeaza id-uri din baza de date (nu neaparat vizibile in query string: hidden fields, cookies, sau parametri vizibili in consola browserului/mesahe HTTP); de obicei id-urile din baza sint consecutive si deci sunt usor de intuit; userii cu aceleasi roluri in aplicatie pot sa vada date ale altor useri care au acelasi rol ca ei

Solutia: de evitat folosirea de id-uri in aplicatie; verificarea conditiilor de business cand se fac cereri cu id-uri (daca userul logat are voie sa le vada); folosirea altor identificatori (folosinf URL rewrite) care sa nu fie usor de ghicit (nume in loc de id daca de exeplu numele este oricum public - trebuie sa fie si unic)


WRONG URL ACCESS

Problema: este posibil ca rolurile sa nu fie bine puse pe pagini astfel incat unele pagini pot fi vazute de cei care nu au dreptul; acelasi lucru pentru apelurile de AJAX - fragmente de pagini pot ramane nesecurizate; sau unele pagini de administrare ale aplicatiei au ramas expuse dupa ce dezvoltarea s-a terminat - eventual consola de server, etc; sau erorile aplicatiei sunt logate direct in productie atunci cand se intampla

Solutie: trebuie intretinuta mereu o lista de pagini cu rolurile asociate (trebuie sa fie acoperita declarativ cu rolurile corespunzatoare in web.xml in cazul securitatii clasile JEE, security.xml sau la nivel de controlere cu adnotari in Spring); la aparitia unei erori se va redirecta spre o pagina cu eroare (404 - page not found; 403 - no rights for this page; 500 - server internal error)