Securitatea aplicatiilor WEB – partea a II-a

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 a 2-a parte a prezentarii tipurilor de atac cu care pot fi compromise aplicatiile WEB: SQL Injection, Session Hijacking sau Session Fixation.

Una din componentele cele mai sensibile ale unei aplicatii web, este baza de date. Aceasta retine informatie obtinuta cumulativ, in timp, care valorifica (financiar, informational) aplicatia in sine. Exemple de astfel de informatii:

• utilizatori autentificati;
• post-uri (in cazul forum-urilor);
• produse si comentarii la produse;

Pierderea acestor informatii produce, pe langa ne-functionare, de-valorizarea aplicatiei in sine. Spre exemplu, valoarea unei aplicatii de social-networking este data (pe langa functionalitati, implementare, design, etc), de numarul de persoane care o folosesc, mai general, de cantitatea de informatii pe care aplicatia o pune la dispozitie.

Or, aceasta informatie este de valoare critica pentru o aplicatie, si ea trebuie protejata.

Un prim pas este realizarea de back-up-uri regulate ale informatiilor. In continuare, vom examina alte situatii vulnerabile care conduc la compromiterea bazei de date, si solutii de evitare a acestora.

Solutii de protejare:

1. limitarea accesului la anumite fisiere de pe server; in Apache, acest lucru se poate face editand httpd.conf, astfel:

<Files ~ "\.inc$">
    Order allow,deny
    Deny from all
</Files>

2. folosirea unei extensii care forteaza evaluarea script-ului, spre deosebire de afisarea lui ca-atare

Expunerea de informatii in fisiere

Majoritatea aplicatiilor web care interactioneaza cu baze de date, retin informatiile de conectare in fisiere auxiliare.

Exemplu:

define ('ADDRESS', 'localhost');
define ('DATABASE', 'bazadate');
define ('USERNAME' , 'root');
define ('PASSWORD', '');

Sa presupunem ca fisierul care contine codul de mai sus se numeste constants.inc, si ca se afla in directorul root al aplicatiei. Cel mai probabil, acesta va fi inclus de un script php, astfel : require_once(‘constants.inc’);. Daca insa un utilizator intuieste (sau alege la intamplare), numele acestui fisier, il poate accesa, astfel:

http://localhost/path/to/constants.inc

Cum nici browserul nici serverul nu au informatii despre extensia *.inc, continutul acestui fisier este intors utilizatorului ca si text. Consecintele sunt intuitive. Username-ul si parola pentru conectarea la baza de date sunt compromise, si implicit continutul acesteia.

SQL Injection

SQL Injection se refera la injectarea de cod SQL malitios, la rularea unui query.

Fie urmatorul script, care construieste un query, pe baza unui formular primit:

$query = "INSERT
          INTO   users (username,
                        password,
                        email)
          VALUES ('{$_POST['username']}',
                  '$autoPassword',
                  '{$_POST['email']}')";

Variabila $autoPassword reprezinta o parola generata automat, care poate fi trimisa utilizatorului via email, la crearea contului. Sa afisam acest query, pentru niste valori conventionale trimise prin formular:

INSERT INTO users (username, password, email) VALUES ('user', '6d0f846348a856321729', 'email')

Ce se intampla insa daca un utilizator, completeaza campul username cu urmatoarea valoare:

bad_guy', 'mypass', ''), ('good_guy

Daca afisam query-ul executat de script, obtinem:

INSERT INTO users (username, password, email) VALUES ('bad_guy', 'mypass', ''), ('good_guy', '6d0f846348a856321729', 'email')

Efectul este vizibil: un utilizator nou este adaugat, cu o parola deja setata.

Aparent, rezultatul acestei vulnerabilitati nu este foarte grav, insa putem considera urmatorul context:

• in locul functiei query, folosim functia multi_query, care permite rularea de instructiuni multiple
• trimitem in locul unui nume de utilizator, sirul:

some_guy', '', '');  DROP TABLE criticaltable; --

