Sesiune

Sesiunea , în tehnologia informației și telecomunicații , este un termen care poate fi folosit pentru a indica: ^[1]

• conversația dintre utilizator și computer pe un anumit subiect, de obicei o aplicație software ;
• activitatea desfășurată între două entități pentru a transfera date în ambele direcții pe întreaga durată a conexiunii sau incluse în timpul conexiunii între entitățile în sine.

Cu semnificația sa de bază, termenul a intrat în aceste zone în jurul anilor șaptezeci . Vorbim de nivel de sesiune în cazul unui model OSI .

Sesiune web

În engleză, cuvântul „sesiune” se referă la o perioadă discretă de timp în care se efectuează o sarcină. O sesiune web este, prin urmare, timpul pe care un utilizator îl petrece navigând pe un anumit site web: din momentul în care ajunge pe prima pagină, până în momentul în care părăsește site-ul ^[2] .

O sesiune web constă în date sau fișiere care sunt persistente în timpul utilizării unui site web sau a unei aplicații web. Aceste resurse sunt identificate în mod unic cu un ID de sesiune. Browserul utilizatorului primește acest ID la începutul unei noi sesiuni și acest ID este schimbat în timpul oricărei comunicări ulterioare între browser și server ^[3] .

O sesiune web include toate informațiile care pot fi relevante în timpul vizitei utilizatorului. În funcție de scopul site-ului web sau al aplicației web, acesta poate include date precum:

• Paginile vizualizate de utilizator
• Detaliile de contact introduse de utilizator într-un formular
• Articolele din coșul de cumpărături al utilizatorului

De obicei, există o limită maximă de timp pentru sesiunile web, după care sesiunea va expira. Această limită maximă de timp depinde de implementare. De exemplu, sesiunile web din Google Analytics expiră după 30 de minute de inactivitate; activitatea ulterioară a utilizatorului va fi tratată ca o nouă sesiune.

Site-urile și aplicațiile web cu un număr foarte mare de utilizatori adesea memorează în cache sesiunile web, astfel încât să poată fi recuperate mai rapid și mai eficient.

Avantajele utilizării sesiunilor web sunt evidente: sesiunile web permit site-ului web să aibă o formă de „memorie pe termen scurt” despre activitatea unui utilizator.

Pe de o parte, lipsa memoriei utilizatorului ar fi extrem de incomodă. Dacă un site web de comerț electronic nu reușește să-și amintească acțiunile unui utilizator, de exemplu, utilizatorii ar trebui să plaseze ordine simultan într-o singură acțiune, în loc să stocheze articole într-un coș de cumpărături.

Pe de altă parte, a avea o memorie prea lungă poate fi, de asemenea, impracticabil. De exemplu, dacă un utilizator revine la un site de comerț electronic după o lună, este posibil să nu dorească să vadă aceleași articole în coșul de cumpărături ca și ultima dată.

Ședințele web realizează un echilibru între aceste două extreme. Sesiunile web pe termen scurt oferă site-urilor web și aplicațiilor web suficientă „memorie” pentru a crea experiențe atractive și personalizate ale utilizatorului pe parcursul vizitei unui utilizator, fără a stoca prea multe informații irelevante pe termen lung.

Sesiunile web sunt adesea comparate cu (și confundate cu) cookie-urile . Deși atât cookie-urile, cât și sesiunile web stochează informații despre un utilizator, funcțiile lor sunt diferite în practică.

Cookie-urile sunt fișiere text care sunt utilizate pentru autentificarea și urmărirea vizitatorilor către un site web și sunt stocate numai pe computerul utilizatorului. Durata unui cookie este, în general, mult mai lungă decât cea a unei sesiuni web, în ​​ordinea lunilor sau chiar a anilor. Cookie-urile sunt modul în care site-urile web stochează informații de utilizare pe termen lung care ar trebui păstrate: de exemplu, conectându-se automat la utilizator atunci când ajung pe site sau completând automat un formular cu detalii despre utilizator.

În schimb, sesiunile web sunt destinate să stocheze informații numai despre cea mai recentă activitate a utilizatorului. Sesiunile web sunt stocate pe server mai degrabă decât pe client, ceea ce ajută la prevenirea modificării utilizatorilor rău intenționați. Atât sesiunile web, cât și cookie-urile pot fi utilizate în combinație pentru a urmări comportamentul utilizatorilor pe termen lung și scurt.

Operațiune

Exemplu de sesiune expirată a panoului de înregistrare Joomla!

Ciclul sesiunii cuprinde trei faze ^[4] :

• Pornire sau deschidere : se inițiază un schimb de informații între utilizatorul (sau chiar clientul ) care intenționează să utilizeze un serviciu și serverul care supraveghează acest serviciu. Cea mai cunoscută și mai frecventă procedură este procedura de autentificare . Serverul pregătește și stochează un pachet de informații permanente care vor deveni parametrii sesiunii și, pentru utilizator, datele sale de lucru pentru întreaga sesiune (de obicei, datele pregătite de server sunt inserate în cookie - uri , care la rândul lor sunt descărcate de pe web browsere și utilizate pentru a menține sesiunea de serviciu activă, fără a fi nevoie să reintroduceți manual datele de fiecare dată.)

• Lucrul în sesiune : Interviul continuă, întotdeauna cu schimbul de informații despre sesiune. Aplicațiile web tipice prevăd adesea că o parte din aceste informații pot fi modificate sau adăugate noi în timpul sesiunii.

• Închidere : la cererea utilizatorului sau a clientului, serverul șterge informațiile despre sesiune. În absența unei cereri specifice, majoritatea aplicațiilor prevăd închiderea sau încheierea automată a sesiunii, după un anumit timp în care utilizatorul / clientul nu trimite niciun mesaj.

Autentificare web, gestionare sesiune și control acces

O sesiune web este o secvență de solicitări HTTP de rețea și tranzacții de răspuns asociate aceluiași utilizator. Aplicațiile web moderne și complexe necesită păstrarea informațiilor sau stării fiecărui utilizator pe durata mai multor cereri. Prin urmare, sesiunile oferă posibilitatea de a stabili variabile, cum ar fi drepturile de acces și setările de locație, care se vor aplica fiecărei interacțiuni pe care un utilizator o are cu aplicația web pe durata sesiunii.

Aplicațiile web pot crea sesiuni pentru a urmări utilizatorii anonimi după prima cerere a utilizatorului. Un exemplu ar fi menținerea preferinței lingvistice a utilizatorului. În plus, aplicațiile web vor utiliza sesiuni odată ce utilizatorul este autentificat. Acest lucru asigură posibilitatea de a identifica utilizatorul la orice solicitări ulterioare, precum și de a putea aplica controale de securitate a accesului, accesul autorizat la datele private ale utilizatorului și creșterea gradului de utilizare a aplicației. Prin urmare, aplicațiile web actuale pot oferi funcționalități de sesiune atât înainte, cât și după autentificare.

Odată stabilită o sesiune autentificată, ID-ul sesiunii (sau simbolul) este echivalent temporar cu cea mai puternică metodă de autentificare utilizată de aplicație, cum ar fi numele de utilizator și parola, expresia de acces, parola unică (OTP), certificatele digitale bazate pe client, cardul inteligent sau date biometrice (cum ar fi amprentele digitale sau retina ochilor).

