Testarea vulnerabilităților de injectare SQL

Atacurile SQL Injection prezintă riscuri enorme pentru aplicațiile web care depind de un backend de baze de date pentru a genera conținut dinamic. În acest tip de atac, hackerii manipulează o aplicație web într-o încercare de a injecta propriile comenzi SQL în cele emise de baza de date. Pentru un exemplu, consultați articolul SQL Injection Attacks on Databases. În acest articol, analizăm mai multe moduri în care puteți testa aplicațiile web pentru a determina dacă acestea sunt vulnerabile la atacurile SQL Injection.

Scanare automată SQL Injection

O posibilitate este utilizarea unui scanner de vulnerabilitate pentru aplicații web automatizate, cum ar fi WebInspect al HP, AppScan-ul IBM sau Hailstorm-ul lui Cenzic. Aceste instrumente oferă metode simple și automate de analiză a aplicațiilor dvs. web pentru vulnerabilitățile SQL Injection potențiale. Cu toate acestea, sunt destul de scumpe, ajungând până la 25.000 $ pe loc.

Teste de injecție manuală SQL

Ce este un dezvoltator de aplicații sărac? Puteți executa de fapt câteva teste de bază pentru a evalua aplicațiile web pentru vulnerabilitățile SQL Injection folosind doar un browser web. În primul rând, un cuvânt de prudență: testele pe care le descriu doar caută defectele de bază SQL Injection. Ei nu vor detecta tehnici avansate și sunt oarecum obositoare de utilizat. Dacă vă puteți permite, mergeți cu un scaner automat. Cu toate acestea, dacă nu puteți gestiona acest preț, testarea manuală este un prim pas important.

Cea mai ușoară modalitate de a evalua dacă o aplicație este vulnerabilă este să experimentați atacuri inofensive de injectare, care nu vă vor afecta de fapt baza de date dacă reușesc, dar vă vor oferi dovezi că trebuie să corectați o problemă. De exemplu, să presupunem că aveți o aplicație web simplă care caută o persoană într-o bază de date și furnizează, prin urmare, informații de contact. Această pagină poate utiliza următorul format de adresă URL:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

Putem presupune că această pagină efectuează o căutare de bază de date, utilizând o interogare similară cu următoarea:

SELECTARE telefon FROM FROM WHERE ultimatename = 'chapple' și firstname = 'mike'

Să experimentăm puțin acest lucru. Prin presupunerea noastră de mai sus, putem face o simplă modificare a adresei URL care testează atacurile de tip SQL:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1

Dacă aplicația web nu a fost protejată corespunzător împotriva injecției SQL, aceasta se conectează pur și simplu la acest nume fals în instrucțiunea SQL pe care o execută împotriva bazei de date, rezultând:

SELECTARE telefon FROM FROM WHERE ultimatename = 'chapple' și firstname = 'mike' ȘI (selectați numărul (*) din fals)> 0 OR '1'

Veți observa că sintaxa de mai sus este puțin diferită de cea din adresa URL inițială. Mi-am permis libertatea de a converti variabila codată URL pentru echivalentele lor ASCII pentru a ușura urmărirea exemplului. De exemplu,% 3d este codarea URL a caracterului '='. De asemenea, am adăugat câteva rupturi de linie pentru scopuri similare.

Evaluarea rezultatelor

Testul apare când încercați să încărcați pagina web cu adresa URL menționată mai sus. Dacă aplicația web se comportă bine, va elimina singurele citate din intrare înainte de a trece interogarea în baza de date. Acest lucru va duce pur și simplu la o căutare ciudată pentru cineva cu un nume care include o grămadă de SQL! Veți vedea un mesaj de eroare din aplicație similar celui de mai jos:

Eroare: Niciun utilizator nu a fost găsit cu numele mike + ȘI + (selectați + număr (*) + de la + fals) +% 3e0 + OR + 1% 3d1 Chapple!

Pe de altă parte, dacă aplicația este vulnerabilă la injectarea SQL, aceasta va transmite declarația direct la baza de date, rezultând una din cele două posibilități. În primul rând, dacă serverul dvs. are mesaje de eroare detaliate activate (care nu ar trebui să!), Veți vedea ceva de genul:

Furnizorul Microsoft OLE DB pentru driverul ODBC eroare '80040e37' [Microsoft] [Driver SQL Server ODBC] [SQL Server] Nume de obiect nevalid "fals". /directory.asp, rândul 13

Pe de altă parte, dacă serverul dvs. web nu afișează mesaje de eroare detaliate, veți primi o eroare generică mai mare, cum ar fi:

Eroare internă a serverului Serverul a întâlnit o eroare internă sau o configurație eronată și nu a putut să vă completeze solicitarea. Vă rugăm să contactați administratorul serverului pentru a vă informa despre momentul producerii erorii și despre orice ați fi putut face, care ar fi cauzat eroarea. Mai multe informații despre această eroare pot fi disponibile în jurnalul de erori al serverului.

Dacă primiți una dintre cele două erori de mai sus, aplicația dvs. este vulnerabilă la atac de injecție SQL! Unele măsuri pe care le puteți lua pentru a vă proteja aplicațiile împotriva atacurilor SQL Injection includ:

• Implementați verificarea parametrilor pentru toate aplicațiile. De exemplu, dacă cereți unei persoane să introducă un număr de client, asigurați-vă că intrarea este numerică înainte de a executa interogarea .
• Limitați permisiunile contului care execută interogări SQL . Se aplică regula cu cel mai mic privilegiu. Dacă contul folosit pentru a executa interogarea nu are permisiunea de ao executa, nu va reuși!
• Utilizați proceduri stocate (sau tehnici similare) pentru a împiedica utilizatorii să interacționeze direct cu codul SQL.