Meniu

Tutorial SQL Testing Injection (Exemplu și prevenirea atacului SQL Injection)

  • Principal
  • Testare Web
  • Tutorial SQL Testing Injection (Exemplu și prevenirea atacului SQL Injection)

sql injection testing tutorial example

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

videoclipuri de vizionat cu cască vr

SQL Injection Exemple și modalități de prevenire a atacurilor SQL Injection pe aplicații Web

În timpul testării unui site web sau a unui sistem, scopul testerului este de a se asigura dacă produsul testat este cât mai protejat posibil.

Testarea de securitate se efectuează de obicei în acest scop. Pentru a efectua acest tip de testare, inițial, trebuie să luăm în considerare care sunt cele mai susceptibile atacuri. SQL Injection este unul dintre aceste atacuri.

Exemplu și prevenire atașare injecție SQL

SQL Injection este considerat unul dintre cele mai frecvente atacuri, deoarece poate aduce consecințe grave și dăunătoare sistemului dvs. și datelor sensibile.

Ce veți învăța:

Ce este SQL Injection?

Unele dintre datele de intrare ale utilizatorului ar putea fi utilizate în cadrul Instrucțiuni SQL care sunt apoi executate de aplicația din baza de date. Este posibil ca o aplicație să nu gestioneze corect intrările date de utilizator.

Daca acesta este cazul, un utilizator rău intenționat ar putea furniza intrări neașteptate aplicației care sunt apoi utilizate pentru a încadra și executa instrucțiuni SQL în baza de date. Aceasta se numește injecție SQL. Consecințele unei astfel de acțiuni ar putea fi alarmante.

După cum sugerează și numele, scopul atacului SQL Injection este de a injecta codul SQL rău intenționat.

Fiecare câmp al unui site web este ca o poartă către baza de date. În formularul de conectare, utilizatorul introduce datele de conectare, în câmpul de căutare utilizatorul introduce un text de căutare, în formularul de salvare a datelor, utilizatorul introduce date pentru a fi salvate. Toate aceste date indicate sunt trimise în baza de date.

În loc de date corecte, dacă este introdus vreun cod rău intenționat, există posibilitatea ca unele baze de date și întregul sistem să se producă daune grave.

SQL Injection se realizează cu limbajul de programare SQL. SQL (Structured Query Language) este utilizat pentru gestionarea datelor păstrate în baza de date. Prin urmare, în timpul acestui atac, acest cod de limbaj de programare este folosit ca injecție rău intenționată.

Acesta este unul dintre cele mai populare atacuri, deoarece bazele de date sunt utilizate pentru aproape toate tehnologiile.

Multe aplicații folosesc un anumit tip de bază de date. O aplicație testată poate avea o interfață cu utilizatorul care acceptă introducerea utilizatorului care este utilizată pentru a efectua următoarele sarcini:

# 1) Arătați datele relevante stocate utilizatorului, de ex. aplicația verifică acreditările utilizatorului folosind informațiile de conectare introduse de utilizator și expune utilizatorului doar funcționalitatea și datele relevante

#Două) Salvați datele introduse de utilizator în baza de date de ex. odată ce utilizatorul completează un formular și îl trimite, aplicația continuă să salveze datele în baza de date; aceste date sunt apoi puse la dispoziția utilizatorului în aceeași sesiune, precum și în sesiunile ulterioare

Riscurile injecției SQL

În prezent, o bază de date este utilizată pentru aproape toate sistemele și site-urile web, deoarece datele ar trebui stocate undeva.

Deoarece datele sensibile sunt stocate în baza de date, există mai multe riscuri implicate în securitatea sistemului. Dacă orice site personal sau date ale blogului ar fi furate, atunci nu vor fi multe daune în comparație cu datele care ar fi furate din sistemul bancar.

Scopul principal al acestui atac este piratarea bazei de date a sistemului, prin urmare consecințele acestui atac pot fi cu adevărat dăunătoare.