HTTP este un protocol fără stat (RFC2616 secțiunea 5), ​​în care fiecare pereche de cereri și răspunsuri este independentă de alte interacțiuni web. Prin urmare, pentru a introduce conceptul de sesiune, este necesar să se implementeze funcționalități de gestionare a sesiunii care leagă atât module de autentificare, cât și control de acces (sau autorizare) disponibile în mod obișnuit în aplicațiile web ^[4] :

• ID-ul sesiunii sau simbolul mapează acreditările de autentificare ale utilizatorului (sub forma unei sesiuni ale utilizatorului) la traficul HTTP al utilizatorului și la controalele de acces adecvate aplicate de aplicația web. Complexitatea acestor trei componente (autentificare, gestionarea sesiunii și controlul accesului) în aplicațiile web moderne, plus faptul că implementarea și asocierea acesteia se află în mâinile dezvoltatorului web (deoarece cadrele de dezvoltare web nu oferă relații strânse între modulele lor) , face ca implementarea unui modul sigur de gestionare a sesiunii să fie foarte dificilă.
• Divulgarea, capturarea, predicția, forța brută sau fixarea ID-ului de sesiune va duce la atacuri de deturnare (sau sidejacking) a sesiunii, în care un atacator poate identifica pe deplin un utilizator victimă pe web-ul aplicației. Atacatorii pot efectua două tipuri de atacuri de deturnare a sesiunii, vizate sau generice. Într-un atac țintit, obiectivul atacatorului este de a identifica un anumit utilizator (sau privilegiat) al unei victime a aplicației web. Pentru atacuri generice, obiectivul atacatorului este de a identifica (sau de a avea acces ca) orice utilizator valid sau legitim din aplicația web.

Sesiune ID

Pentru a menține starea autentificată și a urmări progresul utilizatorului în cadrul aplicației web, aplicațiile oferă utilizatorilor un identificator de sesiune (ID de sesiune sau simbol ^[5] ) care este atribuit atunci când sesiunea este creată și este partajată și schimbată de utilizator și de aplicația web pentru durata sesiunii (se trimite cu fiecare cerere HTTP). ID-ul sesiunii este o pereche name=value .

Pentru a implementa ID-uri de sesiune sigure, generarea de identificatori (ID-uri sau jetoane) trebuie să îndeplinească următoarele proprietăți.

Amprentarea numelui ID-ului

Numele folosit de ID-ul sesiunii nu trebuie să fie extrem de descriptiv sau să ofere detalii inutile despre scopul și semnificația ID-ului.

Numele ID-urilor de sesiune utilizate de cele mai frecvente cadre de dezvoltare a aplicațiilor web pot fi ușor detectate prin amprentă, cum ar fi PHPSESSID (PHP), JSESSIONID (J2EE), CFID și CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP.NET), etc. Prin urmare, numele ID-ului sesiunii poate dezvălui tehnologiile și limbajele de programare utilizate de aplicația web.

Vă recomandăm să schimbați numele sesiunii implicite a cadrului de dezvoltare web cu un nume generic, cum ar fi id .

Lungimea ID-ului sesiunii

ID-ul sesiunii trebuie să fie suficient de lung pentru a preveni atacurile cu forță brută, unde un atacator poate parcurge întreaga gamă de valori ID și poate verifica sesiunile valide.

• Lungimea ID-ului sesiunii trebuie să fie de cel puțin 128 bits (16 bytes) .

• Lungimea ID-ului sesiunii de 128 biți este furnizată pentru referință pe baza ipotezelor făcute în următoarea secțiune Entropy ID sesiune . Cu toate acestea, acest număr nu trebuie considerat un minim absolut, deoarece alți factori de implementare ar putea afecta puterea acestuia.
• De exemplu, există implementări bine cunoscute, cum ar fi ID-ul sesiunii Microsoft ASP.NET: „ Identificatorul de sesiune ASP.NET este un număr generat aleatoriu codificat într-un șir de 24 de caractere format din litere mici de la A la Z și numere de la 0 la 5 ".
• Poate oferi o entropie eficientă foarte bună și, ca rezultat, poate fi considerată suficient de lungă pentru a evita presupunerile sau atacurile de forță brută.

Entropie (ID sesiune)

ID-ul sesiunii trebuie să fie imprevizibil (destul de aleatoriu) pentru a evita atacurile de ghicit, în care un atacator este capabil să ghicească sau să prezică ID-ul unei sesiuni valide prin tehnici de analiză statistică. În acest scop, trebuie utilizat un bun CSPRNG (Generator de Numere Pseudorandom Criptografic Sigur) ^[4] .

Valoarea ID-ului sesiunii trebuie să furnizeze cel puțin 64 bits entropie (dacă se utilizează un PRNG bun, această valoare este estimată la jumătate din lungimea ID-ului sesiunii).

De asemenea, un ID al sesiunii aleatorii nu este suficient; de asemenea, trebuie să fie unic pentru a evita duplicarea ID-urilor. Un ID al sesiunii aleatorii nu trebuie să existe deja în spațiul actual al ID-ului sesiunii.

• Entropia ID-ului sesiunii este cu adevărat afectată de alți factori externi și dificil de măsurat, cum ar fi numărul de sesiuni active simultane pe care le are în mod obișnuit aplicația web, timpul de expirare absolută a sesiunii, cantitatea de încercări de identificare a sesiunii pe secundă pe care atacatorul le poate face și aplicația web țintă poate suporta etc.
• Dacă se folosește un ID de sesiune cu o entropie de 64 bits , un atacator va dura cel puțin 292 de ani pentru a ghici cu succes un ID de sesiune valid, presupunând că atacatorul poate încerca 10.000 de încercări pe secundă cu 100.000 de sesiuni simultane valide disponibile în aplicația web.

Conținutul ID-ului sesiunii (sau valoarea)

Conținutul (sau valoarea) ID-ului sesiunii trebuie să fie lipsit de sens pentru a preveni atacurile de divulgare a informațiilor, în care un atacator este capabil să decripteze conținutul ID-ului și să extragă detalii despre utilizator, sesiune sau sesiune. Funcționarea internă a aplicației web.

ID-ul sesiunii trebuie să fie pur și simplu un identificator al clientului și valoarea acestuia nu trebuie să includă niciodată informații sensibile (sau PII).

Semnificația și logica de afaceri sau aplicație asociate cu ID-ul sesiunii trebuie să fie stocate pe partea serverului și, în mod specific, în obiecte de sesiune sau într-o bază de date de gestionare a sesiunii sau într-un depozit.

Informațiile stocate pot include adresa IP a clientului, agentul utilizatorului, adresa de e-mail, numele de utilizator, ID-ul utilizatorului, rolul, nivelul de privilegiu, drepturile de acces, preferințele de limbă, ID-ul contului, starea curentă, ultima autentificare, expirarea sesiunii și alte detalii interne ale sesiunilor. Dacă obiectele și proprietățile sesiunii conțin informații sensibile, cum ar fi numerele cardului de credit, depozitul de gestionare a sesiunii trebuie să fie criptat și securizat corespunzător.

Este recomandat să creați ID-uri de sesiune criptografice puternice prin utilizarea funcțiilor hash criptografice, cum ar fi SHA256 ^[4] .

Implementarea managementului sesiunii

