Securizarea unei

aplicatii web
Autentificare, autorizare, state management intr-un mod sigur
Ce inseamna o aplicatie sigura?
▪ HTTPS
▪ Managementul Identitatii (autentificare, autorizare)
▪ Rezistenta la atacuri
▪ Acces restrictionat la componente critice
▪ Performanta
▪ Monitorizare
HTTPS
▪ HTTP + TLS
▪ Portul 443
▪ Trafic criptat
▪ Functioneaza pe baza de certificate, chei asimetrice
si chei simetrice
▪ Obligatoriu pentru orice implica comunicatie peste
internet
 Managementul identitatii
intr-un sistem clasic
▪ Este nevoie de inregistrarea unui cont
▪ Conturi retinute in baza de date, intern
▪ Utilizatorii se autentifica cu credentialele setate la
inregistrarea contului
▪ Contul setat poate fi folosit doar in cadrul platformei
respective
▪ Permisiuni setate la nivel de sistem, business logic intern
Autentificare (Cine esti tu?)
▪ Procesul prin care o entitate isi demonstreaza identitatea intr-un
sistem
▪ Multe moduri de realizare: username si parola, token, date
biometrice, PIN, etc...
▪ Poate fi in straturi (multi factor authentication)
▪ Autentificarea rezulta, de obicei, in acces catre sistem
▪ Accesul se traduce in obiecte trimise clientului prin care acesta
demonstreaza ca s-a autentificat:
– Cookies
– Tokens
Autorizare (Ce poti face tu?)
▪ Resursele din sistem pot avea permisiuni
▪ Exemplu:
– Administratorul poate adauga feluri de mancare intr-un meniu
– Utilizatorul poate doar sa le vada
▪ Autorizarea completeaza identitatea unei entitati
▪ Permisiunile si rolurile trebuie stiute (doar) de backend
▪ Autorizarea, ca si autentificarea, sunt strans legate de
managementul identitatii unui utilizator
State management
▪ Backendul, implicit, este stateless
▪ Mecanismele de state management ajuta la retinerea
informatiilor intre cereri succesive
▪ Cookies
– Client side cookies
– Server side cookies (sessions)
▪ JWT Tokens
Cookies
▪ Un set de date stocat pe browserul utilizatorului
▪ Date de tipul Cheie=Valoare
▪ Pot fi persistente sau non-persistente (se sterg cand browserul se
inchide)
▪ Se ataseaza fiecarei cereri pe care browserul o executa
▪ Pot fi stocate si pe server
– In acest caz, backendul devine stateful
– Browserul retine un id pe care serverul il foloseste sa extraga informatii
▪ Niciodata nu stocati date de valoare in cookies!
 Securizare Cookies
▪ In afara de cheie si valoare, cookies au mai multe optiuni ce ajuta la
securizarea acestora
▪ Domain
– Restrange domeniul (si subdomeniul) unde se trimit cookies

▪ HttpOnly
– Restrange accesul la cookies. Util impotriva atacurilor XSS (Cross Site Scripting)
– Un atacator nu va putea accesa cookies

▪ Secure
– Restrange transferul de cookies doar peste HTTPS

▪ SameSite
– Restrange transferul cross-site. Ajuta la mitigarea CSRF (Cross Site Request Forgery)
– Daca SameSite este strict, cookies nu sunt trimise in cereri care nu comunica in cadrul aceluias context
– De exemplu, cookies provenite din good.example.com nu se vor trimite catre bad.example.com
Exemplu Cookies
 Tokenuri JWT (JSON Web Tokens)
▪ Informatie codificata intr-un token
▪ Tokenul este semnat pentru integritatea datelor
▪ Nu se trimit automat la fiecare cerere
▪ Folosit in REST Api cu adevarat stateless (*wink wink* microservicii)
▪ Util, in special, pentru mentinerea sesiunii in comunicatii backend-to-
backend sau aplicatii care nu ruleaza in browser (mobile)
▪ Mai scalabil decat server side cookies
– Nu este nevoie de retinerea lui pe backend, pentru ca tokenul este compact si are
toate informatiile pentru state management
 Anatomia unui JWT
