Securitate de transport strict HTTP

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

HTTP Strict Transport Security sau HSTS (în italiană securitate rigidă pentru transportul HTTP ) este o procedură care implementează o politică de securitate pentru comunicațiile web , necesară pentru a proteja canalul HTTPS de atacuri de degradare a securității ( downgrade ) și foarte utilă pentru protecția împotriva deturnării sesiunii . HSTS permite serverului web să declare că browserele și orice alt tip de client trebuie să comunice cu acesta exclusiv prin conexiuni sigure prin protocol HTTPS și nu prin HTTP simplu [1] . Procedura este un standard de Internet IETF , reglementat de RFC 6797.

Politica HSTS [2] este indicată de server agentului utilizator prin specificarea unui anumit antet în mesajele de răspuns HTTP , numit „ Strict-Transport-Security ” care specifică perioada de timp în care clientul trebuie să acceseze serverul într-un mod neapărat sigur.

Istoricul caietului de sarcini

HSTS este întruchiparea unui aspect al viziunii de design a lui Jeff Hodges și Andy Steingruebl pentru îmbunătățirea securității web și prezentat în 2010 în articolul lor din 2010 intitulat The Need for Coherent Web Security Policy Framework (s) . [3]

Specificația HSTS se bazează pe contribuția inițială a lui Jackson și Barth descrisă în articolul ForceHTTPS: Protejarea site-urilor web de înaltă securitate împotriva atacurilor de rețea . [4]

Primul proiect original al caietului de sarcini a fost scris de PayPal, Jeff Hodges [5] , Collin Jackson[6] și Adam Barth [7] și publicat la 18 septembrie 2009. [8]

Prima specificație a HSTS a fost făcută publică la 18 decembrie 2009 și a corespuns celei mai recente așa-numite „versiuni comunitare”, care a beneficiat de feedback public. [9]

După aprobarea de către IESG pe 2 octombrie 2012, specificația HSTS a fost publicată ca standard propus de RFC pe 19 noiembrie 2012 în RFC 6797 [10] . Cu toate acestea, prima versiune originală a documentului a fost deja depusă la 17 iunie 2010 ca Internet-Draft , moment în care titlul caietului de sarcini a fost schimbat de la „Strict Transport Security” (STS) la mai precis „HTTP Strict Transport Securitate". [11] Cu toate acestea, antetul HTTP definit de specificație a păstrat numele de „Strict-Transport-Security”.

Prezentare generală a procedurii

Un server implementează politica HSTS dacă își emite antetul într-un mesaj de comunicare HTTPS (prin HTTP aceste antete sunt ignorate în schimb). [12] De exemplu, un server ar putea trimite un antet solicitând ca fiecare cerere adresată acestuia în anul următor să fie transmisă în mod necesar prin HTTPS. În acest caz, deoarece parametrul vârstei maxime este exprimat în secunde și 31.536.000 secunde reprezintă o bună aproximare a unui an, antetul ar fi:

Strict-Transport-Security: max-age=31536000; includeSubDomains; .

Atunci când o aplicație web [13] declară agenților utilizator o politică HSTS, clienții care acceptă mecanismul se comportă așa cum este descris mai jos. [2]

  1. Fiecare legătură nesigură este transformată într-o legătură sigură, adică, de exemplu, http://example.com/some/page/ se schimbă în https://example.com/some/page/ înainte ca resursa să fie utilizată.
  2. Dacă securitatea conexiunii nu este considerată fiabilă, de exemplu dacă certificatul TLS nu este fiabil, un mesaj de eroare este afișat utilizatorului și accesul la aplicația web este împiedicat. [2]

Politica HSTS ajută la protejarea utilizatorilor aplicațiilor web de anumite atacuri pasive ( ascultare ) sau active: [14] într-un atac om-în-mijloc este mult mai dificil să intercepți întrebări și răspunsuri între utilizator și web-ul aplicației atunci când prima este în modul HSTS comparativ cu cea din urmă.

Aplicabilitate