Următoarele lucruri pot rezulta din SQL Injection

  • Spargerea contului altei persoane.
  • Furtul și copierea datelor sensibile ale site-ului web sau ale sistemului.
  • Modificarea datelor sensibile ale sistemului.
  • Ștergerea datelor sensibile ale sistemului.
  • Utilizatorul se putea conecta la aplicație ca alt utilizator, chiar și ca administrator.
  • Utilizatorul ar putea vizualiza informații private aparținând altor utilizatori, de ex. detalii despre profilurile altor utilizatori, detalii despre tranzacții etc.
  • Utilizatorul ar putea modifica informațiile de configurare a aplicației și datele celorlalți utilizatori.
  • Utilizatorul ar putea modifica structura bazei de date; chiar ștergeți tabelele din baza de date a aplicației.
  • Utilizatorul ar putea prelua controlul serverului bazei de date și poate executa comenzi pe el după bunul plac.

Riscurile enumerate mai sus pot fi considerate cu adevărat grave, deoarece restaurarea unei baze de date sau a datelor sale poate costa foarte mult. Vă poate costa compania o reputație și bani pentru a restabili datele și sistemul pierdut. Prin urmare, este foarte recomandat să vă protejați sistemul împotriva acestui tip de atac și să considerați testarea de securitate ca o investiție bună în reputația produsului și a companiei.

În calitate de tester, aș dori să comentez, că testarea împotriva posibilelor atacuri este o practică bună chiar dacă Testarea securității nu a fost planificat. În acest fel puteți proteja și testa produsul împotriva cazurilor neașteptate și a utilizatorilor rău intenționați.

Esența acestui atac

Așa cum am menționat mai devreme, esența acestui atac este de a pirata baza de date cu un scop rău intenționat.

Pentru a efectua acest test de securitate, inițial, trebuie să găsiți părțile vulnerabile ale sistemului și apoi să trimiteți cod SQL rău intenționat prin baza de date. Dacă acest atac este posibil pentru un sistem, atunci va fi trimis codul SQL rău intenționat și pot fi efectuate acțiuni dăunătoare în baza de date.

Fiecare câmp al unui site web este ca o poartă către baza de date. Orice date sau intrări pe care le introducem de obicei în orice câmp al sistemului sau site-ului web sunt trimise la interogarea bazei de date. Prin urmare, în loc de date corecte, dacă am introduce un cod rău intenționat, atunci acesta poate fi executat în interogarea bazei de date și poate aduce consecințe dăunătoare.

Instrument recomandat

# 1) Kiuwan

kiuwan banner

Găsiți cu ușurință și remediați vulnerabilitățile, cum ar fi injecția SQL în codul dvs., în fiecare etapă a SDLC. Kiuwan este conform cu cele mai stricte standarde de securitate, inclusiv OWASP, CWE, SANS 25, HIPPA și multe altele.

Integrați Kiuwan în IDE pentru feedback instantaneu în timpul dezvoltării. Kiuwan acceptă toate limbajele de programare majore și se integrează cu instrumentele DevOps de top.

=> Scanați codul gratuit

Pentru efectuarea acestui atac, trebuie să schimbăm actul și scopul unei interogări adecvate în baza de date. Una dintre metodele posibile de realizare a acestuia este de a face interogarea întotdeauna adevărată și după aceea introduceți codul dvs. rău intenționat. Schimbarea interogării bazei de date la întotdeauna adevărată poate fi efectuată cu cod simplu, cum ar fi „sau 1 = 1; -.

Esența injecției SQL

Testatorii ar trebui să țină cont de faptul că, în timp ce verificați dacă schimbarea interogării în întotdeauna adevărată poate fi realizată sau nu, trebuie încercate citate diferite - simple și duble. Prin urmare, dacă am încercat codul cum ar fi ‘sau 1 = 1; -, ar trebui să încercăm și codul cu ghilimele duble„ sau 1 = 1; -.

Esența injecției SQL

De exemplu, să considerăm că avem o interogare, care caută cuvântul introdus în tabelul bazei de date:

selectați * din note nt unde nt.subject = ‘căutare_ cuvânt’;

Prin urmare, în loc de cuvântul de căutare, dacă introducem o interogare SQL Injection ‘sau 1 = 1; -, atunci interogarea va deveni întotdeauna adevărată.

selectați * din note nt unde nt.subject = ‘‘ sau 1 = 1; -

În acest caz, parametrul „subiect” este închis cu ghilimele și apoi avem codul sau 1 = 1, ceea ce face ca o interogare să fie întotdeauna adevărată. Cu semnul „-“ comentăm restul codului de interogare, care nu va fi executat. Este una dintre cele mai populare și mai simple modalități de a începe să controlați interogarea.

