26Aug
Chiar dacă ați urmat numai evenimentele din grupurile de hackeri Anonymous și LulzSec, probabil că ați auzit despre site-urile web și serviciile care au fost hackate, cum ar fi hack-urile infamous Sony. Te-ai întrebat vreodată cum o fac?
Există o serie de instrumente și tehnici pe care aceste grupuri le utilizează și, deși nu încercăm să vă oferim un manual pentru a face acest lucru singur, este util să înțelegeți ce se întâmplă.Două dintre atacurile pe care le auzi în mod constant despre ele sunt "Denial of Service"( DDoS) și "SQL Injections"( SQLI).Iată cum funcționează.
Imagine de xkcd
Denial of Service Attack
Ce este?
Un "refuz de serviciu"( uneori numit "denial distribuit de serviciu" sau DDoS) are loc atunci când un sistem, în acest caz un server web, primește atât de multe cereri la un moment dat că resursele serverului sunt supraîncărcate,și se închide. Scopul și rezultatul unui atac DDoS de succes este că site-urile de pe serverul destinație nu sunt disponibile pentru a legitima cererile de trafic.
Cum funcționează?
Logistica unui atac DDoS poate fi cel mai bine explicată printr-un exemplu.
Imaginați-vă că un milion de persoane( atacatorii) se reunesc cu scopul de a împiedica afacerea Companiei X prin luarea în jos a centrului de apeluri. Atacatorii se coordonează astfel încât, marți, la ora 9 dimineața, toți să sune la numărul de telefon al companiei X.Cel mai probabil, sistemul de telefonie al Companiei X nu va putea să gestioneze simultan un milion de apeluri, astfel încât toate liniile de intrare să fie legate de atacatori. Rezultatul este că apelurile legitime ale clienților( adică cele care nu sunt atacatorii) nu reușesc, deoarece sistemul telefonic este legat de manipularea apelurilor de la atacatori. Deci, în esență, Compania X își pierde potențial afacerea din cauza solicitărilor legitime care nu au putut să treacă.
Un atac DDoS pe un server web funcționează exact în același mod. Deoarece nu există practic nici o modalitate de a ști care este traficul provenit din cererile legitime împotriva atacatorilor, până când serverul web procesează cererea, acest tip de atac este de obicei foarte eficient.
Executarea atacului
Datorită naturii "forței brute" a unui atac DDoS, trebuie să aveți o mulțime de computere toate coordonate pentru a ataca în același timp. Revizuirea exemplului nostru de call center ar necesita ca toți atacatorii să știe să sune la 9 dimineața și să sune de fapt la acel moment. Deși acest principiu va funcționa cu siguranță atunci când vine vorba de atacarea unui server web, devine mult mai ușor atunci când sunt folosite computerele zombie, în loc de computerele reale cu echipaj.
După cum probabil știți, există o mulțime de variante de malware și troieni care, odată ce vă aflați în sistem, se află latente și ocazional "telefon acasă" pentru instrucțiuni. Una dintre aceste instrucțiuni ar putea fi, de exemplu, de a trimite solicitări repetate la serverul Web al companiei X la ora 9:00.Prin urmare, printr-o singură actualizare a locației la domiciliu a malware-ului respectiv, un singur atacator poate coordona instantaneu sute de mii de computere compromise pentru a efectua un atac masiv DDoS.
Frumusețea utilizării computerelor zombie nu este numai în eficiența sa, ci și în anonimatul său, deoarece atacatorul nu trebuie să utilizeze deloc computerul pentru a executa atacul.
SQL Injection Attack
Ce este?
Un atac de tip "SQL injection"( SQLI) este un exploit care profită de tehnicile de dezvoltare web slabă și, în mod obișnuit, combinat cu securitatea bazelor de date defecte. Rezultatul unui atac de succes poate varia de la impersonarea unui cont de utilizator la un compromis complet al bazei de date sau al serverului respectiv. Spre deosebire de un atac DDoS, un atac SQLI este complet și ușor de prevenit dacă o aplicație web este programată corespunzător.
Executarea atacului
De fiecare dată când vă conectați la un site Web și introduceți numele de utilizator și parola, pentru a vă testa datele de contact, aplicația web poate executa o interogare precum:
SELECT UserID FROM Utilizatori WHERE UserName = 'myuser'= 'mypass';
Notă: valorile șirului dintr-o interogare SQL trebuie să fie închise în citate unice, motiv pentru care apar în jurul valorilor introduse de utilizator.
Deci, combinația dintre numele de utilizator introdus( myuser) și parola( mypass) trebuie să se potrivească cu o intrare din tabelul Users, pentru ca un ID de utilizator să fie returnat. Dacă nu există nici o potrivire, nici un ID de utilizator nu este returnat, astfel încât acreditările de autentificare să fie nevalide.În timp ce o anumită implementare poate diferi, mecanica este destul de standard.
Deci, haideți să analizăm o interogare de autentificare a șabloanelor pe care o putem înlocui cu valorile pe care utilizatorul le introduce pe formularul web:
SELECT UserID FROM Utilizatori WHERE UserName = '[user]' și Password = '[pass]'
poate părea un pas simplu și logic pentru validarea cu ușurință a utilizatorilor, totuși dacă este efectuată o înlocuire simplă a valorilor introduse de utilizator pe acest șablon, este susceptibilă la un atac SQLI.
De exemplu, să presupunem că "myuser'-" este introdus în câmpul cu numele de utilizator și că "password wrongpass" este introdus în parolă.Folosind înlocuirea simplă în interogarea noastră șablon, am obține:
SELECT UserID FROM Utilizatori WHERE UserName = 'myuser' - 'AND Password =' wrongpass '
O cheie a acestei instrucțiuni este includerea celor două liniuțe( -).Acesta este jetonul de început pentru declarațiile SQL, astfel încât orice lucru care apare după cele două liniuțe( inclusiv) va fi ignorat.În esență, interogarea de mai sus este executată de către baza de date ca:
SELECT UserID FROM Utilizatori WHERE UserName = 'myuser'
Omisiunea flagrantă aici este lipsa verificării parolei. Prin includerea celor două liniuțe ca parte a câmpului utilizator, am depășit complet condiția de verificare a parolei și am putut să ne conectăm ca "myuser" fără să cunoaștem parola respectivă.Acest act de manipulare a interogării pentru a produce rezultate neintenționate este un atac de injecție SQL.
Ce prejudiciu se poate face?
Un atac de injecție SQL este cauzat de codificarea aplicațiilor neglijente și iresponsabile și este complet prevenit( pe care îl vom acoperi într-o clipă), cu toate acestea, amploarea daunelor care pot fi efectuate depinde de configurarea bazei de date. Pentru ca o aplicație web să comunice cu baza de date backend, aplicația trebuie să furnizeze o autentificare în baza de date( notați, aceasta este diferită de autentificarea unui utilizator pe site-ul propriu-zis).În funcție de permisiunile pe care le cere aplicația web, respectivul cont de baze de date poate necesita orice permisiune de citire / scriere în tabelele existente numai pentru accesul la baza de date completă.Dacă acest lucru nu este clar acum, câteva exemple ar trebui să ofere o anumită claritate.
Pe baza exemplului de mai sus, puteți vedea că introducând, de exemplu, "youruser" - "," admin "- sau orice alt nume de utilizator, ne putem conecta instant la site ca acel utilizator fără să știm parola. Odată ce ne aflăm în sistem, nu știm că nu suntem acel utilizator, deci avem acces deplin la contul respectiv. Permisiunile bazei de date nu vor furniza o plasă de siguranță pentru aceasta deoarece, de obicei, un site web trebuie să aibă cel puțin acces la citire / scriere la baza de date respectivă.
Acum, să presupunem că site-ul Web deține un control deplin asupra bazei sale de date, care oferă posibilitatea de a șterge înregistrări, de a adăuga / elimina tabele, de a adăuga noi conturi de securitate etc. Este important de reținut că unele aplicații web ar putea avea nevoie de acest tip de permisiunenu este în mod automat un lucru rău că se acordă control complet.
Pentru a ilustra daunele care pot fi facute in aceasta situatie, vom folosi exemplul furnizat in comicul de mai sus introducand urmatorul text in campul cu nume de utilizator: "Robert", Utilizatori DROP TABLE - ".După înlocuire simplă, interogarea de autentificare devine:
SELECT UserID FROM Utilizatori WHERE UserName = 'Robert';DROP TABLE Utilizatori - 'AND Password =' wrongpass '
Notă: punct și virgulă într-o interogare SQL este folosit pentru a indica sfârșitul unei instrucțiuni speciale și începutul unei instrucțiuni noi.
care se execută de către baza de date ca:
SELECT UserID FROM Utilizatori WHERE UserName = 'Robert'
DROP TABLE Utilizatorii
Așa că am folosit un atac SQLI pentru a șterge întregul tabel Users.
Desigur, mult mai rău se poate face, în funcție de permisiunile SQL permise, atacatorul poate modifica valori, tabele de bord( sau întreaga bază de date în sine) într-un fișier text, poate crea noi conturi de conectare sau poate chiar deturna întreaga instalare a bazei de date.
Prevenirea atacului SQL
După cum am menționat mai demult, un atac de injecție SQL este ușor de prevenit. Una dintre regulile cardinale ale dezvoltării web este că niciodată nu ai încredere în utilizatorii orbi, așa cum am făcut atunci când am efectuat o înlocuire simplă în interogarea noastră de șablon de mai sus.
Un atac SQLI este ușor împiedicat de ceea ce se numește dezinfecție( sau scaparea) intrărilor dvs. Procesul de dezinfectare este de fapt destul de banal, deoarece tot ceea ce face în mod esențial este manipularea oricărei caractere inline( ') în mod corespunzător astfel încât să nu poată fi folosite pentru a termina prematur un șir în interiorul unei instrucțiuni SQL.
De exemplu, dacă ați fi vrut să căutați "O'neil" într-o bază de date, nu ați putea folosi înlocuirea simplă, deoarece citatul unic după O va determina încheierea prematură a șirului.În schimb, o dezinfectați folosind caracterul de evacuare al bazei de date respective. Să presupunem că caracterul de evacuare pentru o citată inline unică precede fiecare citat cu un simbol. Deci "O'neal" ar fi dezinfectat ca "O" neil ".
Acest simplu act de salubritate previne cu mult un atac SQLI.Pentru a ilustra, să revedem exemplele noastre anterioare și să vedem interogările care rezultă atunci când intrarea utilizatorului este dezinfectată.
myuser '- / errorpass :
SELECT Nume utilizator FROM WHERE UserName =' myuser '-' AND Password = 'wrongpass'
Deoarece citatul unic după myuser este scapat( adică este considerat parte a țintăvaloare), baza de date va căuta literalmente numele UserName al "myuser" - ".În plus, deoarece liniuțele sunt incluse în valoarea șirului și nu în instrucțiunea SQL în sine, ele vor fi considerate parte din valoarea țintă în loc să fie interpretate ca un comentariu SQL.
Robert ';DROP TABLE Utilizatori; - / wrongpass :
SELECT UserID FROM Utilizatori WHERE UserName = 'Robert \';DROP TABLE Utilizatori - 'AND Password =' wrongpass '
Prin simpla scăpare a cotelor unice după Robert, atât punct și virgulă, cât și liniuțele sunt conținute în șirul de căutare UserName, astfel că baza de date va căuta literalmente "Robert";- "în loc să execute ștergerea tabelului.
În rezumat
În timp ce atacurile web evoluează și devin mai sofisticate sau se concentrează pe un alt punct de intrare, este important să ne amintim să protejăm împotriva atacurilor încercate și adevărate care au fost inspirația mai multor "instrumente hacker" disponibile în mod liber pentru a le exploata.
Anumite tipuri de atacuri, cum ar fi DDoS, nu pot fi ușor evitate în timp ce alții, cum ar fi SQLI, pot. Cu toate acestea, daunele care pot fi cauzate de aceste tipuri de atacuri pot varia de la un inconvenient la un dezastru, în funcție de precauțiile luate.