Implementarea managementului sesiunii definește mecanismul de schimb care va fi utilizat între utilizator și aplicația web pentru a partaja și schimba continuu ID-ul sesiunii. Există mai multe mecanisme disponibile în HTTP pentru menținerea stării sesiunii în cadrul aplicațiilor web, cum ar fi cookie-urile (antetul HTTP standard), parametrii URL (rescriere URL - RFC2396), argumentele URL pentru solicitările GET, argumentele corpului pentru solicitările POST, cum ar fi câmpurile de formular ascunse (Formulare HTML) sau anteturi HTTP proprii ^[4] .

Mecanismul preferat de schimb al ID-ului de sesiune ar trebui să permită definirea proprietăților avansate ale simbolurilor, cum ar fi data și ora expirării simbolului sau constrângerile de utilizare granulare. Acesta este unul dintre motivele pentru care cookie-urile (RFC 2109 și 2965 și 6265) sunt unul dintre cele mai utilizate mecanisme de schimb de ID-uri de sesiune, oferind funcționalități îmbunătățite care nu sunt disponibile în alte metode.

Utilizarea unor mecanisme specifice de schimb de ID-uri de sesiune, cum ar fi cele în care ID-ul este inclus în adresa URL, poate dezvălui ID-ul sesiunii (în link-uri web și jurnale, istoricul și marcajele browserului web, în ​​antetul de referință sau în motoarele de căutare), precum și facilitează alte atacuri, cum ar fi manipularea ID-ului sau atacurile de fixare a sesiunii.

Implementări integrate de gestionare a sesiunii

Cadrele de dezvoltare web, cum ar fi J2EE, ASP.NET, PHP și altele, oferă propriile capacități de gestionare a sesiunii și implementarea asociată. Vă recomandăm să utilizați aceste cadre încorporate, mai degrabă decât să le construiți de la zero, deoarece acestea sunt folosite în întreaga lume în mai multe medii web și au fost testate de comunitatea de dezvoltare a aplicațiilor web și de securitate de-a lungul timpului ^[4] .

Cu toate acestea, rețineți că aceste cadre au prezentat și vulnerabilități și puncte slabe în trecut, astfel încât este întotdeauna recomandat să folosiți cea mai recentă versiune disponibilă, care poate remedia toate vulnerabilitățile cunoscute, precum și să revizuiți și să modificați configurația implicită pentru a-i îmbunătăți securitatea. urmând recomandările descrise în acest document.

Capacitățile de stocare sau depozitul utilizat de mecanismul de gestionare a sesiunii pentru a salva temporar ID-urile de sesiune trebuie protejate, protejând ID-urile de sesiune de divulgarea accidentală locală sau la distanță sau de accesul neautorizat.

Mecanisme de schimb de ID-uri de sesiune utilizate și acceptate

O aplicație web ar trebui să utilizeze cookie-uri pentru a gestiona schimbul de ID-uri de sesiune. Dacă un utilizator trimite un ID de sesiune printr-un alt mecanism de schimb, cum ar fi un parametru URL, aplicația web ar trebui să evite acceptarea acestuia ca parte a unei strategii defensive pentru a sparge fixarea sesiunii ^[4] .

• Chiar dacă o aplicație web folosește cookie-uri ca mecanism implicit de schimb al ID-ului de sesiune, poate accepta și alte mecanisme de schimb.
• Prin urmare, este necesar să confirmați prin teste aprofundate toate diferitele mecanisme acceptate în prezent de aplicația web în timpul procesării și gestionării ID-urilor de sesiune și să limitați mecanismele de urmărire a ID-ului de sesiune acceptat numai pentru cookie-uri.
• În trecut, unele aplicații web foloseau parametri URL sau chiar treceau de la cookie-uri la parametrii URL (prin rescrierea automată a URL-urilor), dacă sunt îndeplinite anumite condiții (de exemplu, identificarea clienților web fără suport pentru cookie-uri sau neacceptarea cookie-urilor). la problemele de confidențialitate ale utilizatorilor).

Protecție la nivel de transport

Pentru a proteja schimbul de ID-uri de sesiune de ascultarea activă și dezvăluirea pasivă în traficul de rețea, este esențial să utilizați o conexiune HTTPS (TLS) criptată pentru întreaga sesiune web, nu doar pentru procesul de autentificare în care sunt schimbate mesajele. acreditările utilizatorului.

De asemenea, atributul cookie Secure trebuie utilizat pentru a se asigura că ID-ul sesiunii este schimbat numai pe un canal criptat. Utilizarea unui canal de comunicare criptat protejează, de asemenea, sesiunea de anumite atacuri de fixare a sesiunii în care atacatorul este capabil să intercepteze și să manipuleze traficul web pentru a injecta (sau corecta) ID-ul sesiunii în browserul web al victimei ^[4] .

Următorul set de bune practici se concentrează pe securizarea ID-ului sesiunii (în special atunci când sunt utilizate cookie-uri) și ajută la integrarea HTTPS în aplicația web:

• Nu comutați o anumită sesiune de la HTTP la HTTPS sau invers, deoarece aceasta va dezvălui ID-ul sesiunii în text clar în întreaga rețea.
  • Când redirecționați către HTTPS, asigurați-vă că cookie-ul este setat sau regenerat după ce a avut loc redirecționarea.
• Nu amestecați conținut criptat și necriptat (pagini HTML, imagini, fișiere CSS, fișiere JavaScript etc.) pe aceeași pagină sau din același domeniu.
• Unde este posibil, evitați să oferiți conținut public necriptat și conținut privat criptat de la aceeași gazdă. În cazul în care este necesar conținut nesigur, luați în considerare găzduirea acestuia pe un domeniu nesigur separat.
• Implementați HTTP Strict Transport Security (HSTS) pentru a impune conexiunile HTTPS.

Consultați fișa informativă OWASP Transport Layer Security pentru îndrumări mai generale despre implementarea TLS sigură.

Important, TLS nu protejează împotriva predicției ID-ului sesiunii, a forței brute, a manipulării sau a corecției din partea clientului; cu toate acestea, oferă o protecție eficientă împotriva unui atacator care interceptează sau fură ID-urile de sesiune printr-un atac din mijloc.

Cookie-uri

Același subiect în detaliu: Cookie-uri .

Mecanismul de schimb de ID-uri de sesiune bazat pe cookie oferă mai multe caracteristici de securitate sub formă de atribute cookie care pot fi utilizate pentru securizarea schimbului de ID-uri de sesiune ^[4] :

Atribut sigur

Atributul cookie Secure instruiește browserele web să trimită cookie-ul numai printr-o conexiune HTTPS criptată (SSL / TLS). Acest mecanism de securitate a sesiunii este necesar pentru a preveni divulgarea ID-ului sesiunii prin atacuri Man-in-the-Middle (MitM). Se asigură că un atacator nu poate obține pur și simplu ID-ul sesiunii din traficul browserului web.

Forțarea aplicației web să utilizeze numai HTTPS pentru comunicarea sa (chiar și atunci când portul TCP / 80, HTTP, este închis pe gazda aplicației web) nu protejează împotriva divulgării ID-ului sesiunii dacă cookie-ul Secure nu a fost setat: browserul poate fi păcălit să dezvăluie ID-ul sesiunii pe o conexiune HTTP necriptată. Atacatorul poate intercepta și manipula traficul utilizatorului victimă și poate injecta o referință HTTP necriptată aplicației web, care va forța browserul web să trimită ID-ul sesiunii în text clar.

