?v=54+sau+5459%3D5459&page=1
și ?v=54+sau+6721%3D8812&page=1
ar permite injecție SQL dacă codul care rulează interogarea ar folosi valorile transmise în adresa URL fără a le filtra, ca următorul cod, de exemplu. (Nu este codul pe care îl folosește modulul. Este doar codul care ar permite o injecție SQL.)
$statement = "selectați * din product_variation pv WHERE pv.id = {$_GET['v']}";
Interogările SQL ar fi în esență echivalente, respectiv, cu următoarele.
selectați * din product_variation pv unde pv.id = 54 sau 5459 = 5459
selectați * din product_variation pv unde pv.id = 54 sau 6721 = 8812
Prima interogare SQL ar returna toate rândurile din varianta_produs tabelul bazei de date, în timp ce a doua interogare ar returna doar rândul pentru care ID-ul este egal cu 54.
Modulele de bază Drupal și modulele contribuite nu concatenează valorile transmise de la utilizator (chiar prin adresa URL) cu șiruri literale pentru a construi șirul SQL, dar folosesc înlocuirea corectă a argumentelor, făcând injectarea SQL imposibilă.
De asemenea, nu permit utilizatorilor să furnizeze niciun operator la condiția unei interogări, ci setează o listă de operatori permiși și permit utilizatorilor să-i folosească numai pe aceștia.
Scanarea PCI a observat că a obținut două rezultate diferite (ADEVĂRAT
și FALS
) folosind ?v=54+sau+5459%3D5459&page=1
și ?v=54+sau+6721%3D8812&page=1
, interpretat ADEVĂRAT
la fel de există rânduri care se potrivesc cu interogarea și FALS
la fel de nu există rânduri care să corespundă interogării, și am crezut că injecția SQL a avut succes. (Cum poate spune scanarea PCI că accesarea adreselor URL care conțin acei parametri de interogare ar reveni ADEVĂRAT
și FALS
nici mie nu este clar.)
Nu asta sa întâmplat. Ceea ce raportat de scanare este un fals pozitiv.