Problema cu aplicațiile web este că sunt expuse în mod deschis la miliarde de utilizatori de internet, dintre care mulți vor dori să încalce măsurile de securitate – indiferent de motive..


În primele zile ale internetului, una dintre cele mai frecvente metode de atac era forța de bază brută simplă. De obicei, roboții au efectuat aceste atacuri – sau persoane cu timp îndelungat – care au încercat miliarde de combinații de nume de utilizator și parole până au găsit unul care să acorde acces la aplicația țintă..

Atacurile de forță brută nu mai sunt o amenințare, datorită politicilor de parole, încercărilor de conectare limitate și captcha-urilor. Dar criminalistii adora sa descopere noi exploatari si sa le foloseasca pentru a efectua noi tipuri de atacuri. Cu mult timp în urmă, au descoperit că câmpurile de text din aplicații sau pagini web pot fi exploatate introducând – sau injectând – text neașteptat în ele, care ar obliga aplicația să facă ceva ce nu trebuia să facă. În acest fel, așa-numitele atacuri de injecție au intrat în scenă.

Atacurile de injecție pot fi utilizate nu numai pentru a vă autentifica într-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 server întreg. De aceea, aceste atacuri nu sunt doar o amenințare pentru aplicațiile web, ci și pentru utilizatorii ale căror date se află pe respectivele aplicații și, în cele mai grave cazuri, pentru alte aplicații și servicii conectate..

Injectarea codului

Injectarea cu cod este unul dintre cele mai frecvente tipuri de atacuri de injecție. Dacă atacatorii cunosc limbajul de programare, cadrul, baza de date sau sistemul de operare utilizat de o aplicație web, pot injecta cod prin câmpuri de introducere text pentru a forța serverul de internet să facă ceea ce vor.

Aceste tipuri de atacuri de injecție sunt posibile pentru aplicații care nu au validare a datelor de intrare. Dacă un câmp de introducere de text permite utilizatorilor să introducă tot ce doresc, atunci aplicația este potențial exploatabilă. Pentru a preveni aceste atacuri, aplicația trebuie să restricționeze atât cât poate permite utilizatorilor de intrare.

De exemplu, trebuie să limiteze cantitatea de date preconizate, să verifice formatul de date î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 text a unei aplicații web cu diferite tipuri de conținut. Când sunt găsite, vulnerabilitățile sunt moderat greu de exploatat. Dar 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 injecția de cod, acest atac introduce 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 o execută direct în baza de date. Drept urmare, atacatorul ar putea trece printr-un ecran de autentificare sau poate face lucruri mai periculoase, cum ar fi citit date sensibile direct din baza de date, modificarea sau distrugerea datelor din baza de date sau executarea operațiunilor de administrare din baza de date..

Aplicațiile PHP și ASP sunt predispuse la atacuri de 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 constată o vulnerabilitate la injecția SQL – și pot fi găsite cu ușurință – amploarea atacurilor potențiale va fi limitată doar de îndemânarea și imaginația atacatorului. Astfel, impactul unui atac de injecție SQL este, fără îndoială, mare.

Comanda injecție

Aceste atacuri sunt de asemenea posibile, în principal din cauza validării insuficiente a intrării. Acestea diferă de atacurile de injecție de cod, prin faptul că atacatorul introduce comenzile sistemului în loc de piese de cod de programare sau scripturi. Prin urmare, hackerul nu trebuie să cunoască limbajul de programare pe 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 inserate 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, pentru afișarea structurii de directoare a unui server, pentru modificarea parolelor utilizatorului, printre altele.

Aceste atacuri pot fi prevenite de către un sysadmin, prin limitarea nivelului de acces al sistemului al aplicațiilor web care rulează pe un server.

Scripturi cross-site

Ori de câte ori o aplicație introduce introducerea de la un utilizator în ieșirea pe care o generează, fără a o valida sau codifica, aceasta oferă posibilitatea unui atacator de a trimite cod rău intenționat unui utilizator final diferit. Atacurile cross-site Scripting (XSS) profită de aceste oportunități pentru a injecta scripturi rău intenționate pe site-uri web de încredere, care sunt trimise în final 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, cookie-uri sau informații sensibile stocate de browser. Dacă este programat corect, scripturile ar putea chiar rescrie conținutul unui fișier HTML.

Atacurile XSS pot fi împărțite în general în două categorii diferite: stocate și reflectate.