Puține alte coduri pot fi, de asemenea, utilizate pentru a face interogarea întotdeauna adevărată, cum ar fi:

  • 'Sau' abc '=' abc '; -
  • ‘Sau‘ ‘=‘ ‘; -

Cea mai importantă parte aici este că după semnul virgulă putem introduce orice cod rău intenționat, pe care am dori să îl executăm.

De exemplu, poate fi ‘sau 1 = 1; note de tabel; -

Note pentru tabel

Dacă această injecție este posibilă, poate fi scris orice alt cod rău intenționat. În acest caz, va depinde doar de cunoștințele și intenția utilizatorului rău intenționat. Cum se verifică injecția SQL?

Verificarea acestei vulnerabilități poate fi efectuată foarte ușor. Uneori este suficient să tastați ‘sau„ să vă conectați la câmpurile testate. Dacă returnează orice mesaj neașteptat sau extraordinar, atunci putem fi siguri că injecția SQL este posibilă pentru acel câmp.

De exemplu , dacă primiți un mesaj de eroare ca „Eroare internă a serverului” ca rezultat al căutării, atunci putem fi siguri că acest atac este posibil în acea parte a sistemului.

Alte rezultate care pot notifica un posibil atac includ:

  • Pagină goală încărcată.
  • Fără mesaje de eroare sau de succes - funcționalitatea și pagina nu reacționează la intrare.
  • Mesaj de succes pentru codul rău intenționat.

Să ne uităm în jur la modul în care funcționează acest lucru în practică.

De exemplu, Să testăm dacă o fereastră de conectare adecvată este vulnerabilă pentru SQL Injection. În acest scop, în câmpul de adresă de e-mail sau parolă, tastăm semnul, așa cum se arată mai jos.

Adresa de email

Dacă o astfel de intrare returnează rezultatul, cum ar fi mesajul de eroare „Eroare internă a serverului” sau orice alt rezultat necorespunzător listat, atunci putem fi aproape siguri că acest atac este posibil pentru acel câmp.

eroare interna a serverului

Un lucru foarte complicat Cod de injecție SQL poate fi de asemenea încercat. Aș dori să menționez că în cariera mea nu am întâlnit niciun caz când a apărut mesajul „Internal Server Error” ca urmare a semnului, dar uneori câmpurile nu au reacționat pentru un cod SQL mai complicat.

Prin urmare, verificarea pentru SQL Injection cu un singur citat „este o modalitate destul de demnă de încredere de a verifica dacă acest atac este posibil sau nu.

Dacă ghilimelul unic nu returnează niciun rezultat neadecvat, atunci putem încerca să introducem ghilimele duble și să verificăm rezultatele.

Citat unic

De asemenea, codul SQL pentru schimbarea interogării în întotdeauna adevărat poate fi considerat o modalitate de a verifica dacă acest atac este posibil sau nu. Închide parametrul și schimbă interogarea în „adevărat”. Prin urmare, dacă nu este validat, o astfel de intrare poate, de asemenea, să returneze orice rezultat neașteptat și să informeze același lucru, că acest atac este posibil în acest caz.

Esența injecției SQL

Verificarea eventualelor atacuri SQL poate fi efectuată și de pe linkul site-ului web. Să presupunem că avem linkul unui site web ca http://www.testing.com/books=1 . În acest caz, „cărți” este un parametru, iar „1” este valoarea acestuia. Dacă în linkul furnizat am scrie „semn în loc de 1, atunci am verifica dacă există o posibilă injecție.

Prin urmare legătură http://www.testing.com/books= va fi ca un test dacă atacul SQL este posibil pentru site-ul web http://www.testing.com sau nu.

Link de testare

În acest caz, dacă link http://www.testing.com/books= returnează un mesaj de eroare precum „Eroare internă a serverului” sau o pagină goală sau orice alt mesaj de eroare neașteptat, atunci putem fi siguri că este posibilă injectarea SQL pentru acel site web. Mai târziu, putem încerca să trimitem cod SQL mai complicat prin linkul site-ului web.

Pentru a verifica dacă acest atac este posibil prin intermediul link-ului site-ului sau nu, poate fi trimis cod precum „sau 1 = 1; -

Testarea legăturilor

În calitate de tester software cu experiență, aș dori să reamintesc că nu numai mesajul de eroare neașteptat poate fi considerat o vulnerabilitate SQL Injection. Mulți testeri verifică eventualele atacuri numai în conformitate cu mesajele de eroare.

