Chiar dacă ați urmat numai evenimentele grupurilor de hackeri Anonymous și LulzSec, probabil că ați auzit despre site-uri și servicii care sunt hacked, 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 folosesc ș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
Ce este?
Un "refuz al serviciului" (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 web de pe serverul destinație nu sunt disponibile pentru a legitima cererile de trafic.
Cum functioneazã?
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ă efectueze 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 uneori "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.
Ce este?
Un atac de tip "SQL injection" (SQL injection) este un exploit care profită de tehnicile de dezvoltare web proaste ș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 acreditările, aplicația web poate executa o interogare precum:
SELECT UserID FROM Utilizatori WHERE Nume utilizator = "myuser" ȘI Password = "mypass";
Notă: valorile șirului dintr-o interogare SQL trebuie să fie închise în ghilimele simple, motiv pentru care apar în jurul valorilor introduse de utilizator.
Așadar, 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 introduse de utilizator pe formularul web:
SELECT UserID FROM Utilizatori WHERE UserName = "[utilizator]" și Password = "[pass]"
La prima vedere, acest lucru poate părea un pas simplu și logic pentru validarea ușoară a utilizatorilor, totuși dacă se face o simplă substituire 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 substituție simplă în interogarea noastră șablon, am obține acest lucru:
SELECT Nume utilizator FROM FROM WHERE UserName = "myuser" - "AND Password =" wrongpass "
O cheie la această afirmație 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 de utilizator, am depășit complet condiția de verificare a parolei și am putut să ne conectăm ca "myuser" fără a cunoaște 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 injectare SQL este cauzat de codificarea aplicațiilor neglijentă și iresponsabilă și este complet prevenit (pe care îl vom acoperi într-un moment), însă 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ă a cunoaște 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 să rețineți că unele aplicații web ar putea avea nevoie de acest tip de permisiune nu este automat un lucru rău că se acordă control complet.
Deci, pentru a ilustra daunele care pot fi cauzate în această situație, vom folosi exemplul furnizat în comicul de mai sus prin introducerea următoarelor în câmpul cu numele de utilizator: "Robert"; Utilizatori din tabelul DROP; - ". 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 și începutul unei instrucțiuni noi.
Ce se execută de către baza de date ca:
SELECT Nume utilizator de la utilizatori WHERE UserName = "Robert"DROP Utilizatori
Prin urmare, am folosit un atac SQLI pentru a șterge întregul tabel Utilizatori.
Desigur, mult mai rău poate fi făcut, deoarece, în funcție de permisiunile SQL permisibile, atacatorul poate schimba valori, tabele de dump (sau întreaga bază de date în sine) într-un fișier text, poate crea conturi de conectare noi sau poate chiar deturna întreaga instalare a bazei de date.
Prevenirea atacului de injectare SQL
Așa 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 acestea să nu poată fi folosite pentru a termina prematur un șir în interiorul unei instrucțiuni SQL.
De exemplu, dacă ați vrut să căutați "O'neil" într-o bază de date, nu ați putea folosi substituția 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 '- / wrongpass:
SELECT Nume utilizator FROM FROM WHERE UserName = "myuser" - "AND Password =" wrongpass "
Deoarece citatul unic după myuser este scăpat (adică este considerat o parte a valorii țintă), 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"; "Utilizatori DROP TABLE" - " în loc să executați ștergerea tabelului.
În timp ce atacurile web evoluează și devin mai sofisticate sau se concentrează pe un alt punct de intrare, este important să nu uitați să protejați împotriva atacurilor încercate și adevărate, care au fost sursa de inspirație a mai multor "instrumente de 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 altele, 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.
