HSTS

Спецификация HSTS была одобрена как предлагаемый стандарт IETF 2 октября 2012 года и официально опубликована 19 ноября 2012 года как RFC 6797^[2]. Авторы впервые представили спецификацию как черновик 17 июня 2010 года. После преобразования в черновик название было изменено с «Strict Transport Security» («STS») на «HTTP Strict Transport Security», чтобы подчеркнуть её применимость только к HTTP^[3]. Однако наименование заголовка ответа осталось как «Strict-Transport-Security».

«Общедоступная версия» спецификации, пересмотренная с учётом обратной связи сообщества, была опубликована 18 декабря 2009 года под именем «STS»^[4].

Оригинальный черновик спецификации, подготовленный Джеффом Ходжесом из PayPal, Коллином Джексоном и Адамом Бартом, был опубликован 18 сентября 2009 года^[5].

Спецификация HSTS основана на работах Джексона и Барта, изложенных в статье «ForceHTTPS: Protecting High-Security Web Sites from Network Attacks» («Защита веб-сайтов высокой безопасности от сетевых атак»)^[6].

Кроме того, HSTS стал шагом на пути реализации общей концепции повышения веб-безопасности, изложенной Джеффом Ходжесом и Энди Стейнгрюбелем в статье 2010 года «The Need for Coherent Web Security Policy Framework(s)»^[7].

Сервер реализует политику HSTS, отправляя заголовок ответа только по HTTPS (заголовки HSTS, полученные по HTTP, игнорируются)^[1]. Например, сервер может отправить следующий заголовок, чтобы браузеры использовали только HTTPS для домена в течение года (max-age указывается в секундах: 31 536 000 секунд = 365 дней): Strict-Transport-Security: max-age=31536000.

Когда веб-приложение оповещает пользовательские агенты о включении HSTS, совместимые браузеры ведут себя следующим образом (согласно RFC 6797)^[8]:

1. Необеспеченные соединения с сайтом должны автоматически перенаправляться на защищённые (например, http://example.com/some/page/ меняется на https://example.com/some/page/ до запроса к серверу).
2. Если установить защищённое соединение не удаётся (например, TLS-сертификат сервера ненадёжный), браузер должен разорвать соединение и не предоставлять пользователю возможность проигнорировать это.

Политика HSTS помогает защитить пользователей веб-приложений от ряда пассивных (прослушивание) и активных сетевых атак^[9]. Если в браузере для определённого сайта действует политика HSTS, злоумышленник, применяющий атаку «человек посередине» (MITM), теряет возможность эффективно перехватывать трафик.

Одним из наиболее опасных уязвимостей, которые позволяет устранить HSTS, является атака SSL Stripping, впервые представленная Мокси Марлинспайком в 2009 году на конференции BlackHat Federal («New Tricks For Defeating SSL In Practice»)^[10]. Атака SSL/TLS Stripping заключается в прозрачном преобразовании защищённой (HTTPS) связи в незашифрованную (HTTP), при этом пользователь может не заметить проблему, а определить, должен ли сайт использовать защищённое соединение, зачастую невозможно. Поскольку многие сайты вовсе не поддерживают TLS/SSL, зачастую невозможно отличить результат атаки от обычной работы сайта. Дополнительно, при атаке пользователю не показывается никаких предупреждений, что делает атаку эффективной практически против всех пользователей.

HSTS устраняет эту проблему^[9] путём указания браузеру всегда использовать TLS/SSL для соединения с сайтом. Однако, если это первый визит пользователя, злоумышленник всё ещё может удалить HSTS-заголовок. Для смягчения этой проблемы в Google Chrome, Mozilla Firefox, Internet Explorer и Microsoft Edge используется «предзагруженный список», содержащий сайты с поддержкой HSTS^[11][12][13]. Однако этот подход не масштабируется для покрытия всех сайтов в Интернете.

HSTS также может предотвращать атаки с похищением cookie, осуществляемые с помощью таких инструментов, как Firesheep^[14].

Так как действие HSTS ограничено во времени, оно уязвимо для атак с изменением времени на компьютере жертвы, например, с помощью поддельных пакетов NTP^[15].

Если первый запрос к сайту осуществляется по незащищённому HTTP или через небезопасный URI, то он не защищён от атак активного злоумышленника^[16]. То же верно для первого запроса после истечения срока действия политики HSTS, определённого в max-age (его стоит подбирать исходя из специфики сайта). Для борьбы с этим основными браузерами (Google Chrome, Mozilla Firefox, Internet Explorer/Microsoft Edge) используется «список предзагрузки HSTS» — он распространяется в составе браузера и включает сайты, поддерживающие HSTS^{[11][12][13][17]}. Однако этот механизм неспособен покрыть весь Интернет. Одно из возможных решений — распространение политики HSTS через DNS (например, с использованием DNSSEC для аутентификации записей)^[18].

Джунаде Али указал, что HSTS бессилен против «фальшивых» доменных имён: используя атаки на DNS, злоумышленник может предоставить трафик с недействительного домена, не попавшего в предзагруженный список HSTS^[19], что возможно как с помощью DNS спуфинга^[20], так и через регистрацию домена, схожего с настоящим (например, «www.example.com» вместо «www.example.org»).

Даже наличие «предзагруженного списка HSTS» не позволяет защититься от сложных атак на TLS, таких как BEAST и CRIME^[21], а также от атак на сам сервер: если злоумышленник получит доступ к серверу, он сможет отдавать вредоносный контент через TLS.

Детализированный разбор аспектов безопасности HSTS приведён в RFC 6797.

HSTS может использоваться для метки браузеров, в том числе и в «приватном» режиме, путём хранения так называемых «суперкуки». Осуществляя обращения к нескольким заранее заданным доменам, сайт может установить идентификаторы, позволяющие определить до миллиона разных пользователей (2²⁰)^[22].

• Chromium и Google Chrome начиная с версии 4.0.211.0^[23][24]
• Firefox начиная с версии 4^[1]; Mozilla реализовала предзагрузку HSTS с версии Firefox 17^[12]
• Opera начиная с версии 12^[25]
• Safari на OS X Mavericks (версия 10.9, конец 2013 года)
• Internet Explorer 11 на Windows 8.1 и Windows 7 (после установки KB 3058515 в обновлении Windows в июне 2015 года)^[26]
• Microsoft Edge и Internet Explorer 11 на Windows 10^[27][28]
• BlackBerry 10 (BlackBerry OS 10.3.3 и новее) и встроенный WebView, для которых реализована интеграция списков поддерживаемых HSTS-сайтов.

В зависимости от применяемой конфигурации при внедрении HSTS необходимо учитывать ряд вопросов (например, защищённость от атак внедрения cookie):

• HSTS следует объявлять для корневого домена (например, для https://example.com вместе с includeSubDomains), чтобы политика распространялась и на поддомены, например https://sub.example.com. Пример заголовка: Strict-Transport-Security: max-age=16070400; includeSubDomains^[29].
• Для предотвращения атак с инъекцией cookie через поддомен, сервер https://www.example.com должен также обеспечивать установку HSTS для https://example.com и, например, при обработке запросов с поддоменов делать дополнительный запрос к ресурсу корневого домена^[30].