ce este CRLF?

când un browser trimite o solicitare către un server web, serverul web răspunde cu un răspuns care conține atât anteturile de răspuns HTTP, cât și conținutul real al site-ului web, adică corpul de răspuns. Anteturile HTTP și răspunsul HTML (conținutul site-ului web) sunt separate printr-o combinație specifică de caractere speciale, și anume un retur de transport și un flux de linie. Pe scurt, ele sunt cunoscute și sub numele de CRLF.

serverul web folosește CRLF pentru a înțelege când începe antetul HTTP nou și se termină altul. CRLF poate spune, de asemenea, o aplicație web sau utilizator că o nouă linie începe într-un fișier sau într-un bloc de text. Caracterele CRLF sunt un mesaj standard HTTP / 1.1, deci este utilizat de orice tip de server web, inclusiv Apache, Microsoft IIS și toate celelalte.

care este vulnerabilitatea injecției CRLF?

într-un atac de vulnerabilitate prin injecție CRLF, atacatorul introduce atât caracterele de returnare a transportului, cât și caracterele linefeed în intrarea utilizatorului pentru a păcăli serverul, aplicația web sau utilizatorul să creadă că un obiect este terminat și altul a început. Ca atare, secvențele CRLF nu sunt caractere rău intenționate, cu toate acestea pot fi utilizate pentru intenția rău intenționată, pentru divizarea răspunsului HTTP etc.

injecție CRLF în aplicații web

în aplicații web o injecție CRLF poate avea un impact sever, în funcție de ceea ce face aplicația cu elemente unice. Impacturile pot varia de la dezvăluirea informațiilor la executarea codului, o vulnerabilitate directă a securității aplicațiilor web. De fapt, un atac de injecție CRLF poate avea repercusiuni foarte grave asupra unei aplicații web, chiar dacă nu a fost niciodată listat în lista OWASP Top 10. De exemplu, este de asemenea posibil să se manipuleze fișierele jurnal într-un panou de administrare așa cum este explicat în exemplul de mai jos.

un exemplu de injecție CRLF într-un fișier jurnal

Imaginați-vă un fișier jurnal într-un panou de administrare cu modelul fluxului de ieșire al căii vizitate în timp IP, cum ar fi cele de mai jos:

123.123.123.123 - 08:15 - /index.php?page=home

dacă un atacator este capabil de a injecta caracterele CRLF în cererea HTTP el este capabil de a schimba fluxul de ieșire și fals intrările jurnal. El poate schimba răspunsul din aplicația webs la ceva de genul de mai jos:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

%0d și %0a sunt formele codificate url ale CR și LF. Prin urmare, intrările de jurnal ar arăta astfel după ce atacatorul a introdus acele caractere și aplicația o afișează:

IP – Time – Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

prin urmare, prin exploatarea unei vulnerabilități de injecție CRLF, atacatorul poate falsifica intrările din fișierul jurnal pentru a-și ascunde propriile acțiuni rău intenționate. Atacatorul face literalmente deturnarea paginii și modificarea răspunsului. De exemplu, imaginați-vă un scenariu în care atacatorul are parola de administrator și a executat parametrul restrictedaction, care poate fi utilizat numai de un administrator.

problema este că, dacă administratorul observă că un IP necunoscut a folosit parametrul restrictedaction, va observa că ceva nu este în regulă. Cu toate acestea, din moment ce se pare că comanda a fost emisă de localhost (și, prin urmare, probabil de cineva care are acces la server, ca un administrator), nu pare suspect.

întreaga parte a interogării care începe cu %0d%0a va fi gestionată de server ca un parametru. După aceea, există un alt & cu parametrul restrictedactioncare va fi analizat de server ca un alt parametru. În mod eficient acest lucru ar fi aceeași interogare ca:

/index.php?page=home&restrictedaction=edit

divizarea răspunsului HTTP

descriere

deoarece antetul unui răspuns HTTP și corpul său sunt separate prin caractere CRLF, un atacator poate încerca să le injecteze. O combinație de CRLFCRLF va spune browserului că antetul se termină și corpul începe. Asta înseamnă că acum este capabil să scrie date în corpul de răspuns Unde este stocat codul html. Acest lucru poate duce la o vulnerabilitate de scriptare între site-uri.

un exemplu de divizare a răspunsului HTTP care duce la XSS

Imaginați-vă o aplicație care stabilește un antet personalizat, de exemplu:

X-Your-Name: Bob

valoarea antetului este setată printr-un parametru get numit „nume”. Dacă nu există codificare URL și valoarea este reflectată direct în antet, este posibil ca un atacator să introducă combinația CRLFCRLF menționată mai sus pentru a spune browserului că începe corpul de solicitare. În acest fel, el poate introduce date precum XSS payload, de exemplu:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

cele de mai sus vor afișa o fereastră de alertă în contextul domeniului atacat.

HTTP Header Injection

Description

prin exploatarea unei injecții CRLF, un atacator poate insera și anteturi HTTP care ar putea fi utilizate pentru a învinge mecanismele de securitate, cum ar fi filtrul XSS al unui browser sau aceeași politică de origine. Acest lucru permite atacatorului să obțină informații sensibile, cum ar fi jetoanele CSRF. De asemenea, poate seta cookie-uri care ar putea fi exploatate prin logarea victimei în contul atacatorului sau prin exploatarea vulnerabilităților de scripting cross-site (XSS) neexploatabile.

un exemplu de injecție Antet HTTP pentru a extrage date sensibile

dacă un atacator este capabil să injecteze anteturile HTTP care activează CORS (Cross Origin resource Sharing), el poate folosi javascript pentru a accesa resurse care sunt altfel protejate de SOP (aceeași politică de origine) care împiedică site-urile de origini diferite să se acceseze reciproc.

impactul vulnerabilității injecției CRLF

impactul injecțiilor CRLF variază și include, de asemenea, toate impactul Scriptării între site-uri la dezvăluirea informațiilor. De asemenea, poate dezactiva anumite restricții de securitate, cum ar fi filtrele XSS și aceeași politică de origine în browserele victimei, lăsându-le susceptibile la atacuri rău intenționate.

cum să preveniți injecțiile de antet CRLF/HTTP în aplicațiile Web

cea mai bună tehnică de prevenire este să nu folosiți intrarea utilizatorilor direct în anteturile de răspuns. Dacă acest lucru nu este posibil, ar trebui să utilizați întotdeauna o funcție pentru a codifica caracterele speciale CRLF. O altă bună practică de securitate a aplicațiilor web este să vă actualizați limbajul de programare la o versiune care nu permite injectarea CR și LF în interiorul funcțiilor care stabilesc anteturile HTTP.

tabelul de clasificare și severitate a vulnerabilității