▪ 3 parti
▪ Header
 Functionare JWT
▪ Backendul codifica header-ul si payload-ul in Base64
▪ Codificarea este semnata
– Modul in care se semneaza variaza in functie de algortimul ales: HMAC, RSA, etc…

▪ Semnatura este atasata la finalul tokenului

▪ Tokenul este trimis clientului in urma unei actiuni
– De obicei, autentificare sau cerere de token de access

▪ Clientul salveaza tokenul si il trimite in Authorization Header cand face cereri ulterioare
catre resurse protejate
▪ Backendul verifica integritatea datelor
– Semneaza codificarea Base64 din token
– Verifica daca rezultatul e identic cu semnatura atasata la finalul tokenului

▪ Backendul foloseste apoi informatiile codificate in token pentru business logic

 Securitate JWT
▪ Vulnerabil la XSS daca este salvat in localstorage (sau sessionstorage)
– Un atacator poate prelua tokenul salvat fara probleme
▪ Datele sunt codificate, nu criptate, deci este necesara utilizarea HTTPS
▪ Combate atacurile CSRF prin faptul ca nu se trimite automat la fiecare
cerere
▪ Prin natura sa compacta, asigura integritatea datelor
▪ Cel mai bine folosit in cadrul OAuth2 si OpenID Connect
JWT este vulnerabil la XSS.
Cum putem mitiga acest lucru?
Daca JWT e impachetat in
cookie, mai e aparat implicit
impotriva CSRF?
OAuth2 (RFC 6749)
▪ Framework de autorizare
▪ OAuth2 ofera posibilitatea unei aplicatii terte sa
obtina acces la un serviciu HTTP in numele unui
utilizator
– Ex: Ca sa faceti un quiz online, va logati cu FB si apoi bifati ca
sunteti de acord ca quizul online sa va acceseze poza de profil
▪ Poate fi utilizat la aplicatii desktop si web, servicii
web si aplicatii de mobil
Utilizarea OAuth2
▪ OAuth2 se rezuma la obtinerea unui token de acces pentru
accesarea resursei protejate
▪ Modul in care se obtine acest token este descris de granturi
▪ OAuth2 are 5 tipuri de granturi:
– Authorization Code
– Implicit
– Resource Owner Password Credentials
– Client Credentials
– Authorization Code Grant using PKCE
Terminologie OAuth2
▪ Resource Owner: entitatea care ofera acces catre o resursa
protejata. De obicei este utilizatorul
– Decide ce permisiuni are aplicatia terta (clientul) asupra resurselor protejate
▪ Client: o aplicatie care cere acces la o resursa protejata in numele
RO
▪ Resource Server: serverul care detine resursa protejata
▪ Authorization Server: serverul care autentifica RO si emite un
token de acces.
▪ User Agent: agentul folosit de RO pentru a comunica cu Clientul
(ex: browser, aplicatie nativa)
 OAuth2 Authorization Code
▪ Se foloseste cand Clientul
ruleaza pe un server
▪ Se obtine un cod de autorizare
pe care serverul il foloseste sa
obtina un token de acces si,
optional, un token de refresh
▪ Tokenurile sunt trimise direct
pe serverul Clientului
▪ Tokenurile sunt stocate pe
server
 OAuth2 Implicit
▪ Se foloseste cand
Clientul ruleaza pe
dispozitivul utilizatorului
▪ Se obtine direct un
token de acces
▪ Tokenurile sunt salvate
pe dispozitivul Clientului
(browser, telefon mobil)
▪ Mai putin sigur pentru ca
tokenurile de acces sunt
expuse
 OAuth2 Client Credentials

▪ Se foloseste cand Clientul este chiar Resource Owner