Cu toate acestea, trebuie amintit că niciun mesaj de eroare de validare sau mesaj de succes pentru codul rău intenționat nu poate fi, de asemenea, un semn, că acest atac este posibil.

Testarea securității aplicațiilor web împotriva injecției SQL

Testarea securității aplicațiilor web explicată cu exemple simple:

Deoarece consecințele permiterii acestei tehnici de vulnerabilitate ar putea fi severe, rezultă că acest atac ar trebui testat în timpul testării de securitate a unei aplicații. Acum, cu o prezentare generală a acestei tehnici, permiteți-ne să înțelegem câteva exemple practice de injecție SQL.

Important: Acest test de injecție SQL trebuie testat numai în mediul de testare.

Dacă aplicația are o pagină de conectare, este posibil ca aplicația să utilizeze SQL dinamic, cum ar fi declarația de mai jos. Se așteaptă ca această instrucțiune să returneze cel puțin un singur rând cu detaliile utilizatorului din tabelul Utilizatori ca set de rezultate atunci când există un rând cu numele de utilizator și parola introduse în instrucțiunea SQL.

SELECTAȚI * DE LA UTILIZATORII UNDE User_Name = ‘” & strUserName & „‘ AND Password = ‘” & strPassword & '’; '

Dacă testerul ar introduce John ca strUserName (în caseta de text pentru numele de utilizator) și Smith ca strPassword (în caseta de text pentru parolă), instrucțiunea SQL de mai sus ar deveni:

SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;

Dacă testerul ar introduce John’– ca strUserName și nu strPassword, instrucțiunea SQL ar deveni:

SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;

Rețineți că partea din instrucțiunea SQL după John este transformată într-un comentariu. Dacă în tabelul Utilizatori ar exista un utilizator cu numele de utilizator al lui John, aplicația ar putea permite testerului să se conecteze ca utilizator al lui John. Testatorul putea vedea acum informațiile private ale utilizatorului John.

Ce se întâmplă dacă testerul nu știe numele vreunui utilizator existent al aplicației? Într-un astfel de caz, testerul ar putea încerca nume de utilizator obișnuite, cum ar fi admin, administrator și sysadmin. Dacă niciunul dintre acești utilizatori nu există în baza de date, testerul ar putea introduce John ’sau‘ x ’=’ x ca strUserName și Smith ’sau‘ x ’=’ x ca strPassword. Acest lucru ar face ca declarația SQL să devină ca cea de mai jos.

SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;

Deoarece condiția „x” = „x” este întotdeauna adevărată, setul de rezultate ar consta din toate rândurile din tabelul Utilizatori. Aplicația ar putea permite testerului să se conecteze ca primul utilizator din tabelul Utilizatori.

Important: testerul ar trebui să solicite administratorului bazei de date sau dezvoltatorului să copieze tabelul în cauză înainte de a încerca următoarele atacuri.

Dacă testerul ar intra pe John ’; Tabela DROP users_details; ’- ca strUserName și orice altceva ca strPassword, instrucțiunea SQL ar deveni ca cea de mai jos.

SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';

Această declarație ar putea determina ca tabelul „utilizatori_detalii” să fie șters definitiv din baza de date.

Deși exemplele de mai sus se referă la utilizarea tehnicii de injecție SQL numai pe pagina de autentificare, testerul ar trebui să testeze această tehnică pe toate paginile aplicației care acceptă introducerea utilizatorului în format textual, de ex. pagini de căutare, pagini de feedback etc.

Injecția SQL ar putea fi posibilă în aplicațiile care utilizează SSL. Chiar și un firewall ar putea să nu poată proteja aplicația împotriva acestei tehnici.

Am încercat să explic această tehnică de atac într-o formă simplă. Aș dori să reiterați că acest atac ar trebui testat numai într-un mediu de testare și nu în mediul de dezvoltare, mediu de producție sau orice alt mediu.

cel mai bun downloader video de pe orice site

În loc să testați manual dacă aplicația este vulnerabilă la atac SQL sau nu, s-ar putea folosi un Scanner de vulnerabilități web care verifică această vulnerabilitate.

Lectură conexă: Testarea securității aplicației web . Verificați acest lucru pentru mai multe detalii despre diferite vulnerabilități web.

Părți vulnerabile ale acestui atac