Atribut HttpOnly

HttpOnly cookie HttpOnly instruiește browserele web să nu permită scripturilor (cum ar fi JavaScript sau VBscript) să acceseze cookie-urile prin intermediul obiectului DOM document.cookie. Această protecție pentru ID-ul sesiunii este necesară pentru a preveni furtul ID-ului sesiunii prin atacuri XSS. Cu toate acestea, dacă un atac XSS este combinat cu un atac CSRF, solicitările trimise aplicației web vor include cookie-ul de sesiune, deoarece browserul include întotdeauna cookie-uri la trimiterea cererilor. HttpOnly ul HttpOnly protejează numai confidențialitatea cookie-ului; atacatorul nu îl poate folosi offline, în afara contextului unui atac XSS.

Atribut SameSite

SameSite permite unui server să definească un atribut cookie, făcând imposibil browserul să trimită acest cookie împreună cu cererile de pe site-uri. Obiectivul principal este de a atenua riscul scurgerilor de informații între origini și de a oferi o anumită protecție împotriva atacurilor de falsificare a cererilor între site-uri.

Atribute de domeniu și cale

Atributul cookie de Domain instruiește browserele web să trimită cookie-ul numai către domeniul specificat și către toate subdomeniile. Dacă atributul nu este setat, în mod implicit cookie-ul va fi trimis numai către serverul de origine. Atributul cookie Path instruiește browserele web să trimită cookie-ul numai în directorul sau subdirectoarele (sau căile sau resursele) specificate în cadrul aplicației web. Dacă atributul nu este setat, în mod implicit cookie-ul va fi trimis doar pentru director (sau cale ) a resursei solicitate și setarea cookie-urilor.

Este recomandat să utilizați un domeniu restrâns sau limitat pentru aceste două atribute. În acest fel, atributul de Domain nu trebuie setat (limitând modulul cookie doar la serverul de origine), iar atributul Path trebuie setat cât mai restrictiv posibil la calea aplicației web care utilizează ID-ul sesiunii.

Setarea atributului Domain la o valoare prea permisivă, cum ar fi example.com permite unui atacator să lanseze atacuri ID sesiune între diferite gazde și aplicații web aparținând aceluiași domeniu, cunoscute sub numele de cookie-uri cu subdomeniu încrucișat. De exemplu, vulnerabilitățile din www.example.com ar putea permite unui atacator să obțină acces la ID-urile de sesiune de pe secure.example.com .

În plus, se recomandă să nu amestecați aplicații web de diferite niveluri de securitate pe același domeniu. Vulnerabilitățile unei aplicații web ar permite unui atacator să seteze ID-ul sesiunii pentru o altă aplicație web pe același domeniu utilizând un atribut de Domain permisiv (cum ar fi example.com ) care este o tehnică care poate fi utilizată în atacuri prin corectarea sesiunii ^[4] .

Deși atributul Path permite izolarea ID-urilor de sesiune între diferite aplicații web folosind căi diferite pe aceeași gazdă, este foarte recomandat să nu rulați aplicații web diferite (în special de la niveluri sau domenii de securitate diferite) pe aceeași gazdă. Alte metode pot fi utilizate de aceste aplicații pentru a accesa ID-urile sesiunii, cum ar fi obiectul document.cookie . De asemenea, orice aplicație web poate seta cookie-uri pentru orice cale de pe gazda respectivă.

Cookie-urile sunt vulnerabile la atacurile de falsificare DNS, unde un atacator poate manipula rezoluția DNS pentru a forța browserul web să dezvăluie ID-ul sesiunii pentru o anumită gazdă sau domeniu.

Atribute Expire și Max-Age

Mecanismele de gestionare a sesiunii bazate pe cookie pot utiliza două tipuri de cookie-uri, cookie-uri non-persistente (sau de sesiune) și cookie-uri persistente. Dacă un cookie are atributele Max-Age (care are preferință peste Expires ) sau Expires , acesta va fi considerat un cookie persistent și va fi stocat pe disc de browserul web pe baza datei de expirare ^[4] .

De obicei, funcțiile de gestionare a sesiunii pentru a urmări utilizatorii după autentificare utilizează cookie-uri non-persistente. Acest lucru face ca sesiunea să dispară din client dacă instanța curentă a browserului web este închisă. Prin urmare, este foarte recomandat să utilizați cookie-uri non-persistente în scopuri de gestionare a sesiunii, astfel încât ID-ul sesiunii să nu rămână în memoria cache a clientului web pentru perioade lungi de timp, de unde un atacator îl poate obține.

• Asigurarea faptului că informațiile sensibile nu sunt înțelese, asigurarea faptului că informațiile sensibile nu sunt persistente / criptate / stocate în funcție de necesități pe durata necesității
• Asigurați-vă că activitățile neautorizate nu pot avea loc prin manipularea cookie-urilor
• Asigurați-vă că semnalizatorul de securitate este setat pentru a preveni transmiterea accidentală „peste fir” într-un mod nesigur
• Determină dacă toate tranzițiile de stare din codul aplicației verifică corect cookie-urile și impun utilizarea acestora
• Asigurați-vă că întregul cookie trebuie criptat dacă datele sensibile persistă în cookie
• Definiți toate cookie-urile utilizate de aplicație, numele acestora și de ce sunt necesare

API de stocare web HTML5

Același subiect în detaliu: HTML5 .

Hypertext Application Group Web Tehnologia de lucru (WHATWG) descrie localStorage și sessionStorage HTML5 Web API - urile de stocare ca mecanisme pentru stocarea la nivel de client perechi nume-valoare. Spre deosebire de cookie - uri HTTP, localStorage și sessionStorage conținutul nu sunt partajate automat în cereri sau răspunsuri de la browser și sunt utilizate pentru stocarea de date la nivel de client ^{[6] [7] [4]} .

API-ul localStorage

Domeniul de aplicare

