Intoxicații în sesiune - Session poisoning

Intoxicația de sesiune (denumită și „poluarea datelor sesiunii” și „modificarea sesiunii”) este o metodă de a exploata o validare insuficientă a intrării în cadrul unei aplicații server. De obicei, o aplicație de server care este vulnerabilă la acest tip de exploatare va copia intrarea utilizatorului în variabilele de sesiune .

Vulnerabilitatea de bază este o problemă de gestionare a statului: stare comună, condiție de rasă , ambiguitate în utilizare sau modificări simple neprotejate ale valorilor de stat.

Intoxicația în sesiune a fost demonstrată în mediile serverului unde aplicații (scripturi) diferite, care nu sunt dăunătoare, împărtășesc aceleași stări de sesiune, dar în care utilizarea diferă, provocând ambiguitate și condiții de cursă.

Intoxicația în sesiune a fost demonstrată în scenarii în care atacatorul este capabil să introducă scripturi malițioase în mediul serverului, ceea ce este posibil dacă atacatorul și victima împărtășesc o gazdă web.

originile

Otrăvirea Sesiunea a fost discutată mai întâi ca (potențial nou) clasa de vulnerabilitate în dezvăluirea completă lista de discuții. Alla Bezroutchko a întrebat dacă „Vulnerabilitățile privind poluarea datelor din sesiuni în aplicațiile web” a fost o problemă nouă în ianuarie 2006. Cu toate acestea, aceasta a fost o veche vulnerabilitate remarcată anterior de către alții: „aceasta este o problemă clasică a managementului de stat” - Yvan Boily; „Acest lucru nu este nou” - / cineva.

Exemple anterioare ale acestor vulnerabilități pot fi găsite în resurse / arhive majore de securitate, cum ar fi Bugtraq , de ex

  • Iulie 2001, Gaura de securitate serioasă în Mambo Site Server versiunea 3.0.X de Ismael Peinado Palomo de la reverseonline.com
  • Septembrie 2005, modificarea sesiunii PHP de către necunoscut (din echipa uw) și adam_i

Poluarea în sesiuni a fost, de asemenea, acoperită în unele articole, precum PHP Session Security, Przemek Sobstel, 2007.

Exemple de atac

Scenariu de atac banal

Un exemplu de cod vulnerabil la această problemă este: 

Session("Login") = Request("login")
Session("Username") = Request("username")

Ceea ce este supus unor atacuri banale precum 

vulnerable.asp?login=YES&username=Mary

Această problemă ar putea exista în software unde

  • Utilizatorul trimite numele de utilizator / parola la logon.asp
  • Dacă parola pentru Marycheck-out, logon.asptransmiteți cătrevulnerable.asp?login=YES&username=Mary

Problema este că vulnerable.aspeste concepută pe baza presupunerii că pagina este accesată numai într-un mod non-rău intenționat. Oricine își dă seama cum este proiectat scriptul, este capabil să creeze o solicitare HTTP care stabilește în mod arbitrar utilizatorul de conectare.

Exploatarea utilizării ambigue sau duale a aceleiași variabile de sesiune

Alla Bezroutchko discută un scenariu în care $_SESSION['login']este folosit în două scopuri diferite.

  • În scripturile de conectare, variabila de sesiune stochează „Acest utilizator este conectat”.
  • În scripturile de resetare a parolei, variabila de sesiune stochează „acest utilizator își dorește resetarea parolei”.

S-a demonstrat o condiție de rasă, în care scripturile de resetare puteau fi exploatate pentru a schimba în mod arbitrar utilizatorul conectat.

Exploatarea scripturilor care permite scrierea la variabile de sesiune arbitrare

Alla Bezroutchko discută exemple observate în forumurile de dezvoltare, ceea ce permite scrierea unor variabile arbitrare.

Primul exemplu este 

$var = $_GET["something"]; 
$_SESSION["$var"] = $var2;

(în care $ _GET ["ceva"] provine probabil dintr-o casetă de selecție sau similar).

Atacul devine 

vulnerable.php?something=SESSION_VAR_TO_POISON

Atacuri de otrăvire în sesiune activate de php.ini: register_globals = on

php.ini: register_globals = oneste cunoscut pentru a activa vulnerabilitățile de securitate în mai multe aplicații. Administratorilor serverului PHP li se recomandă să dezactiveze această caracteristică.

Notă: exemple din lumea reală a otrăvirilor în sesiune activate de register_globals = on a fost demonstrat public înapoi în articolul din iulie 2001. O gaură serioasă de securitate în Mambo Site Server versiunea 3.0.X.

Al doilea exemplu de / cineva este

if ($condition1) { 
  $var = 'SOMETHING'; 
}; 
if ($condition2) { 
  $var = 'OTHER'; 
}; 
$_SESSION["$var"] = $var2;

care este vulnerabil dacă:

  • Este posibil ca atacatorul să facă falsă ambele condiții.
  • php.ini este neconfigurat (register_globals = on), ceea ce permite ca valoarea implicită $ var să fie controlată prin intrare GPC (GET, POST sau COOKIE).

Atacul devine 

vulnerable.php?var=SESSION_VAR_TO_POISON

Exploatare folosind un server PHP partajat (de exemplu, găzduire web comună)

„necunoscut” din uw-team.org discută un scenariu în care atacatorul și victima împărtășesc același server PHP.

Atacul este destul de ușor:

  • Atacatorul vizitează mai întâi pagina victimei și de ex.
  • Atacatorul apoi încarcă un script PHP în contul său și are un context afișat de $ _SESSION (setat de scriptul victimei).
  • Attacker stabilește ce variabilă trebuie schimbată, încarcă un script care stabilește această variabilă, o execută.
  • Atacatorul vizitează paginile victimelor pentru a vedea dacă funcționează exploatarea anticipată.

Acest atac necesită doar ca victima și atacatorul să împartă același server PHP. Atacul nu depinde de victima și atacatorul care au același nume de gazdă virtual, întrucât este banal pentru atacator să mute cookie-ul de identificare a sesiunii de la un domeniu cookie la altul.

Vezi si

Referințe