Înainte de a începe procesul de testare, fiecare tester sincer ar trebui să știe mai mult sau mai puțin ce părți ar fi cele mai vulnerabile la acest atac posibil.

De asemenea, este o bună practică să planificați ce domeniu al sistemului urmează să fie testat exact și în ce ordine. În cariera mea de testare, am învățat că nu este o idee bună să testezi câmpurile împotriva atacurilor SQL în mod aleatoriu, deoarece unele câmpuri pot fi ratate.

Deoarece acest atac este efectuat în baza de date, toate componentele sistemului de introducere a datelor, câmpurile de intrare și linkurile site-ului web sunt vulnerabile.

Părțile vulnerabile includ:

  • Câmpuri de autentificare
  • Caută câmpuri
  • Câmpuri de comentarii
  • Orice alte câmpuri de introducere și salvare a datelor
  • Link-uri către site-ul web

Este important să observați că, în timp ce testați împotriva acestui atac, nu este suficient să verificați doar unul sau câteva câmpuri. Este destul de obișnuit ca un câmp să fie protejat împotriva injecției SQL, dar altul nu. Prin urmare, este important să nu uitați să testați toate câmpurile site-ului web.

Automatizarea testelor de injecție SQL

Deoarece unele sisteme sau site-uri web testate pot fi destul de complicate și conțin date sensibile, testarea manuală poate fi cu adevărat dificilă și necesită mult timp. Prin urmare, testarea împotriva acestui atac cu instrumente speciale poate fi uneori foarte utilă uneori.

Un astfel de instrument SQL Injection este SOAP UI . Dacă avem teste de regresie automate la nivelul API, putem comuta și verificarea împotriva acestui atac folosind acest instrument. În instrumentul SOAP UI, există deja șabloane de cod pregătite pentru verificarea împotriva acestui atac. Aceste șabloane pot fi, de asemenea, completate de propriul cod scris.

Este un instrument destul de fiabil.

Cu toate acestea, un test ar trebui deja automatizat la nivelul API, ceea ce nu este atât de ușor. O altă modalitate posibilă de a testa automat este utilizând diverse plugin-uri pentru browser.

Trebuie menționat faptul că, chiar dacă instrumentele automate vă economisesc timpul, acestea nu sunt considerate întotdeauna foarte fiabile. Dacă testăm un sistem bancar sau orice site web cu date foarte sensibile, este foarte recomandat să îl testăm manual. Unde puteți vedea rezultatele exacte și le puteți analiza. De asemenea, în acest caz, putem fi siguri, că nimic nu a fost omis.

Comparație cu alte atacuri

SQL Injection poate fi considerat unul dintre cele mai grave atacuri, deoarece influențează baza de date și poate afecta grav datele și întregul sistem.

Cu siguranță, poate avea consecințe mai grave decât o injecție Javascript sau o injecție HTML, deoarece ambele sunt efectuate din partea clientului. Pentru comparație, cu acest atac, puteți avea acces la întreaga bază de date.

Trebuie menționat că, pentru a testa împotriva acestui atac, ar trebui să aveți cunoștințe destul de bune despre limbajul de programare SQL și, în general, ar trebui să știți cum funcționează interogările bazelor de date. De asemenea, în timp ce efectuați acest atac de injecție, ar trebui să fiți mai atent și mai atent, deoarece orice inexactitate poate fi lăsată ca vulnerabilități SQL.

Concluzie

Sper că ați avea o idee clară despre ce este o injecție SQL și cum ar trebui să prevenim aceste atacuri.

Cu toate acestea, este foarte recomandat să testați împotriva acestui tip de atac de fiecare dată când este testat un sistem sau un site web cu o bază de date. Orice vulnerabilitate a bazei de date sau a sistemului din stânga poate costa reputația unei companii și o mulțime de resurse pentru a restabili întregul sistem.

Deoarece testarea împotriva acestei injecții ajută la găsirea celor mai multe vulnerabilități importante de securitate , de asemenea, este recomandat să investiți în cunoștințele și instrumentele de testare.

Dacă testarea securității este planificată, atunci testarea împotriva injecției SQL ar trebui să fie planificată ca una dintre primele părți de testare.

Ați întâlnit vreo injecție SQL tipică? Simțiți-vă liber să împărtășiți experiențele dvs. în secțiunea de comentarii de mai jos.

Lectură recomandată

^