▪ Nu implica interactiune cu un utilizator uman
▪ Exemplu, un CRON care adauga date intr-o baza de date
OAuth2 RO Password Credentials
▪ Se foloseste in doua situatii:
– Clientul este incredintat cu datele de autentificare ale RO
– Orice alt grant nu se poate folosi
▪ Credentialele nu se mai introduc intr-un agent
separat, ci direct in client
▪ Periculos daca clientul nu este 100% de incredere
OAuth2 Auth Code Grant using PKCE
▪ Folosit in locul Implicit Grant
▪ Se bazeaza pe Authorization Grant
▪ Adauga un plus de securitate prin introducerea unui secret
care se verifica in Auth Server
▪ Permite grantului de tip Authorization Grant sa fie
sigur, chiar daca comunicatia se face intre frontend si
AS ( ca in cazul Implicit Grant)
 OAuth2 Corolar
▪ Framework de autorizare care propune folosirea
tokenurilor de acces
▪ Pe baza tokenurilor de access, un tert (Client) este
autorizat sa foloseasca informatii ale unui Resource
Owner
▪ Informatiile provin de pe un Resource Server.
▪ Tokenul de access este creat si validat de
Authorization Server
OAuth2 Corolar
OpenID Connect
▪ OAuth2 rezolva autorizarea
▪ OpenID Connect este un strat in plus adaugat peste
OAuth2, care se ocupa de autentificar
▪ Permite unei aplicatii sa preia informatii de la un
Identity Provider despre un utilizator in maniera
sigura
▪ Utilizeaza JWT pentru codificarea informatiilor cu
privire la utilizator
OpenID Connect
▪ OAuth2 rezolva autorizarea
▪ OpenID Connect este un strat in plus adaugat peste
OAuth2, care se ocupa de autentificar
▪ Permite unei aplicatii sa preia informatii de la un
Identity Provider despre un utilizator in maniera
sigura
▪ Deoarece este bazat pe OAuth2, flowurile seamana
foarte mult, dar sunt simplificate
Caz de utilizare OIDC

Sign up with ****

permite utilizarea unui
cont extern in contextul
unei aplicatii.
Caz de utilizare OIDC
▪ Sign up with Google trimite o cerere de
autorizare catre Google
▪ Google verifica credentialele si, ca in cazul
OAuth2 de baza, arata ce informatii vor fi
transmise catre Postman
▪ Dupa ce se ofera acceptul, Google trimite
un token de acces si un ID token (JWT)
inapoi catre Postman
▪ Postman poate folosi informatii din ID
Token pentru sesiune
Caz de utilizare OIDC
Bune practici
▪ HTTPS intotdeauna!
▪ Parole stocate in baza de date criptat
▪ Sanitizare si verificare de parametri
– Nu va bazati ca veti primi pe cereri ce va astepti sa primiti
– Verificati parametri intotdeauna si aruncati erori clare catre client

▪ Nu expuneti erorile de pe server catre client

– Erorile, de multe ori, pot expune vulnerabilitati

▪ Flaguri de securitate pentru cookies

▪ Utilizati drivere/orm/odm care previn atacuri SQL Injection
▪ Nu stocati informatii importante pe browser
Bune practici
▪ Monitorizati aplicatia pentru probleme de performanta
– Problemele de performanta pot cauza probleme de Securitate

▪ Restrictionati accesul catre componente interne ale sistemului

– Nu expuneti baza de date catre public
– Nu expuneti diverse servicii conectate la API-ul central catre public
– API Gateway pattern

▪ Stati la curent cu ultimele trenduri din domeniul securitatii web

– https://connect2id.com/learn/oauth-2
– https://bugcrowd.com/vulnerability-rating-taxonomy
– https://apisecurity.io/issue-34-owasp-launches-api-security-top-10-project
Bune practici
▪ Monitorizati aplicatia pentru probleme de performanta
– Problemele de performanta pot cauza probleme de Securitate

▪ Restrictionati accesul catre componente interne ale sistemului

– Nu expuneti baza de date catre public
– Nu expuneti diverse servicii conectate la API-ul central catre public
– API Gateway pattern

▪ Stati la curent cu ultimele trenduri din domeniul securitatii web

– https://connect2id.com/learn/oauth-2
– https://bugcrowd.com/vulnerability-rating-taxonomy
– https://apisecurity.io/issue-34-owasp-launches-api-security-top-10-project