Web14: Probleme de securitate în protocolul HTTP

Acest articol prezintă câteva probleme de securitate în protocolul HTTP , ridicate în două documente RFC 7230 și RFC 7231. Exemplele din articolul despre erori specifice sunt menționate de la OWASP.

1. Riscuri din factori intermediari

HTTP permite utilizarea intermediarilor pentru a răspunde solicitărilor printr-o serie de conexiuni. Există trei elemente intermediare comune: proxy, gateway și tunel.

O cerere sau un răspuns va trebui să treacă prin punctele A, B și C. Aceștia pot accesa informațiile sensibile transmise, cum ar fi informațiile personale ale utilizatorilor sau ale organizațiilor. Lipsa de atenție acordată securității și confidențialității de către intermediari poate duce la o gamă largă de potențiale atacuri.

Dezvoltatorii de sisteme și dezvoltatorii ar trebui să ia în considerare factorii de confidențialitate și securitate în timpul procesului de proiectare, codificare și implementare a sistemului.

Utilizatorii trebuie să fie conștienți de pericolele utilizării proxy-urilor sau gateway-urilor care nu sunt de încredere.

2. Divizarea răspunsului

Divizarea răspunsului (alias injecție CRLF) este o tehnică populară de exploatare web. Atacatorul trimite date codificate, în unii parametri de cerere, care sunt apoi decodate și repetate într-un anumit câmp al antetului răspunsului.

Dacă aceste date sunt un simbol care reprezintă sfârșitul răspunsului și este inițiat un răspuns ulterior, răspunsul inițial va fi împărțit în două, iar conținutul celui de-al doilea răspuns va fi controlat de atacator. Atacatorul poate face apoi o altă solicitare în cadrul aceleiași conexiuni persistente și poate păcăli destinatarul (inclusiv intermediarii) să creadă că acest al doilea răspuns este ca răspuns la a doua cerere.

3. Solicitați contrabandă

Contrabanda cererilor este o tehnică care exploatează diferențele în procesarea cererilor de către diferite tipuri de servere pentru a ascunde cererile aparent inofensive atașate cererii inițiale.

Să luăm în considerare următorul exemplu:

Să presupunem că o solicitare POST conține două câmpuri „Lungimea conținutului” în antet cu două valori diferite. Unele servere vor refuza această solicitare (IIS și Apache), dar altele nu. De exemplu, SunONE W/S 6.1 folosește mai întâi câmpul Content-length, în timp ce sunONE Proxy 3.6 ia pe al doilea câmpul Content-length.

Presupunând că SITE este DNS-ul unui SunONE W/S, situat în spatele unui SunONE Proxy, există un fișier poison.html situat pe SunONE W/S. Iată cum să exploatezi HTTP Request Suggling pe baza inconsistențelor în procesarea între două servere:

[Rețineți că fiecare linie se termină cu un CRLF (""), cu excepția liniei 10]

Să luăm în considerare ce se întâmplă atunci când o solicitare este trimisă către W/S prin serverul Proxy. Mai întâi, proxy-ul va analiza cererea de la rândurile 1 la 7 (albastru) și va întâlni două câmpuri Content-Length. După cum sa menționat mai sus, va ignora primul câmp și va înțelege că corpul cererii are 44 de octeți. Prin urmare, tratează datele de la liniile 8 la 10 ca primul corp de solicitare (de la liniile 8 la 10, datele au exact 44 de octeți). Proxy-ul va analiza apoi liniile 11 până la 14 (în roșu) ca a doua cerere a clientului.

Acum să vedem cum interpretează W/S datele de mai sus, deoarece sunt transmise de la proxy. Spre deosebire de proxy, W/S va folosi primul câmp Content-Length și îl va interpreta după cum urmează: prima solicitare nu are corp, iar a doua cerere începe de la linia 8 (rețineți că W/S va analiza de la linia 11 în continuare ca valoare al câmpului Bla).

În continuare, să vedem cum răspunsul este returnat clientului. Solicitarea pe care W/S o înțelege este „POST /foobar.html” (de la linia 1) și „GET /poison.html” (de la linia 8), așa că va trimite clientului 2 răspunsuri cu conținutul paginii foobar. html și otravă.html. Proxy-ul înțelege că aceste 2 răspunsuri corespund a 2 solicitări: „POST /foobar.html” (de pe linia 1) și „GET /page_to_poison.html” (linia 11). Proxy-ul va stoca în cache conținutul paginii poison.html corespunzătoare adresei URL „page_to_poison.html” (otrăvirea cache). De acolo, atunci când clientul solicită „page_to_poison.html” va primi conținutul paginii poison.html.

4. Atacul bazat pe calea fișierului

Serverele web își folosesc frecvent sistemul de fișiere local pentru a gestiona maparea numelor de fișiere din URI-uri la resursele reale de pe server. Majoritatea sistemelor de fișiere nu sunt concepute pentru a proteja împotriva căilor de fișiere rău intenționate. Prin urmare, serverul trebuie să evite accesarea fișierelor importante de sistem.

De exemplu, UNIX, Microsoft Windows și alte câteva sisteme de operare folosesc „..” ca element de cale pentru a reprezenta un director cu un nivel deasupra fișierului/directorului curent. Fără un control și autorizare adecvată a intrării, fișierele/folderele sensibile ale sistemului pot fi accesate prin introducerea căilor care indică aceste fișiere/foldere.

5. Tipuri de atacuri: Command Injection, Code Injection, Query Injection

[Serverele web folosesc adesea parametrii din URI ca intrare pentru a executa comenzile sistemului și interogările bazei de date. Cu toate acestea, datele primite în cerere nu pot fi întotdeauna de încredere. Un atacator poate crea și modifica componente în cerere (cum ar fi metode, câmpuri din antet, corp...), pentru a executa comenzi de sistem, a interoga baza de date...

De exemplu, SQL Injection este un atac comun în care serverul web primește parametri în URI care fac parte din interogarea SQL. Prin urmare, un atacator poate păcăli serverul web pentru a executa interogări SQL ilegale, pentru a fura sau a sabota baza de date.
În general, datele transmise de utilizatori nu trebuie utilizate direct pentru a efectua operațiuni pe server. Aceste date trebuie să treacă prin filtre, care definesc ce este valid și ce este invalid, eliminând astfel datele nedorite.

6. Dezvăluirea informațiilor personale

Clienții conțin adesea o mulțime de informații personale, inclusiv informații furnizate de utilizator pentru a interacționa cu serverul (cum ar fi numele de utilizator, parola, locația, adresa de e-mail etc.) și informații despre activitățile de navigare pe web ale utilizatorului (istoric, marcaje, etc.). La implementare, ar trebui să se acorde atenție prevenirii punctelor care pot dezvălui aceste informații private.

7. Dezvăluirea informațiilor sensibile în URI

URI-urile, prin proiectare, sunt menite să fie partajate cu toți utilizatorii și nu se garantează că sunt sigure. URI-urile sunt adesea afișate în codul sursă al site-ului web și sunt stocate în marcaje fără mecanisme de protecție. Prin urmare, nu va fi sigur dacă URI-ul conține informații sensibile, informații personale etc.

Evitați utilizarea metodei GET pentru a trimite informații personale către server, deoarece acestea vor fi afișate în URI. Folosiți în schimb metoda POST.

8. Dezvăluirea informațiilor software utilizate

Câmpurile User-Agent, Via, Server din antet oferă de obicei informații despre software-ul utilizat de expeditor. În teorie, acest lucru permite atacatorilor să exploateze mai ușor vulnerabilitățile cunoscute din aceste software.