Lepiej późno niż wcale, to chyba najlepsze określenie informacji ogłoszonej przez Microsoft w połowie lutego: HTTP Strict Transport Security został wdrożony w Internet Explorerze i, co naturalne, będziemy mogli z niego korzystać także w przeglądarce Spartan.
HTTP Strict Transport Security
HTTP Strict Transport Security, w skrócie HSTS, to mechanizm pozwalający na wymuszenie na przeglądarce ładowania strony jedynie z wykorzystaniem szyfrowanego protokołu HTTPS. Całość realizowana jest poprzez dodanie odpowiedniej wartości do nagłówka HTTP.
Warunki jakie należy spełnić, aby móc skutecznie wdrożyć HTST dla swojej witryny to:
- zainstalowanie certyfikatu SSL oraz,
- skonfigurowanie strony tak, aby była osiągalna jedynie za pomocą protokołu HTTPS.
Niektórzy z Was mogą w tym momencie pomyśleć: skoro mam zainstalowany certyfikat SSL i pozwalam wejść na moją stronę jedynie za pomocą szyfrowanego protokołu to po co mi HSTS? OK, a co jeżeli użytkownik wpisze, w pasku adresu, adres Twojej strony z przedrostkiem http:// zamiast https://? Zgadza się, serwer przekieruje go natychmiast na https://, ale… mimo, że dzieje się to wszystko praktycznie niezauważalnie dla użytkownika to atakujący może wykorzystać ten moment na przechwycenie żądania i przekierowanie nieświadomego użytkownika na podstawioną stronę.
Właśnie w celu rozwiązania m.in. tego problemu zaprojektowany został mechanizm HSTS realizowany poprzez dołączenie do nagłówka HTTP specjalnej wartości Strict-Transport-Security. Po jego otrzymaniu, przeglądarka będzie komunikowałą się z serwerem jedynie z wykorzystaniem protokołu HTTPS. Wymuszanie szyfrowania połączenia będzie trwało tak długo, jak wskazane zostanie to we wspomnianym nagłówku w polu max-age (wartość ta wyrażana jest w sekundach). Przykładowy nagłówek Strict-Transport-Security może wyglądać tak:
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Dodanie opcjonalnej dyrektywy includeSubDomains pozwoli na zastosowanie mechanizmu HSTS nie tylko dla hosta wysyłającego nagłówek, ale także dla wszystkich jego subdomen.
Dodatkową wartością, jaką niesie za sobą HSTS, jest blokowanie przez przeglądarkę, bez możliwości obejścia blokady, dostępu do strony w przypadku błędu certyfikatu (np. niezgodności nazwy domeny z certyfikatu, z domeną z którą próbujemy nawiązać bezpieczne połączenie). W przypadku braku wsparcia dla HSTS po stronie serwera, użytkownik ma możliwość zignorowania ostrzeżenia i przejścia do potencjalnie niebezpiecznej strony.
Jeszcze jedną korzyścią stosowania HSTS jest brak tolerancji tego mechanizmu dla tzw. mixed content, który, oprócz ostrzeżeń w przeglądarkach, może prowadzić do przełamania zabezpieczeń witryny.
HSTS nie jest niestety wolny od wad. Główna z nich to konieczność zaakceptowania przez przeglądarkę koncepcji TOFU (trust-on-first-use). Oznacza to, że podczas pierwszego przesyłania nagłówka STS przez serwer, przeglądarka musi mu zaufać. Może prowadzić to do sytuacji w której atakujący będzie w stanie zmodyfikować żądanie i na przykład usunąć z niego nagłówek STS, co z kolei może prowadzić do scenariusza opisanego kilka akapitów wcześniej. Rozwiązaniem tego problemu jest dodanie swojej domeny do zaszytej w przeglądarce listy domen. Przeglądarka nie pozwoli wtedy nigdy nawiązać połączenia z Twoją domeną za pomocą nieszyfrowanego protokołu HTTP.
Jak włączyć HSTS na moim serwerze?
Dla serwera Apache w parametrze <VirtualHost> wystarczy dodać linijkę (wymagane jest wcześniejsze włączenie modułu headers):
Header always set Strict-Transport-Security „max-age=10886400; includeSubDomains”
W przypadku serwera nginx sprawę załatwi wpis:
add_header Strict-Transport-Security „max-age=10886400; includeSubDomains”;
w sekcji server.
Trochę więcej pracy wymagane jest do uzyskania poprawnej konfiguracji HSTS na serwerze IIS (konieczna jest instalacja dodatkowego modułu), ale także nie powinno przysporzyć to większych trudności.
Aktualizacja 08.06.2015:
Konfiguracji HSTS na serwerze IIS można dokonać także w prostszy, niż wyżej wymieniony, sposób. Możliwe jest to poprzez rozszerzenie URL Rewrite, a przykładowe reguły, które należy dopisać do pliku web.config, mogą wyglądać tak (źródło: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#URL_Rewrite):
<configuration> <system.webServer> <rewrite> <rules> <rule name="HTTPS_301_Redirect" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="^OFF$" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" redirectType="Permanent" /> </rule> </rules> <outboundRules> <rule name="Add_HSTS_Header" preCondition="USING_HTTPS" patternSyntax="Wildcard"> <match serverVariable="RESPONSE_Strict-Transport-Security" pattern="*" /> <action type="Rewrite" value="max-age=31536000" /> </rule> <preConditions> <preCondition name="USING_HTTPS"> <add input="{HTTPS}" pattern="^ON$" /> </preCondition> </preConditions> </outboundRules> </rewrite> </system.webServer> </configuration>
Zestawiając ogólną łatwość włączenia mechanizmu HSTS i korzyści z niego płynące warto (jeżeli jeszcze tego nie zrobiliście) poświęcić mu chwilę uwagi. Nie należy obawiać się braku wsparcia dla HSTS w przypadku starszych lub niektórych mobilnych wersji przeglądarek. Jeżeli dana przeglądarka nie obsługuje HSTS, po prostu zignoruje ona dodatkowy nagłówek i bez problemu wyświetli zawartość strony.
IE daleko w tyle
Mechanizm HSTS został dodany do Internet Explorera instalowanego w systemie Windows 10 Technical Preview i będzie on obecny także w nowej przeglądarce Microsoftu, Spartanie.
IE zamyka listę najpopularniejszych przeglądarek, które zdecydowały się na wdrożenie HSTS. Wcześniej został on zaimplementowany w:
- Chrome 4.0.211.0 (rok 2010),
- Firefox 4 (2011),
- Safari 7 na OS X 10.9 (2014),
- Opera 12 (2012).
Jeżeli ktoś z Was chciałby poznać więcej szczegółów mechanizmu HTTP Strict Transport Security zachęcam do zapoznania się ze specyfikacją standardu.
W IIS nie potrzeba modułu – wystarczy dodać 2 reguły URL Rewrite:
– pierwsza przekierowuje HTTP na HTTPS,
– druga dodaje nagłówek HSTS do żądań HTTPS
Przykładowy konfig można znaleźć tu:
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#IIS
Zgadza się, dzięki :-) Poprawiłem wpis.