În stocate Atacuri XSS, scriptul rău intenționat se află permanent pe serverul țintă, într-un forum de mesaje, într-o bază de date, într-un jurnal de vizitatori, etc. Victima îl primește atunci când browserul său solicită informațiile stocate. În reflectat Atacuri XSS, scriptul rău intenționat este reflectat într-un răspuns care include intrarea trimisă serverului. 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 datele XML. Modul în care funcționează acest atac este similar cu injecția SQL: atacatorii trimit informații malformate aplicației pentru a afla cum sunt structurate datele XML, iar apoi atacă din nou pentru a accesa aceste date.

XPath este un limbaj standard cu care, precum SQL, puteți specifica atributele pe care doriți să le găsiți. Pentru a efectua o interogare pe datele XML, aplicațiile web folosesc introducerea utilizatorului pentru a seta un model cu care datele ar trebui să se potrivească. Prin trimiterea unei intrări incorecte, 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 folosește date XML, indiferent de implementare. Aceasta înseamnă, de asemenea, că atacul poate fi automatizat; prin urmare, spre deosebire de injecția SQL, are potențialul de a fi concediat împotriva unui număr arbitrar de obiective.

Injectarea comenzii prin poștă

Această metodă de atac poate fi folosită pentru a exploata serverele de e-mail și aplicațiile care creează instrucțiuni IMAP sau SMTP cu o introducere 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 poștă, atacatorii ar putea sustrage restricții precum captcha, 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ă înlocuiască restricțiile serverului și să utilizeze serviciile sale pentru a trimite spam.

Injectarea IMAP se poate face în principal pe aplicații de e-mail, 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 unei adrese URL cu comenzile injectate.

Injectare CRLF

Inserarea caracterelor de retur și de alimentare a liniei – combinația cunoscută sub numele de CRLF – în câmpurile de introducere a formei web reprezintă o metodă de atac numită injecție 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 pe aplicații web vulnerabile care nu aplică filtrarea corespunzătoare intrării utilizatorului. Această vulnerabilitate deschide ușa către alte tipuri de atacuri de injecție, cum ar fi XSS și injectarea de cod, și ar putea deriva, de asemenea, ca un site web să fie deturnat.

Injecție antet gazdă

În serverele care găzduiesc numeroase site-uri web sau aplicații web, antetul gazdei devine necesar pentru a determina care dintre site-urile web sau aplicațiile web rezidențiale – de cele mai multe ori cunoscute drept gazdă virtuală – ar trebui să proceseze o solicitare primită. Valoarea antetului spune serverului către care dintre gazdele virtuale să trimită o solicitare. Când serverul primește un antet de gazdă nevalid, acesta îl transmite, de regulă, la prima gazdă virtuală din listă. Aceasta constituie o vulnerabilitate pe care atacatorii o pot folosi pentru a trimite antete de gazdă arbitrare către prima gazdă virtuală a unui server.

Manipularea antetului gazdelor este în mod obișnuit legată de aplicațiile PHP, deși se poate face și cu alte tehnologii de dezvoltare web. Atacurile cu antetul gazdelor funcționează ca activatori pentru alte tipuri de atacuri, cum ar fi intoxicația cu cache-uri web. Consecințele sale ar putea include executarea operațiunilor sensibile de către atacatori, de exemplu resetările cu parolă.

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 intraneturi, iar atunci când este utilizat ca parte a unui singur sistem de conectare, poate fi folosit pentru a stoca numele de utilizator și parolele. Interogările LDAP implică utilizarea de caractere speciale de control care afectează controlul său. Atacatorii pot modifica potențial comportamentul intenționat al unei interogări LDAP dacă pot insera caractere de control în ea.

Din nou, problema rădăcină care permite atacurile de injecție LDAP este validată în mod necorespunzător. Dacă textul pe care îl trimite un utilizator către o aplicație este utilizat ca parte a unei interogări LDAP fără a-l igieniza, interogarea ar putea ajunge să recupereze o listă cu toți utilizatorii și să o arate unui atacator, doar folosind un asterisc (*) din dreapta plasați în interiorul unui șir de intrare.

Prevenirea atacurilor injectabile

După cum am văzut în acest articol, toate atacurile de 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 serverului.

Dezvoltatorii de aplicații trebuie să cunoască riscurile implicate de validarea incorectă a intrării utilizatorului și să învețe cele mai bune practici pentru igienizarea intrărilor utilizatorilor cu scopuri de prevenire a riscurilor. Administratorii serverului trebuie să-și auditeze sistemele periodic pentru a detecta vulnerabilitățile și pentru a le corecta cât mai curând posibil. Există multe opțiuni pentru a efectua aceste audituri, fie la cerere, fie automat.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me