Tehnici de evitare

Puteţi spune că un atacator trebuie să deţină informaţii despre baza de date şi schema acesteia în majoritatea exemplelor. În majoritatea cazurilor aşa este, dar nu se ştie niciodată cum poate fi descoperită aceasta, în mod direct sau indirect. Dacă folosiţi un soft open source, sau alt pachet disponibil publicului larg (content management system sau forum), atacatorii pot duplica cu uşurinţă codul dumneavoastră. De asemenea un risc îl reprezintă şi designul necorespunzător al bazei de date.

Aceste atacuri sunt de obicei bazate pe exploatarea codului scris de developeri fără a lua în calcul securitatea lui. Niciodată nu aveţi încredere în nici un fel de input, mai ales când acesta provine din partea clientului, chiar dacă acesta vine dintr-un câmp select, câmp ascuns sau cookie. Primul exemplu arată că o interpelare aparent nevinovată poate cauza un dezastru.

• Niciodată nu vă conectaţi la baza de date ca superuser sau ca orice alt utilizator care poate manipula mai multe baze de date decât cea folosită. Folosiţi întotdeauna useri cu privilegii limitate.
• Verificaţi dacă un input conţine tipul de date corect. PHP are o varietate de funcţii de validare, de la cele mai simple, care pot fi găsite în Funcţii asupra variabilelor şi în Funcţii ale tipurilor de caractere (de ex. is_numeric(), ctype_digit() respectiv) şi până la Expresii regulate compatibile Perl.

• Dacă aplicaţia aşteaptă un input numeric, încercaţi să verificaţi datele cu funcţia is_numeric(), sau schimbaţi tipul variabilei utilizând funcţia settype(), sau folosiţi reprezentaţia numerică prin sprintf().

  Example #5 O metodă mai sigură de formare a interpelării pentru paginare

  <?php

settype($offset, 'integer');
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";

// observaţi %d (care înseamnă formatul integer) din string-ul de formatare,
// folosirea %s (string) ar fi fără sens
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
                 $offset);

?>

• Aplicaţi asupra fiecărei valori non-numerice furnizate de utilizator, ce va fi transmisă bazei de date, funcţia 'string escape' specifică fiecărei baze de date (de ex. mysql_real_escape_string(), sql_escape_string(), etc.). Dacă baza de date nu posedă un mecanism specific de 'string escape', pot fi utile funcţiile addslashes() şi str_replace() (în dependenţă de tipul bazei de date). Vedeţi primul exemplu. Dupa cum arată exemplul, adăugarea ghilimelelor în partea statică a interpelării nu este de ajuns, făcând-o susceptibilă la atacuri.
• Nu afişaţi informaţii specifice bazei de date, în special despre schema acesteia. Vedeţi de asemenea Raportarea erorilor şi Prelucrarea erorilor şi funcţii de logare.
• Puteţi utiliza proceduri stocate şi cursoare de date predefinite pentru a abstractiza accesul la date, pentru ca utilizatorii să nu interacţioneze direct cu tabelele sau viziunile, dar această soluţie poate avea alte consecinţe.

În afară de acestea, puteţi loga interpelările în interiorul scriptului şi în baza de date, dacă aceasta susţine acest lucru. Bineînţeles, logarea nu poate preveni atacurile sau încercările de a vătăma baza de date, dar poate fi utilă în depistarea aplicaţiei în care a avut loc incidentul. Log-ul nu este util prin sine, ci prin informaţia pe care o conţine. Mai multă detaliere este de obicei mai bună decât lipsa detaliilor.