Cea mai importantă vulnerabilitate de securitate care poate fi evitată de HSTS este așa - numitul om-în-mijloc cu tehnica SSL-stripping , ilustrată public pentru prima dată în 2009 de Moxie Marlinspike în discursul său „ New Tricks For Defeating SSL În practică » (Punerea în practică a unor noi trucuri pentru a învinge SSL) prezentate la BlackHat Federal . [15] [16] Acest atac constă în transformarea silențioasă a unei conexiuni HTTP sigure, acceptate de SSL sau TLS , într-o conexiune HTTP clară: utilizatorul poate verifica dacă conexiunea nu este într-adevăr sigură, dar nu are cum să știe că ar trebui să fie. Având în vedere că mai multe site-uri nu folosesc TLS / SSL, de fapt, nu există nicio modalitate de a înțelege, dacă nu se cunoaște a priori site-ul specific, dacă nesiguranța conexiunii este efectul unui atac sau dacă este comportamentul obișnuit aplicație web. Mai mult, procesul de regresie de securitate nu generează mesaje de avertizare către utilizator, făcând atacul discret în ochii aproape oricui. Instrumentul sslstrip al lui Marlinspike automatizează pe deplin un astfel de atac.

HSTS tratează această problemă [14] informând browserul că conexiunile sale la site ar trebui să utilizeze întotdeauna TLS / SSL. Cu toate acestea, deoarece antetul HSTS poate fi încă manipulat de un atacator la prima vizită a unui utilizator, Google Chrome , Mozilla Firefox , Internet Explorer și Microsoft Edge încearcă să limiteze problema prin inserarea unei liste preliminare a site-urilor HSTS. [17] [18] [19] În următorul paragraf Limite vom discuta și despre modul în care această soluție este neapărat insuficientă, dat fiind că lista de mai sus nu poate fi exhaustivă.

HSTS ajută, de asemenea, la prevenirea furtului de acreditări de conectare la site-urile web bazate pe cookie HTTP , un atac viabil cu instrumente disponibile, precum Firesheep . [20]

Deoarece HSTS are limite de timp, protocolul este sensibil la atacurile care implică deplasarea ceasului victimei, de exemplu prin trimiterea de pachete NTP false. [21]

Limite

În fața atacurilor active, prezența HSTS nu este capabilă să protejeze prima cerere către o aplicație web, atunci când aceasta este transmisă pe un protocol nesigur, cum ar fi HTTP în format clar sau când URI-ul relativ a fost obținut pe un canal nesigur . [22] Același lucru se aplică primei cereri care se face după expirarea perioadei specificate de parametrul de max-age anunțat în politica HSTS. Prin urmare, site-urile ar trebui să stabilească o durată de câteva zile sau câteva luni, în funcție de activitatea și comportamentul utilizatorilor. Browserele Google Chrome , Mozilla Firefox și Internet Explorer / Microsoft Edge abordează această limitare a protocolului implementând o „listă preliminară STS”: o listă de site-uri cunoscute care acceptă HSTS [17] [18] [19] care este distribuită direct în interiorul browser și care îl determină să utilizeze HTTPS și pentru prima solicitare. Cu toate acestea, așa cum am menționat anterior, această listă nu poate enumera fiecare site web de pe Internet. O posibilă soluție ar putea fi obținută utilizând înregistrări DNS pentru a declara politica HSTS și accesând aceste informații cu protocolul DNSSEC , eventual folosind amprente digitale ale certificatului pentru a le asigura validitatea, ceea ce, la rândul său, necesită un client de rezoluție DNS pentru a verifica acest lucru. ultima milă de conexiune . [23]

Chiar și atunci când este furnizat cu „lista preliminară STS”, mecanismul HSTS nu este în niciun caz capabil să protejeze împotriva atacurilor care implică același nivel de securitate TLS, cum ar fi BEAST sau CRIME proiectate de Juliano Rizzo și Thai Duong: întreținerea politica HSTS este irelevantă și irelevantă în fața acestui tip de atac.

Pentru o discuție mai amplă despre securitatea HSTS, consultați RFC 6797 . [24]

Suport pentru browser

Pagina de setări pentru HTTPS Strict Transport Security în Chromium 45, care arată starea politicii de securitate pentru domeniul Wikipedia engleză.
Pagina de setări pentru HTTPS Strict Transport Security în Chromium 45, care arată starea politicii de securitate pentru domeniul Wikipedia engleză.

Reguli bune de implementare

În funcție de implementarea specifică, anumite bune practici vă permit să evitați anumite amenințări la adresa securității, cum ar fi atacurile de injectare a cookie-urilor.

  • Gazdele HSTS ar trebui să declare politica HSTS în numele lor de nivel superior - de exemplu, un server care ascultă pe https://sub.example.com ar trebui să răspundă cu antetul HSTS chiar și pentru solicitările către https://example.com.
  • O gazdă care servește https://www.example.com ar trebui să adauge o cerere la o resursă https://example.com, astfel încât HSTS să fie setat și pentru domeniul părinte. În acest fel, utilizatorul este protejat de orice injecție de cookie efectuată de un om în mijloc care ar putea injecta o referință la domeniul superior sau altul de același nivel (cum ar fi http://nonexistentpeer.example.com) unde ar răspunde.

