Problema aplicațiilor web este că sunt expuse în mod deschis la miliarde de utilizatori de internet, mulți dintre care vor dori să-și încalce măsurile de securitate – indiferent de motive.
În primele zile ale internetului, una dintre cele mai comune metode de atac era forța brută simplă, de bază. De obicei, roboții au efectuat aceste atacuri – sau persoane cu mult timp liber – care au încercat miliarde de combinații de nume de utilizator și parole până când au găsit una care să acorde acces la aplicația țintă.
Atacurile cu forță brută nu mai reprezintă o amenințare, datorită politicilor de parole, încercărilor limitate de conectare și captchas-ului. Dar infractorilor cibernetici le place să descopere noi exploatații și să le folosească pentru a efectua noi tipuri de atacuri. Cu mult timp în urmă, ei au descoperit că câmpurile de text din aplicații sau pagini web ar putea fi exploatate prin introducerea – sau injectarea – de text neașteptat în ele care ar forța aplicația să facă ceva ce nu ar fi trebuit să facă. În acest fel, în scenă au intrat așa-numitele atacuri cu injecție.
Atacurile prin injectare pot fi folosite nu numai pentru a vă conecta la o aplicație fără a cunoaște numele de utilizator și parola, ci și pentru a expune informații private, confidențiale sau sensibile sau chiar pentru a deturna un întreg server. De aceea, aceste atacuri nu reprezintă doar o amenințare pentru aplicațiile web, ci și pentru utilizatorii ale căror date se află pe acele aplicații și, în cel mai rău caz, pentru alte aplicații și servicii conectate.
Cuprins
Injectarea codului
Injecția de cod este unul dintre cele mai comune tipuri de atacuri prin injecție. Dacă atacatorii cunosc limbajul de programare, cadrul, baza de date sau sistemul de operare folosit de o aplicație web, aceștia pot injecta cod prin câmpuri de introducere a textului pentru a forța serverul web să facă ceea ce doresc.
Aceste tipuri de atacuri prin injecție sunt posibile în aplicațiile care nu au validarea datelor de intrare. Dacă un câmp de introducere a textului permite utilizatorilor să introducă ceea ce doresc, atunci aplicația este potențial exploatabilă. Pentru a preveni aceste atacuri, aplicația trebuie să restricționeze cât de mult poate utilizatorii de intrare au voie să intre.
De exemplu, trebuie să limiteze cantitatea de date așteptate, să verifice formatul datelor înainte de a le accepta și să restricționeze setul de caractere permise.
Vulnerabilitățile de injectare de cod pot fi ușor de găsit, doar testând introducerea textului unei aplicații web cu diferite tipuri de conținut. Când sunt găsite, vulnerabilitățile sunt moderat greu de exploatat. Dar atunci când un atacator reușește să exploateze una dintre aceste vulnerabilități, impactul ar putea include pierderea confidențialității, integrității, disponibilității sau funcționalității aplicației.
injecție SQL
În mod similar cu injectarea de cod, acest atac inserează un script SQL – limbajul folosit de majoritatea bazelor de date pentru a efectua operațiuni de interogare – într-un câmp de introducere a textului. Scriptul este trimis aplicației, care îl execută direct în baza sa de date. Drept urmare, atacatorul ar putea trece printr-un ecran de autentificare sau poate face lucruri mai periculoase, cum ar fi să citească date sensibile direct din baza de date, să modifice sau să distrugă datele bazei de date sau să execute operațiuni de administrare în baza de date.
Aplicațiile PHP și ASP sunt predispuse la atacuri cu injecție SQL datorită interfețelor sale funcționale mai vechi. Aplicațiile J2EE și ASP.Net sunt de obicei mai protejate împotriva acestor atacuri. Când se găsește o vulnerabilitate de injectare SQL – și ar putea fi găsită cu ușurință – amploarea atacurilor potențiale va fi limitată doar de priceperea și imaginația atacatorului. Astfel, impactul unui atac de injecție SQL este, fără îndoială, mare.
Injecție de comandă
Aceste atacuri sunt, de asemenea, posibile, în principal din cauza validării intrărilor insuficiente. Ele diferă de atacurile cu injecție de cod prin faptul că atacatorul introduce comenzi de sistem în loc de bucăți de cod de programare sau scripturi. Prin urmare, hackerul nu trebuie să cunoască limbajul de programare în care se bazează aplicația sau limba folosită de baza de date. Dar trebuie să cunoască sistemul de operare folosit de serverul de găzduire.
Comenzile de sistem introduse sunt executate de sistemul de operare gazdă cu privilegiile aplicației, ceea ce ar putea permite expunerea conținutului fișierelor arbitrare care se află pe server, afișarea structurii directoarelor unui server, schimbarea parolelor utilizatorului, printre altele. .
Aceste atacuri pot fi prevenite de un administrator de sistem, prin limitarea nivelului de acces la sistem al aplicațiilor web care rulează pe un server.
Scripturi între site-uri
Ori de câte ori o aplicație inserează o intrare de la un utilizator în ieșirea pe care o generează, fără a o valida sau a codifica, aceasta oferă unui atacator posibilitatea de a trimite cod rău intenționat unui alt utilizator final. Atacurile Cross-Site Scripting (XSS) profită de aceste oportunități pentru a injecta scripturi rău intenționate în site-uri web de încredere, care sunt în cele din urmă trimise altor utilizatori ai aplicației, care devin victimele atacatorului.
Browserul victimelor va executa scriptul rău intenționat fără să știe că nu ar trebui să fie de încredere. Prin urmare, browserul îi va permite să acceseze jetoane de sesiune, cookie-uri sau informații sensibile stocate de browser. Dacă sunt programate corect, scripturile ar putea chiar rescrie conținutul unui fișier HTML.
Atacurile XSS pot fi, în general, împărțite în două categorii diferite: stocate și reflectate.
În atacurile XSS stocate, scriptul rău intenționat rezidă permanent pe serverul țintă, într-un forum de mesaje, într-o bază de date, într-un jurnal al vizitatorilor etc. Victima îl primește atunci când browser-ul său solicită informațiile stocate. În atacurile XSS reflectate, scriptul rău intenționat este reflectat într-un răspuns care include intrarea trimisă către server. Acesta poate fi un mesaj de eroare sau un rezultat al căutării, de exemplu.
Injecție XPath
Acest tip de atac este posibil atunci când o aplicație web folosește informațiile furnizate de un utilizator pentru a construi o interogare XPath pentru date XML. Modul în care funcționează acest atac este similar cu injecția SQL: atacatorii trimit informații malformate către aplicație pentru a afla cum sunt structurate datele XML, apoi atacă din nou pentru a accesa acele date.
XPath este un limbaj standard cu care, la fel ca SQL, puteți specifica atributele pe care doriți să le găsiți. Pentru a efectua o interogare asupra datelor XML, aplicațiile web folosesc intrarea utilizatorului pentru a seta un model cu care datele ar trebui să se potrivească. Prin trimiterea unei intrări neformate, modelul se poate transforma într-o operațiune pe care atacatorul dorește să o aplice datelor.
Spre deosebire de ceea ce se întâmplă cu SQL, în XPath, nu există versiuni diferite. Aceasta înseamnă că injecția XPath se poate face pe orice aplicație web care utilizează date XML, indiferent de implementare. Asta înseamnă, de asemenea, că atacul poate fi automatizat; prin urmare, spre deosebire de injecția SQL, are potențialul de a fi lansat împotriva unui număr arbitrar de obiective.
Injectarea comenzii prin e-mail
Această metodă de atac poate fi utilizată pentru a exploata serverele de e-mail și aplicațiile care construiesc instrucțiuni IMAP sau SMTP cu intrare de utilizator validată incorect. Ocazional, serverele IMAP și SMTP nu au o protecție puternică împotriva atacurilor, așa cum ar fi cazul majorității serverelor web și, prin urmare, ar putea fi mai exploatabile. Intrând printr-un server de e-mail, atacatorii ar putea sustrage restricții precum captchas, un număr limitat de solicitări etc.
Pentru a exploata un server SMTP, atacatorii au nevoie de un cont de e-mail valid pentru a trimite mesaje cu comenzi injectate. Dacă serverul este vulnerabil, acesta va răspunde solicitărilor atacatorilor, permițându-le, de exemplu, să depășească restricțiile serverului și să-și folosească serviciile pentru a trimite spam.
Injectarea IMAP ar putea fi făcută în principal pe aplicații de webmail, exploatând funcționalitatea de citire a mesajelor. În aceste cazuri, atacul poate fi efectuat prin simpla introducere, în bara de adrese a unui browser web, a unui URL cu comenzile injectate.
injecție CRLF
Inserarea caracterelor de întoarcere a căruciorului și de avans de linie – combinație cunoscută sub numele de CRLF – în câmpurile de introducere a formularului web reprezintă o metodă de atac numită injectare CRLF. Aceste caractere invizibile indică sfârșitul unei linii sau sfârșitul unei comenzi în multe protocoale tradiționale de internet, cum ar fi HTTP, MIME sau NNTP.
De exemplu, inserarea unui CRLF într-o solicitare HTTP, urmată de un anumit cod HTML, ar putea trimite pagini web personalizate vizitatorilor unui site web.
Acest atac poate fi efectuat asupra aplicațiilor web vulnerabile care nu aplică filtrarea adecvată la intrarea utilizatorului. Această vulnerabilitate deschide ușa către alte tipuri de atacuri de injectare, cum ar fi XSS și injectarea de cod, și ar putea, de asemenea, să decurgă dintr-un site web deturnat.
Injectare antet gazdă
În serverele care găzduiesc multe site-uri web sau aplicații web, antetul gazdei devine necesar pentru a determina care dintre site-urile sau aplicațiile web rezidente – fiecare dintre ele cunoscute ca gazdă virtuală – ar trebui să proceseze o solicitare de intrare. Valoarea antetului îi spune serverului căruia dintre gazdele virtuale să trimită o cerere. Când serverul primește un antet de gazdă nevalid, de obicei îl transmite primei gazde virtuale din listă. Aceasta constituie o vulnerabilitate pe care atacatorii o pot folosi pentru a trimite anteturi de gazdă arbitrare la prima gazdă virtuală dintr-un server.
Manipularea antetului gazdă este de obicei legată de aplicațiile PHP, deși se poate face și cu alte tehnologii de dezvoltare web. Atacurile cu antetul gazdei funcționează ca elemente de activare pentru alte tipuri de atacuri, cum ar fi otrăvirea cache-ului web. Consecințele sale ar putea include executarea de operațiuni sensibile de către atacatori, de exemplu, resetarea parolei.
injecție LDAP
LDAP este un protocol conceput pentru a facilita căutarea resurselor (dispozitive, fișiere, alți utilizatori) într-o rețea. Este foarte util pentru intranet, iar atunci când este utilizat ca parte a unui sistem de conectare unică, poate fi folosit pentru a stoca nume de utilizator și parole. Interogările LDAP implică utilizarea caracterelor de control speciale care îi afectează controlul. Atacatorii pot modifica comportamentul dorit al unei interogări LDAP dacă pot introduce caractere de control în ea.
Din nou, problema rădăcină care permite atacurile de injecție LDAP este intrarea utilizatorului validată incorect. Dacă textul pe care un utilizator îl trimite unei aplicații este folosit ca parte a unei interogări LDAP fără a-l igieniza, interogarea ar putea ajunge să preia o listă cu toți utilizatorii și să o arate unui atacator, doar folosind un asterisc.
în locul potrivit în interiorul unui șir de intrare.
Prevenirea atacurilor de injectare
După cum am văzut în acest articol, toate atacurile prin injecție sunt direcționate către servere și aplicații cu acces deschis oricărui utilizator de internet. Responsabilitatea de a preveni aceste atacuri este distribuită între dezvoltatorii de aplicații și administratorii de servere.
Dezvoltatorii de aplicații trebuie să cunoască riscurile implicate de validarea incorectă a intrărilor utilizatorului și să învețe cele mai bune practici pentru a igieniza inputul utilizatorului în scopuri de prevenire a riscurilor. Administratorii de servere trebuie să-și auditeze periodic sistemele pentru a detecta vulnerabilități și a le corecta cât mai curând posibil. Există multe opțiuni pentru a efectua aceste audituri, fie la cerere, fie automat.