Conditii minime de securitate pentru aplicatiile web

Prezentul articol va dezvaluie cateva conditii minime de securitate pentru aplicatiile web. Eu sunt dezvoltator de aplicatii web si am ceva experienta la activ, peste 12 ani. Am dezvoltatat platforme si aplicatii web, unele dintre ele necesitand conditii de siguranta sporita. De exemplu platforma ce-faci.ro sau talk-social.eu. Lucrez cu algoritmi de criptare, iar securitatea este unul dintre dezideratele principale ale platformelor web pe care le dezvolt.

De acceea am hotarat sa va spun cateva dintre cerintele esentiale in ceea ce priveste securitatea aplicatiilor web.

1. https. Asta inseamna transmitere de informatii criptate intre computerul tau si server. Platforma trebuie sa aiba redirectionare automata de la http la https (de obicei se face din htaccess). Daca nu are, evita sa-ti introduci datele personale si parolele acolo. Sau evita ca utilizatorii tai sa faca asta Cum verifici asta? Inlocuiesti in orice link din platforma https cu http si vezi daca atunci cand dai enter se ramane pe http sau se duce pe https.
2. tranmiterea de date criptate intre paginile aplicatiei. Intre paginile aplicatiei/platformei web se transmit date de la o pagina la alta sau de la scripturile javascript la server (prin POST si GET). Aceste date trebuie sa fie criptate. Daca sunt transmise in clar reprezinta o problema de securitate care poate fi exploatata de un hacker. Cum poti verifica asta? Intri in meniul browserului si in developer tools, iar de acolo slectezi netwrok. Si vezi cand se executa scriptul si te uiti sa vezi cum se transmit datele. E un pic mai complicat asta pentru un utilizator normal, dar puteti apela la mine sa va verific asta.
3. username diferit de adresa de email. Este o functionalitate care ii da mai mare bataie de cap hackerului. Adresa de email e posibil sa ti-o stie (din listele de pe darkweb, de exempluu), dar username-ul pentru acea platforma e mai greu sa-l ghiceasca sau sa-l stie.
4. parole complexe. Platforma trebuie sa te lase sa iti alegi platforme complexe mai mari de 6 caractere, preferat 8 sau 12. D efapt ar trbui sa t eblocheze daca parola are mai putin de 6 caractere si nu contine litere mari, cifre si caractere speciale
5. recuperarea datelor daca ai uitat parola. Multe platforme au facilitatea asta, e un must in ziua de azi! Emailul care se tirmite contine, de cele mai multe ori, un link, Acel link trebuie sa aiba portiunea de la final criptata. Adica codul de autentificare trebuie sa fie criptat. Asta o vedeti in linkul trimis pe email. Aplicatia nu trebuie sa-ti trimita prin email o parola provizorie deoarece orice indiviv rau voitor iti poate bloca accesul la cont generand aceste parole provizorii. Asta da batai de cap utilizatorilor.
6. protectie la atacuri de tip XSS. Aceste atacuri implica introducerea de cod javascript in formularele aplicatiei/platformei. Daca variabilele preluate din formular nu sunt sanitizate acest cod va fi introdus in codul aplicatiei, si se va executa de fiecare data cand utilizatorul apleaza acea sectiune, fara ca utilizatorul sa stie. Acest cod poata sa fie, de exemplu, un keylogger care sa inregistreze tot ce tasteaza utilizatorul. Puteti verifica asta introducand cod javascript in formular si sa vedeti cum il gestioneaza aplicatia. Va pot ajuta eu sa verificati asta!
7. protectie la SQLInjection. Presupune injectarea de cod SQL in formularele aplicatie, cod care va fi executat in baza de date. Se poate intampla asta daca variabilele nu sunt sanitizate. Asta poate face ca un hacker sa afiseze in paginile aplicatiei lista cu toti utilizatorii si datele lor, de exemplu. Atacurile XSS si SQLInjection se bazeaza pe erori de programare. Se poate verifica prin introducerea de cod SQL in formular si sa vezi cum il tateaza aplicatia. Va pot ajuta eu cu asta!
8. limitarea tipurilor de fisere care se incarca in aplicatie. Asta daca e cazul! Utiliatorul nu poate incarca orice fel de fisere in aplicatie(verificarea se face pe extensii, de obicei). De obicei, cerinta asta e rezolvata de platfoermele existente.
9. coduri capcha si limitarea numarul de incercari de autentificare. Aplicatia trebuie sa aiba coduri capcha pentru a evita atacuile de tip brute force. La fel, in formularele de autentificare, trebuie sa permita autentificare gresita de cel mult 3 ori. Atentia ca platformele de bloggind si unele magazine virtuale nu fac asta in mod implicit, va trebuie module suplimentare pentru asta.
10. erorile de autentificare. Aplicatia/platforma nu trebuie sa spuna explicit ce nu e in regula la autentificare. De exemplu daca combinatie username si parola nu e ok, nu trebuia sa spuna ca parola nu e buna sau ca username-ul nu e ok.
11. Erorile aplicatiei afisate in paginile web sau in consola. E o setare de server si nu trebuie afisate. Unele tehnici de hacking se bazeaza pe fortarea serverului sa genereze erori, erori care pot da informatii valoroase hackerului.
12. coockiuri. sa nu uitam de GDPR. Platforma trebuie sa il lase pe utilizator sa aleaga daca doreste sau nu cookiurile neesentiale. Atentie foarte mare aici deaorece platformele de blogging sau magazine viirtuale nu anuleaza cookiurile chiar daca utilizatorul a ales asta. E foarte greu sa controlezi cookiurile pe care diversele module ale platformei le aloca utiilizatorilor. De aceea aveti foarte mare grija la wordpress si la platformele de magazine virtuale pentru ca se poate lasa cu amenzi mari de la data protection. Poti vedea asta tot in meniul Developer tool la sectiunea storage. Va pot ajuta eu sa vedeti asta daca nu stiti cum sa o faceti. Si va pot auta si sa gestionati acele coockiuri nedorite. Adica la coockiurile de facebook (pe care le introduce pixel) si la cele de la google analytics. Astea nu sunt coockiuri esentiale pentru ca aplicatia poate functiona si fara ele.
13. datele personale ale utilizatorilor sa fie criptate in baza de date. Adica numele, prenumele, adresa de email, CNP-ul, numarul de telefon sau adresa clientului, IP-ul sa fie anonimizat. Sunt datele pe care le stocheaza marea majoritate a platformelor si, de obicei, ele nu sunt criptate in paza de date (unul din motive este ca ele sunt folosite si de modulele alltor dezvoltatori). Atentie la platformele de blogging si la platformele de magazine virtuale. Se poate verifica asta in baza de date! Va pot ajuta eu daca nu stiti cum.
14. stergerea datelor personale ale utilizatorilor. La cerere, conform GDPR trebuie sa stergeti datele utilizatorilor din baza voastra de date cat si din ale partenerilor vostri. Atentie din nou la google analitycs si facebook pentru ca nu puteti sterge datelor utilizatorilor vostri de acolo. Daca datele sunt criptate in baza voastra de date va trebui sa puteti identifica prin platforma utilizatorul si sa-i puteti sterge datele din toate modulele. Dezinstalarea unor module care preiau date de la voi nu inseamna ca proprietarul acelor module a sters datele utilizatorilor vostri si ca a anulat coockie-ul intordus anterior. Apropo, voi nu titi si nu controlati ce date iau mdulele de la voi , unde si cum le stocheaza. Mai ales daca le stocheaza pe serverul lui, al dezvoltatorului modulului.

Dupa cum vedeti sunt 14 cerinte simple (cel putin pentru un programator) si sentiale pentru a avea un site sigur si pentru proteja datele utilizatorilor. Nu e nevoie sa aveti acces la codul aplicatiei sau sa integeti codul pentru a verifica aceste aspecte. E nevoie in schimb de accesul la baza de date si de ceva cunostiinte a structurii bazei de date pentru a verifica unele din aspectele de mai sus.

Daca ai nevoie de ajutor ma poti solicita si te ajut cu mare placere. Ai datle mele de contact la sectiune contact a acestui site.