Datele stocate folosind API-ul localStorage sunt accesibile din pagini încărcate din aceeași sursă, definite ca schemă ( https:// ), gazdă ( example.com ), port ( 443 ) și domeniu / tărâm ( example.com ). Acest lucru oferă acces similar la aceste date pe care le-ați obține utilizând semnalizatorul secure pe un cookie, ceea ce înseamnă că datele stocate de https nu pot fi recuperate prin http . Datorită potențialului acces simultan din ferestre / fire separate, datele stocate folosind localStorage ar putea fi supuse unor probleme de acces partajat (cum ar fi condițiile cursei) și ar trebui considerate ca neblocante (specificații API de stocare web).

Durată

Datele stocate folosind API-ul localStorage sunt păstrate în timpul sesiunilor de navigare, prelungind perioada de timp în care pot fi accesate de alți utilizatori ai sistemului.

Acces offline

Standardele nu necesită criptarea datelor de stocare localStorage în repaus, ceea ce înseamnă că ar putea fi posibil să accesați direct aceste date de pe disc.

Utilizare caz

WHATWG suggerisce l'uso di localStorage per i dati a cui è necessario accedere attraverso finestre o schede, su più sessioni e dove potrebbe essere necessario archiviare grandi volumi di dati (multi-megabyte) per motivi di prestazioni.

L'API sessionStorage

Scopo

L'API sessionStorage memorizza i dati all'interno del contesto della finestra da cui è stata chiamata, il che significa che la scheda 1 non può accedere ai dati archiviati dalla scheda 2. Inoltre, come l'API localStorage , i dati archiviati utilizzando l'API sessionStorage sono accessibili dalle pagine caricate dalla stessa origine, che è definito come scheme ( https:// ), host ( example.com ), port ( 443 ) e domain/realm ( example.com ). Ciò fornisce un accesso simile a questi dati come si otterrebbe utilizzando il flag secure su un cookie, il che significa che i dati memorizzati da https non possono essere recuperati tramite http .

Durata

L'API sessionStorage memorizza i dati solo per la durata della sessione di navigazione corrente. Una volta chiusa la scheda, i dati non sono più recuperabili. Ciò non impedisce necessariamente l'accesso, nel caso in cui una scheda del browser venga riutilizzata o lasciata aperta. I dati possono anche persistere in memoria fino a un evento di garbage collection.

Accesso offline

Gli standard non richiedono che i dati sessionStorage siano crittografati a riposo, il che significa che potrebbe essere possibile accedere direttamente a questi dati dal disco.

Caso d'uso

WHATWG suggerisce l'uso di sessionStorage per i dati rilevanti per un'istanza di un flusso di lavoro, come i dettagli per la prenotazione di un biglietto, ma in cui è possibile eseguire più flussi di lavoro contemporaneamente in altre schede. La natura del vincolo di finestra/scheda manterrà i dati dalla perdita tra i flussi di lavoro in schede separate.

Rischi per la sicurezza

In generale, i dati protetti o sensibili non devono essere archiviati in modo persistente negli archivi dati del browser poiché ciò potrebbe consentire la fuga di informazioni sui sistemi condivisi. Poiché i meccanismi di archiviazione Web sono API, ciò consente anche l'accesso da script iniettati, rendendolo meno sicuro dei cookie con il flag httponly applicato. Sebbene sia possibile archiviare dati specifici del flusso di lavoro sessionStorage per utilizzarli in quella scheda/finestra specifica durante i ricaricamenti, le API di archiviazione Web dovrebbero essere trattate come archiviazione non sicura. Per questo motivo, se una soluzione aziendale richiede l'uso di localStorage o sessionStorage per archiviare dati sensibili, una tale soluzione dovrebbe crittografare i dati e applicare protezioni di riproduzione. A causa della possibilità di accedere alle API di archiviazione Web tramite un attacco XSS, gli identificatori di sessione devono essere archiviati utilizzando cookie non persistenti, con i flag appropriati per proteggere da problemi di accesso non sicuro ( Secure ), XSS ( HttpOnly ) e CSRF ( SameSite ).

Web Workers

Lo stesso argomento in dettaglio: Web worker .

I Web Worker eseguono il codice JavaScript in un contesto globale separato da quello della finestra corrente. Esiste un canale di comunicazione con la finestra di esecuzione principale, che viene chiamato MessageChannel [4] .

Caso d'uso

I web worker sono un'alternativa per l'archiviazione del browser dei segreti (di sessione) quando la persistenza dell'archiviazione durante l'aggiornamento della pagina non è un requisito. Affinché i Web Worker forniscano l'archiviazione sicura del browser, qualsiasi codice che richiede il segreto dovrebbe esistere all'interno del Web Worker e il segreto non dovrebbe mai essere trasmesso al contesto della finestra principale.

L'archiviazione dei segreti nella memoria di un Web Worker offre le stesse garanzie di sicurezza di un cookie HttpOnly: la riservatezza del segreto è protetta. Tuttavia, un attacco XSS può essere utilizzato per inviare messaggi al Web Worker per eseguire un'operazione che richiede il segreto. Il Web Worker restituirà il risultato dell'operazione al thread di esecuzione principale.

Il vantaggio di un'implementazione di Web Worker rispetto a un cookie HttpOnly è che un Web Worker consente ad un codice JavaScript isolato di accedere al segreto; un cookie HttpOnly non è accessibile a nessun JavaScript. Se il codice JavaScript frontend richiede l'accesso al segreto, l'implementazione del Web Worker è l'unica opzione di archiviazione del browser che preserva la riservatezza del segreto.

Ciclo di vita dell'ID sessione

Gestione dell'ID sessione come qualsiasi altro input utente

Gli ID sessione devono essere considerati non attendibili, come qualsiasi altro input utente elaborato dall'applicazione Web, e devono essere accuratamente convalidati e verificati. A seconda del meccanismo di gestione della sessione utilizzato, l'ID di sessione verrà ricevuto in un parametro GET o POST, nell'URL o in un'intestazione HTTP (ad esempio i cookie). Se le applicazioni Web non convalidano e filtrano i valori ID di sessione non validi prima di elaborarle, possono essere potenzialmente utilizzate per sfruttare altre vulnerabilità Web, come SQL injection se gli ID di sessione sono archiviati su un database relazionale o XSS persistente se gli ID di sessione vengono memorizzati e riflessi in seguito dall'applicazione web ^[4] .

Rinnova l'ID sessione dopo qualsiasi modifica del livello di privilegio

L'ID sessione deve essere rinnovato o rigenerato dall'applicazione Web dopo qualsiasi modifica del livello di privilegio all'interno della sessione utente associata. Lo scenario più comune in cui la rigenerazione dell'ID di sessione è obbligatoria è durante il processo di autenticazione, poiché il livello di privilegio dell'utente passa dallo stato non autenticato (o anonimo) allo stato autenticato. È inoltre necessario considerare altri scenari comuni, come le modifiche alla password, le modifiche alle autorizzazioni o il passaggio da un ruolo utente normale a un ruolo di amministratore all'interno dell'applicazione Web. Per tutte queste pagine critiche dell'applicazione Web, gli ID di sessione precedenti devono essere ignorati, un nuovo ID di sessione deve essere assegnato a ogni nuova richiesta ricevuta per la risorsa critica e l'ID di sessione precedente o precedente deve essere distrutto.

I framework di sviluppo web più comuni forniscono funzioni e metodi di sessione per rinnovare l'ID di sessione, come request.getSession(true) & HttpSession.invalidate() (J2EE), Session.Abandon() & Response.Cookies.Add(new...) (ASP.NET) o session_start() & session_regenerate_id(true) (PHP).

La rigenerazione dell'ID di sessione è obbligatoria per prevenire attacchi di fissazione della sessione, in cui un utente malintenzionato imposta l'ID di sessione sul browser Web dell'utente della vittima invece di raccogliere l'ID di sessione della vittima, come nella maggior parte degli altri attacchi basati sulla sessione, e indipendentemente dall'utilizzo di HTTP o HTTPS. Questa protezione mitiga l'impatto di altre vulnerabilità basate sul Web che possono essere utilizzate anche per lanciare attacchi di correzione della sessione, come la suddivisione della risposta HTTP o XSS.

Una raccomandazione complementare è quella di utilizzare un ID di sessione o un nome token (o un set di ID di sessione) diversi prima e dopo l'autenticazione, in modo che l'applicazione Web possa tenere traccia degli utenti anonimi e degli utenti autenticati senza il rischio di esporre o legare la sessione dell'utente tra entrambi gli stati ^[4] .

Considerazioni sull'utilizzo di più cookie

Se l'applicazione Web utilizza i cookie come meccanismo di scambio dell'ID di sessione e più cookie sono impostati per una determinata sessione, l'applicazione Web deve verificare tutti i cookie (e applicare le relazioni tra di essi) prima di consentire l'accesso alla sessione dell'utente.

È molto comune per le applicazioni Web impostare una pre-autenticazione del cookie utente su HTTP per tenere traccia degli utenti non autenticati (o anonimi). Una volta che l'utente si autentica nell'applicazione Web, un nuovo cookie sicuro post-autenticazione viene impostato su HTTPS e viene stabilita un'associazione tra entrambi i cookie e la sessione utente. Se l'applicazione web non verifica entrambi i cookie per le sessioni autenticate, un utente malintenzionato può utilizzare il cookie non protetto di pre-autenticazione per ottenere l'accesso alla sessione dell'utente autenticato.

Le applicazioni Web dovrebbero cercare di evitare lo stesso nome di cookie per diversi percorsi o ambiti di dominio all'interno della stessa applicazione Web, poiché ciò aumenta la complessità della soluzione e potenzialmente introduce problemi di scoping .

Scadenza della sessione

Per ridurre al minimo il periodo di tempo in cui un utente malintenzionato può lanciare attacchi su sessioni attive e dirottarle, è obbligatorio impostare i timeout di scadenza per ogni sessione, stabilendo per quanto tempo una sessione rimarrà attiva. Una scadenza insufficiente della sessione da parte dell'applicazione web aumenta l'esposizione di altri attacchi basati sulla sessione, poiché per poter riutilizzare un ID di sessione valido e dirottare la sessione associata, l'aggressore deve essere ancora attivo ^[4] .

Minore è l'intervallo di sessione, minore è il tempo a disposizione di un utente malintenzionato per utilizzare l'ID di sessione valido. I valori di timeout di scadenza della sessione devono essere impostati in base allo scopo e alla natura dell'applicazione Web e bilanciare sicurezza e usabilità, in modo che l'utente possa completare comodamente le operazioni all'interno dell'applicazione Web senza che la sua sessione scada frequentemente.

Entrambi i valori di inattività e di timeout assoluto dipendono fortemente dalla criticità dell'applicazione Web e dei suoi dati. Gli intervalli di timeout di inattività comuni sono 2-5 minuti per applicazioni di alto valore e 15-30 minuti per applicazioni a basso rischio. I timeout assoluti dipendono da quanto tempo un utente utilizza normalmente l'applicazione. Se l'applicazione è destinata all'uso da parte di un impiegato per un'intera giornata, un intervallo di timeout assoluto appropriato potrebbe essere compreso tra 4 e 8 ore.

Quando una sessione scade, l'applicazione web deve intraprendere azioni attive per invalidare la sessione su entrambi i lati, client e server. Quest'ultimo è il più rilevante e obbligatorio dal punto di vista della sicurezza.

Per la maggior parte dei meccanismi di scambio di sessioni, le azioni lato client per invalidare l'ID di sessione si basano sulla cancellazione del valore del token. Ad esempio, per invalidare un cookie si consiglia di fornire un valore vuoto (o non valido) per l'ID di sessione e impostare l'attributo Expires (o Max-Age ) su una data passata (nel caso in cui venga utilizzato un cookie persistente): Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT

Al fine di chiudere e invalidare la sessione lato server, è obbligatorio che l'applicazione web intraprenda azioni attive quando la sessione scade, o l'utente si disconnette attivamente, utilizzando le funzioni e le modalità offerte dai meccanismi di gestione della sessione, quali come HttpSession.invalidate() (J2EE), Session.Abandon() (ASP.NET) o session_destroy()/unset() (PHP).

Scadenza automatica della sessione

Timeout di inattività

Tutte le sessioni dovrebbero implementare un timeout di inattività o inattività. Questo timeout definisce la quantità di tempo in cui una sessione rimarrà attiva nel caso in cui non vi siano attività nella sessione, chiudendo e invalidando la sessione dopo il periodo di inattività definito dall'ultima richiesta HTTP ricevuta dall'applicazione Web per un determinato ID di sessione.

Il timeout di inattività limita le possibilità che un utente malintenzionato abbia di indovinare e utilizzare un ID di sessione valido di un altro utente. Tuttavia, se l'aggressore è in grado di dirottare una determinata sessione, il timeout di inattività non limita le azioni dell'aggressore, poiché può generare periodicamente attività sulla sessione per mantenerla attiva per periodi di tempo più lunghi.

La gestione e la scadenza del timeout della sessione devono essere applicate sul lato server. Se il client viene utilizzato per imporre il timeout della sessione, ad esempio utilizzando il token di sessione o altri parametri del client per tenere traccia dei riferimenti temporali (ad esempio il numero di minuti dall'ora di accesso), un utente malintenzionato potrebbe manipolarli per estendere la durata della sessione.

Timeout assoluto

Tutte le sessioni dovrebbero implementare un timeout assoluto, indipendentemente dall'attività della sessione. Questo timeout definisce la quantità massima di tempo in cui una sessione può essere attiva, chiudendo e invalidando la sessione dopo il periodo assoluto definito da quando la sessione data è stata inizialmente creata dall'applicazione web. Dopo aver invalidato la sessione, l'utente è costretto a (ri) autenticarsi nuovamente nell'applicazione web e stabilire una nuova sessione.

La sessione assoluta limita la quantità di tempo che un utente malintenzionato può utilizzare una sessione dirottata e impersonare l'utente vittima.

Timeout rinnovo

In alternativa, l'applicazione web può implementare un timeout di rinnovo aggiuntivo dopo il quale l'ID di sessione viene automaticamente rinnovato, a metà della sessione utente, e indipendentemente dall'attività della sessione e, quindi, dal timeout di inattività.

Dopo un determinato periodo di tempo dalla creazione iniziale della sessione, l'applicazione Web può rigenerare un nuovo ID per la sessione utente e provare a impostarlo o rinnovarlo sul client. Il valore dell'ID di sessione precedente sarebbe ancora valido per un po' 'di tempo, adattando un intervallo di sicurezza, prima che il client sia a conoscenza del nuovo ID e inizi a usarlo. A quel punto, quando il client passa al nuovo ID all'interno della sessione corrente, l'applicazione invalida l'ID precedente.

Questo scenario riduce al minimo la quantità di tempo in cui un determinato valore di ID sessione, potenzialmente ottenuto da un utente malintenzionato, può essere riutilizzato per dirottare la sessione dell'utente, anche quando la sessione dell'utente vittima è ancora attiva. La sessione utente rimane attiva e aperta sul client legittimo, sebbene il valore dell'ID di sessione associato venga rinnovato periodicamente in modo trasparente durante la durata della sessione, ogni volta che scade il timeout di rinnovo. Pertanto, il timeout di rinnovo integra i timeout di inattività e assoluti, specialmente quando il valore di timeout assoluto si estende in modo significativo nel tempo (ad esempio, è un requisito dell'applicazione mantenere aperte le sessioni utente per lunghi periodi di tempo).

A seconda dell'implementazione, potenzialmente potrebbe esserci una condizione di competizione in cui l'attaccante con un ID di sessione precedente ancora valido invia una richiesta prima dell'utente vittima, subito dopo che il timeout di rinnovo è appena scaduto, e ottiene prima il valore per l'ID di sessione rinnovato. Almeno in questo scenario, l'utente vittima potrebbe essere a conoscenza dell'attacco poiché la sua sessione verrà interrotta improvvisamente perché il suo ID di sessione associato non è più valido.

Scadenza manuale della sessione

Le applicazioni Web dovrebbero fornire meccanismi che consentano agli utenti sensibili alla sicurezza di chiudere attivamente la propria sessione una volta terminato di utilizzare l'applicazione Web.

Pulsante di disconnessione

Le applicazioni Web devono fornire un pulsante di disconnessione (disconnessione, uscita o chiusura sessione) visibile e facilmente accessibile, disponibile nell'intestazione o nel menu dell'applicazione Web e raggiungibile da ogni risorsa e pagina dell'applicazione Web, in modo che l'utente possa chiudere manualmente la sessione all'indirizzo in qualsiasi momento. Come descritto nella sezione Session_Expiration , l'applicazione web deve invalidare la sessione almeno sul lato server.

NOTA : Sfortunatamente, non tutte le applicazioni Web facilitano agli utenti la chiusura della sessione corrente. Pertanto, i miglioramenti sul lato client consentono agli utenti coscienziosi di proteggere le proprie sessioni aiutando a chiuderle diligentemente.

Caching dei contenuti web

Anche dopo la chiusura della sessione, potrebbe essere possibile accedere ai dati privati o sensibili scambiati all'interno della sessione tramite la cache del browser web. Pertanto, le applicazioni Web devono utilizzare direttive di cache restrittive per tutto il traffico Web scambiato tramite HTTP e HTTPS, come le intestazioni Cache-Control e Pragma HTTP e/o tag META equivalenti su tutte o (almeno) le pagine Web sensibili.

Indipendentemente dalla politica della cache definita dall'applicazione Web, se è consentito il caching dei contenuti dell'applicazione Web, gli ID di sessione non devono mai essere memorizzati nella cache, quindi si consiglia vivamente di utilizzare la direttiva Cache-Control: no-cache="Set-Cookie, Set-Cookie2" , per consentire ai client Web di memorizzare nella cache tutto tranne l'ID di sessione.

Difese aggiuntive lato client per la gestione delle sessioni

Le applicazioni Web possono integrare le difese di gestione delle sessioni descritte in precedenza con contromisure aggiuntive sul lato client. Le protezioni lato client, in genere sotto forma di controlli e verifiche JavaScript, non sono a prova di proiettile e possono essere facilmente sconfitte da un aggressore esperto, ma possono introdurre un altro livello di difesa che deve essere aggirato dagli intrusi ^[4] .

Timeout di accesso iniziale

Le applicazioni Web possono utilizzare il codice JavaScript nella pagina di accesso per valutare e misurare il tempo trascorso da quando la pagina è stata caricata e è stato concesso un ID di sessione. Se viene tentato un tentativo di accesso dopo un determinato periodo di tempo, il codice client può notificare all'utente che è trascorso il tempo massimo per l'accesso e ricaricare la pagina di accesso, recuperando così un nuovo ID di sessione.

Questo meccanismo di protezione aggiuntivo cerca di forzare il rinnovo della pre-autenticazione dell'ID di sessione, evitando scenari in cui un ID di sessione precedentemente utilizzato (o impostato manualmente) viene riutilizzato dalla vittima successiva utilizzando lo stesso computer, ad esempio, negli attacchi di correzione della sessione.

Forza la disconnessione dalla sessione sugli eventi di chiusura della finestra del browser web

Le applicazioni Web possono utilizzare il codice JavaScript per acquisire tutte le schede del browser Web o gli eventi di chiusura (o anche indietro) della finestra e intraprendere le azioni appropriate per chiudere la sessione corrente prima di chiudere il browser Web, emulando che l'utente ha chiuso manualmente la sessione tramite il logout pulsante.

Disattiva le sessioni a campi incrociati del browser Web

Le applicazioni Web possono utilizzare il codice JavaScript una volta che l'utente ha effettuato l'accesso e una sessione è stata stabilita per forzare l'utente a eseguire nuovamente l'autenticazione se una nuova scheda o finestra del browser Web viene aperta per la stessa applicazione Web. L'applicazione Web non desidera consentire a più schede o finestre del browser Web di condividere la stessa sessione. Pertanto, l'applicazione tenta di forzare il browser Web a non condividere lo stesso ID di sessione contemporaneamente tra di loro.

Disconnessione automatica del client

Il codice JavaScript può essere utilizzato dall'applicazione Web in tutte le pagine (o critiche) per disconnettersi automaticamente dalle sessioni client allo scadere del timeout di inattività, ad esempio reindirizzando l'utente alla pagina di logout (la stessa risorsa utilizzata dal pulsante di logout menzionato in precedenza).

Il vantaggio di migliorare la funzionalità di timeout di inattività lato server con codice lato client è che l'utente può vedere che la sessione è terminata per inattività, o può anche essere avvisato in anticipo che la sessione sta per scadere tramite un conto alla rovescia e messaggi di avviso. Questo approccio intuitivo aiuta a evitare la perdita di lavoro nelle pagine Web che richiedono dati di input estesi a causa di sessioni scadute lato server.

Rilevamento degli attacchi di sessione

Indovinare ID sessione e rilevamento della forza bruta

Se un utente malintenzionato tenta di indovinare o forzare un ID di sessione valido, deve avviare più richieste sequenziali contro l'applicazione Web di destinazione utilizzando ID di sessione diversi da un singolo (o set di) indirizzi IP. Inoltre, se un utente malintenzionato cerca di analizzare la prevedibilità dell'ID di sessione (ad esempio utilizzando l'analisi statistica), deve lanciare più richieste sequenziali da un singolo (o insieme di) indirizzi IP contro l'applicazione web di destinazione per raccogliere nuovi validi ID di sessione ^[4] .

Le applicazioni Web devono essere in grado di rilevare entrambi gli scenari in base al numero di tentativi di raccogliere (o utilizzare) ID di sessione diversi e avvisare e/o bloccare gli indirizzi IP offensivi.

Rilevamento delle anomalie dell'ID di sessione

Le applicazioni Web dovrebbero concentrarsi sul rilevamento delle anomalie associate all'ID di sessione, come la sua manipolazione. Il progetto OWASP AppSensor fornisce un framework e una metodologia per implementare funzionalità di rilevamento delle intrusioni integrate all'interno di applicazioni Web incentrate sul rilevamento di anomalie e comportamenti imprevisti, sotto forma di punti di rilevamento e azioni di risposta. Invece di utilizzare livelli di protezione esterni, a volte i dettagli della logica di business e l'intelligence avanzata sono disponibili solo dall'interno dell'applicazione Web, dove è possibile stabilire più punti di rilevamento relativi alla sessione, ad esempio quando un cookie esistente viene modificato o eliminato, un nuovo cookie viene aggiunto, l'ID di sessione di un altro utente viene riutilizzato o quando la posizione dell'utente o l'agente utente cambia durante una sessione.

Associazione dell'ID sessione ad altre proprietà utente

Con l'obiettivo di rilevare (e, in alcuni scenari, proteggere da) comportamenti scorretti dell'utente e dirottamento della sessione, si consiglia vivamente di associare l'ID di sessione ad altre proprietà utente o client, come l'indirizzo IP del client, utente-agente o client certificato digitale basato su. Se l'applicazione Web rileva qualsiasi cambiamento o anomalia tra queste diverse proprietà nel mezzo di una sessione stabilita, questo è un ottimo indicatore della manipolazione della sessione e dei tentativi di dirottamento e questo semplice fatto può essere utilizzato per avvisare e/o terminare la sessione sospetta.

Sebbene queste proprietà non possano essere utilizzate dalle applicazioni Web per difendersi in modo affidabile dagli attacchi di sessione, aumentano notevolmente le capacità di rilevamento (e protezione) delle applicazioni Web. Tuttavia, un utente malintenzionato esperto può aggirare questi controlli riutilizzando lo stesso indirizzo IP assegnato all'utente vittima condividendo la stessa rete (molto comune negli ambienti NAT, come gli hotspot Wi-Fi ) o utilizzando lo stesso proxy Web in uscita (molto comune in ambienti aziendali) o modificando manualmente il suo agente utente in modo che appaia esattamente come fanno gli utenti vittima.

Ciclo di vita delle sessioni di registrazione: monitoraggio della creazione, dell'utilizzo e della distruzione degli ID di sessione

Le applicazioni Web dovrebbero aumentare le loro capacità di registrazione includendo informazioni riguardanti l'intero ciclo di vita delle sessioni. In particolare, si consiglia di registrare gli eventi relativi alla sessione, come la creazione, il rinnovo e la distruzione degli ID di sessione, nonché i dettagli sul suo utilizzo durante le operazioni di login e logout, le modifiche del livello di privilegio all'interno della sessione, la scadenza del timeout, la sessione non valida attività (se rilevate) e operazioni aziendali critiche durante la sessione.

I dettagli del registro potrebbero includere un timestamp, indirizzo IP di origine, risorsa di destinazione Web richiesta (e coinvolta in un'operazione di sessione), intestazioni HTTP (inclusi User-Agent e Referer), parametri GET e POST, codici e messaggi di errore, nome utente (o ID utente), più l'ID di sessione (cookie, URL, GET, POST...).

I dati sensibili come l'ID di sessione non devono essere inclusi nei registri al fine di proteggere i registri di sessione dalla divulgazione locale o remota dell'ID di sessione o da accessi non autorizzati. Tuttavia, è necessario registrare un certo tipo di informazioni specifiche della sessione per correlare le voci di registro a sessioni specifiche. Si consiglia di registrare un hash salato dell'ID di sessione invece dell'ID di sessione stesso per consentire la correlazione del registro specifica della sessione senza esporre l'ID di sessione.

In particolare, le applicazioni web devono proteggere a fondo le interfacce amministrative che permettano di gestire tutte le sessioni attive correnti. Spesso vengono utilizzati dal personale di supporto per risolvere problemi relativi alla sessione, o anche problemi generali, impersonando l'utente e osservando l'applicazione Web come fa l'utente.

I registri di sessione diventano una delle principali fonti di dati di rilevamento delle intrusioni nelle applicazioni Web e possono anche essere utilizzati dai sistemi di protezione dalle intrusioni per terminare automaticamente le sessioni e/o disabilitare gli account utente quando vengono rilevati (uno o più) attacchi. Se vengono implementate protezioni attive, anche queste azioni difensive devono essere registrate.

Accesso a sessioni simultanee

È la decisione di progettazione dell'applicazione Web determinare se sono consentiti più accessi simultanei dallo stesso utente dallo stesso o da indirizzi IP client diversi. Se l'applicazione Web non desidera consentire l'accesso simultaneo alla sessione, deve intraprendere azioni efficaci dopo ogni nuovo evento di autenticazione, terminando implicitamente la sessione precedentemente disponibile o chiedendo all'utente (tramite la vecchia, la nuova o entrambe le sessioni) la sessione che deve rimanere attivi.

Si consiglia alle applicazioni Web di aggiungere funzionalità utente che consentono di controllare i dettagli delle sessioni attive in qualsiasi momento, monitorare e avvisare l'utente degli accessi simultanei, fornire funzionalità utente per terminare manualmente le sessioni in remoto e tenere traccia della cronologia delle attività dell'account (registro) mediante registrazione più dettagli del client come indirizzo IP, agente utente, data e ora di accesso, tempo di inattività, ecc.

Protezioni WAF per la gestione delle sessioni

Ci sono situazioni in cui il codice sorgente dell'applicazione web non è disponibile o non può essere modificato, o quando le modifiche richieste per implementare le molteplici raccomandazioni sulla sicurezza e le migliori pratiche descritte sopra implicano una riprogettazione completa dell'architettura dell'applicazione web e, pertanto, non possono essere facilmente implementate a breve termine ^{[8] [4]} .

In questi scenari, o per completare le difese dell'applicazione web, e con l'obiettivo di mantenere l'applicazione web il più sicura possibile, si consiglia di utilizzare protezioni esterne come Web Application Firewall (WAF) in grado di mitigare le minacce di gestione delle sessioni già descritte.

I Web Application Firewall offrono funzionalità di rilevamento e protezione dagli attacchi basati sulla sessione. Da un lato, è banale per i WAF imporre l'utilizzo di attributi di sicurezza sui cookie, come i flag Secure e HttpOnly , applicando regole di riscrittura di base sull'intestazione Set-Cookie per tutte le risposte dell'applicazione web che impostano un nuovo cookie.

D'altra parte, è possibile implementare funzionalità più avanzate per consentire al WAF di tenere traccia delle sessioni e degli ID di sessione corrispondenti e di applicare tutti i tipi di protezione contro la correzione della sessione (rinnovando l'ID di sessione sul lato client quando i privilegi cambiano vengono rilevati), imponendo sessioni permanenti (verificando la relazione tra l'ID di sessione e altre proprietà del client, come l'indirizzo IP o User-Agent), o gestendo la scadenza della sessione (costringendo sia il client che l'applicazione web a finalizzare la sessione).

Il ModSecurity WAF open source, oltre al set di regole OWASP Core, fornisce funzionalità per rilevare e applicare gli attributi dei cookie di sicurezza, contromisure contro gli attacchi di fissazione della sessione e funzionalità di tracciamento della sessione per applicare sessioni permanenti.

Esempio

 session_start (
	'mySessionName' , 
	- expires = 1440 ,
	- usecookie = true
)
if ( session_result ( 'mySessionName' ) != 'load' ) => {
	session_addVar ( 'mySessionName' , 'sv_userId' )
	session_addVar ( 'mySessionName' , 'sv_userName' )
	session_addVar ( 'mySessionName' , 'sv_userEmail' )
	session_addVar ( 'mySessionName' , 'sv_favouriteColour' )
}

! var_defined ( 'sv_userId' ) ? var ( 'sv_userId' = integer )
! var_defined ( 'sv_userName' ) ? var ( 'sv_userName' = string )
! var_defined ( 'sv_userEmail' ) ? var ( 'sv_userEmail' = string )
! var_defined ( 'sv_favouriteColour' ) ? var ( 'sv_favouriteColour' = 'red' )

Note

Voci correlate

• Cookie
• Informatica
• Login
• Logout
• Utente

Portale Informatica

Portale Telecomunicazioni