Notă

  1. ^ HTTPS denotă HTTP peste stratul TLS / SSL .
  2. ^ a b c Hodges, Jeff; Jackson, Collin; Barth, Adam (noiembrie 2012).
  3. ^ Hodges, Jeff; Steinguebl, Andy (29 octombrie 2010).
  4. ^ "ForceHTTPS: Protejarea site-ului web de înaltă securitate împotriva atacurilor de rețea" , la crypto.stanford.edu .
  5. ^ „Pagina principală a lui Jeff Hodges” , la Kingsmountain.com .
  6. ^ „Pagina principală a lui Collin Jackson” , pe collinjackson.com .
  7. ^ „Pagina principală a lui Adam Barth” , pe adambarth.com .
  8. ^ "Strict Transport Security -05 " , pe lists.w3.org , 18 septembrie 2009.
  9. ^ "Strict Transport Security -06" , pe lists.w3.org , 18 decembrie 2009.
  10. ^ "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)" , pe ietf.org , 2 octombrie 2012.
  11. ^ Jeff Hodges (30 iunie 2010).
  12. ^ "HTTP Strict Transport Security" , la developer.mozilla.org .
  13. ^ Daniel Națiuni
  14. ^ a b Jeff Hodges, Collin Jackson și Adam Barth, 2.3. Threat Model , RFC 6797 , IETF, noiembrie 2012. Adus pe 21 noiembrie 2012 .
  15. ^ Trucuri noi pentru înfrângerea SSL în practică ( PDF ).
  16. ^ Înfrângerea SSL folosind Sslstrip , pe YouTube .
  17. ^ a b Adam Langley, Strict Transport Security , The Chromium Projects , 8 iulie 2010. Accesat la 22 iulie 2010 .
  18. ^ a b c David Keeler (1 noiembrie 2012).
  19. ^ a b Mike Bell și David Walp, HTTP Strict Transport Security vine pe Internet Explorer , la blogs.msdn.com , 16 februarie 2015. Adus 16 februarie 2015 .
  20. ^ Jeff Hodges, Firesheep și HSTS (HTTP Strict Transport Security) , pe identitymeme.org , 31 octombrie 2010. Accesat la 8 martie 2011 .
  21. ^ Jose Selvi, Bypassing HTTP Strict Transport Security ( PDF ), pe blackhat.com , 17 octombrie 2014. Adus 22 octombrie 2014 .
  22. ^ Jeff Hodges, Collin Jackson și Adam Barth, secțiunea 14.6. Vulnerabilitate Bootstrap MITM , pe RFC 6797 , IETF, noiembrie 2012. Adus pe 21 noiembrie 2012 .
  23. ^ Simon Butcher (11 septembrie 2011).
  24. ^ Jeff Hodges, Collin Jackson și Adam Barth, Secțiunea 14. Considerații de securitate , RFC 6797 , IETF, noiembrie 2012. Accesat la 21 noiembrie 2012 .
  25. ^ The Chromium Developers, Strict Transport Security - The Chromium Projects , la dev.chromium.org , 17 noiembrie 2010. Accesat la 17 noiembrie 2010 .
  26. ^ Jeff Hodges (18 septembrie 2009). „fyi: specificație strictă de securitate a transportului” , pe lists.w3.org .
  27. ^ „HTTP Strict Transport Security” , la blog.mozilla.org .
  28. ^ Opera Software ASA, suport pentru specificații web în Opera Presto 2.10 , pe opera.com , 23 aprilie 2012. URL accesat la 8 mai 2012 (arhivat din original la 4 mai 2012) .
  29. ^ @agl__ (Adam Langley).
  30. ^ HTTP Strict Transport Security vine pe Internet Explorer 11 pe Windows 8.1 și Windows 7 , pe windows.com . Adus pe 12 iunie 2015 .
  31. ^ Starea și foaia de parcurs a platformei web Internet Explorer , la status.modern.ie . Adus 14/04/2014 .
  32. ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog" , la blogs.msdn.com .

Elemente conexe

linkuri externe

Adus de la „ https://it.wikipedia.org/w/index.php?title=HTTP_Strict_Transport_Security&oldid=116474988 ”