HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) – mechanizm bezpieczeństwa sieci, który chroni strony przed atakami takimi, jak wymuszone zmniejszenie poziomu protokołu oraz przechwytywanie sesji. Dzięki niemu do serwerów można połączyć się tylko za pomocą przeglądarek, korzystających z bezpiecznych połączeń HTTPS[a], natomiast nigdy nie dopuszcza on połączeń na bazie niezabezpieczonego protokołu HTTP. HSTS jest uznawany za standardowy protokół przez IETF; został opisany w dokumencie RFC 6797 ↓.

O stosowaniu polityki HSTS[1] serwer informuje użytkownika za pomocą pola znajdującego się w nagłówku odpowiedzi HTTP o nazwie „Strict-Transport-Security”. Polityka HSTS określa czas, w którym użytkownik może być połączony z serwerem tylko poprzez bezpieczne połączenie[2].

Historia specyfikacji

Specyfikację HSTS opublikowano jako RFC 6797 ↓ w dniu 19 listopada 2012 po tym, jak została zaaprobowana do proponowanego standardu RFC 2 października 2012 przez IESG.[3] Początkowo autorzy wydali ją 17 czerwca 2010. Nazwa specyfikacji została zmieniona ze „Strict Transport Security” (STS) na „HTTP Strict Transport Security”, ponieważ odnosiła się ona tylko do protokołu HTTP[4]. Mimo tego pole nagłówka odzewu (ang. response header field) HTTP sprecyzowane w specyfikacji HSTS pozostaje nazwane „Strict-Transport-Security”.

Ostatnia tzw. „społecznościowa wersja” specyfikacji, nazywanej wtedy „STS”, została opublikowana 18 grudnia 2009, z poprawkami wniesionymi na podstawie opinii użytkowników[5].

Oryginalna specyfikacja, której autorami byli Jeff Hodges[6] z PayPal, Collin Jackson[7] oraz Adam Barth[8] została wydana 18 września 2009.[9]

Specyfikacja HSTS bazuje na oryginalnej pracy Jacksona i Barth’a jak opisano w ich artykule: „ForceHTTPS: Protecting High-Security Web Sites from Network Attacks”[10].

Ponadto HSTS jest realizacją aspektu całościowej wizji poprawy bezpieczeństwa w internecie, którą zaproponowali Jeff Hodges oraz Andy Steingruebl w artykule z 2010 roku „The Need for Coherent Web Security Policy Framework(s)”[11].

Gdy witryna internetowa[12] wymusza użycie polityki HSTS do użytkowników, zgodne aplikacje użytkowników zachowują się w następujący sposób[13]:

  1. Automatycznie zamieniają wszystkie niezabezpieczone odniesienia do witryny na połączenia chronione (np. http://example.pl/jakas/strona/ zmieni się w https://example.pl/jakas/strona/ przed nawiązaniem połączenia).
  2. Jeżeli bezpieczeństwo połączenia nie może zostać zapewnione (np. certyfikat SSL serwera jest niezaufany), pokazany zostanie komunikat o  błędzie i użytkownik nie  będzie w stanie skorzystać z witryny[14].

Polityka HSTS pomaga chronić użytkowników sieci przed niektórymi pasywnymi (nasłuch) i aktywnymi atakami[15]. Przy stosowaniu polityki HSTS dla danej witryny przez przeglądarkę, możliwość przechwytywania zapytań i odpowiedzi pomiędzy witryną a  użytkownikiem w ataku pośrednictwa została drastycznie zmniejszona.

Uwagi

  1. HTTPS oznacza protokół HTTP, wykorzystujący szyfrowanie Transport Layer Security (TLS/SSL). Zabezpieczone w ten sposób połączenia HTTP są określane w standardzie URI jako „https”, natomiast taką „kombinację” często określa się mianem „protokołu HTTPS”.

Przypisy

  1. RFC 6797 ↓, Section 5.2. HSTS Policy.
  2. Piotr Bratkowski: HSTS, czyli HTTP Strict Transport Security. sierpień 2013. [dostęp 2016-05-19].
  3. [websec Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)]. 2 października 2012. [dostęp 2012-10-02].
  4. Jeff Hodges: Re: [HASMAT „STS” moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)]. 30 czerwca 2010. [dostęp 2010-07-22].
  5. Strict Transport Security -06. 18 grudnia 2009. [dostęp 2009-12-23].
  6. Jeff Hodges’s homepage. [dostęp 2011-08-26].
  7. Collin Jackson’s homepage. [dostęp 2011-03-08].
  8. Adam Barth’s homepage. [dostęp 2011-03-08].
  9. Strict Transport Security -05. 18 września 2009. [dostęp 2009-11-19].
  10. ForceHTTPS: Protecting High-Security Web Site from Network Attacks. kwiecień 2008. [dostęp 2009-11-19].
  11. Jeff Hodges, Steinguebl, Andy: The Need for Coherent Web Security Policy Framework(s). 29 października 2010. [dostęp 2012-11-21].
  12. Nations, Daniel. „Web Applications: What is a Web Application?”. About.com. Z 21 listopada 2012.
  13. RFC 6797 ↓, Section 5. HSTS Mechanism Overview.
  14. RFC 6797 ↓, Sekcja 12.1. No User Recourse.
  15. RFC 6797 ↓, Sekcja 2.3. Model Zagrożeń (Threat Model).

Bibliografia

  • J. Hodges, C. Jackson, A. Barth, HTTP Strict Transport Security (HSTS), RFC 6797, IETF, listopad 2012, DOI10.17487/RFC6797, ISSN 2070-1721, OCLC 943595667 (ang.).

Linki zewnętrzne

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.