Query-ul produs, va fi urmatorul:

INSERT INTO users (username, password, email) VALUES ('some_guy', '', ''); DROP TABLE criticaltable; --', 'ba2fd310dcaa8781a9a6', 'email')

Observatii:

• Caracterele – reprezinta comentarii; comentariile anuleaza restul expresiei SQL
• In ipoteza existentei tabelului criticalTable, acesta va fi sters
• Mai grav, instructiunea SQL DROP TABLE … putea fi inlocuita cu DROP DATABASE …, avand un efect usor de imaginat.
• Chiar si in cazul in care folosim functia query, care executa un singur query, SQL Injection poate fi folosit in formule (de sintaxa) mai complicate, pentru a produce efecte grave asupra bazei de date (spre exemplu: extragerea de informatii)

Modalitati de protejare:

• filtrarea oricarei informatii provenite din formulare, indiferent de metoda folosita (acceptarea valorilor care respecta un pattern pre-stabilit, si respingerea a orice nu respecta acest pattern)
• folosirea functiei membru real_escape_string din clasa mysqli; detalii: http://www.php.net/manual/en/mysqli.real-escape-string.php

Securitatea WEB – Session Hijacking

Un astfel de atac este posibil, daca session id-ul unui utilizator este compromis. Acest lucru este foarte posibil, tinand cont de faptul ca session-id-ul este direct vizibil. Iata un exemplu de header HTTP, care expune session_id-ul.

Header-ul provine de la un script care seteaza o sesiune:

HTTP/1.1 200 OK 
Date: Wed, 17 Mar 2010 18:31:47 GMT 
Server: Apache/2.2.11 (Win32) PHP/5.2.8 X-Powered-By: PHP/5.2.8 
Set-Cookie: PHPSESSID=ls2pd33foiidr5ld6gkpqo94d0; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT 
Content-Length: 0 
Connection: close 
Content-Type: text/html

Observati linia PHPSESSID=ls2pd33foiidr5ld6gkpqo94d0;, care expune session id-ul. Incluzand acest session id intr-o cerere HTTP, un atacator poate obtine credentialele utilizatorului, pe aplicatia web vulnerabila.

In continuare prezentam un script PHP care afiseaza continutul header-ului primit dupa o cerere GET de la un server.

<?php
        $url = parse_url('http://example.com/session.php');
	$host = $url['host'];
	$path = $url['path'];
 
	$fp = fsockopen($host, 80);
	// send the request headers:
	fputs($fp, "GET $path HTTP/1.1\r\n");
	fputs($fp, "Host: $host\r\n");
	fputs($fp, "Connection: close\r\n\r\n");
 
	$result = ''; 
	while(!feof($fp)) {
		// receive the results of the request
		$result .= fgets($fp, 128);
	}
	// close the socket connection:
	fclose($fp);
 
	// split the result header from the content
	$result = explode("\r\n\r\n", $result, 2);
 
	$header = isset($result[0]) ? $result[0] : '';
	$content = isset($result[1]) ? $result[1] : '';
 
	echo $header;
?>

Securitatea WEB – Session Fixation

Ca si Session Hijacking, Session Fixation se bazeaza pe folosirea session id-ului unui utilizator, insa fara a-l fura, ci impunandu-l.

Un utilizator poate accesa un link care ii fixeaza un anume session id, care apoi e folosit ca id de sesiune, la autentificarea pe o aplicatie. Folosind id-ul fixat, atacatorul poate beneficia pe aplicatia vulnerabila, de privilegiile utilizatorului.

Detalii despre Session Fixation: http://en.wikipedia.org/wiki/Session_fixation

Related posts:

1. Securitatea aplicatiilor WEB – partea I
2. Aspecte cheie ale dezvoltarii aplicatiilor WEB
3. Prezentare (X)HTML, CSS si HTML 5
4. PHP – stabilirea unei conexiuni la Baza de Date
5. Formulare HTML – setarea de sesiuni si cookies in PHP