Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

HTTP Strict Transport Security ( HSTS ) - этомеханизм политики веб-безопасности, который помогает защитить веб-сайты от атак типа « злоумышленник в середине», таких как атаки на более раннюю версию протокола [1] и захват файлов cookie . Он позволяет веб-серверам объявлять, что веб-браузеры (или другие соответствующие пользовательские агенты ) должны автоматически взаимодействовать с ним, используя толькосоединения HTTPS , которые обеспечивают безопасность транспортного уровня (TLS / SSL), в отличие от незащищенного HTTP, используемого отдельно. HSTS - это IETFпротокол отслеживания стандартов и определен в RFC 6797 .

Политика HSTS передается сервером пользовательскому агенту через поле заголовка ответа HTTPS с именем « Strict-Transport-Security ». [1] Политика HSTS определяет период времени, в течение которого пользовательский агент должен осуществлять доступ к серверу только безопасным способом. [2] Веб-сайты, использующие HSTS, часто не принимают открытый текст HTTP, отклоняя соединения по HTTP или систематически перенаправляя пользователей на HTTPS (хотя это не требуется спецификацией). Следствием этого является то, что пользовательский агент, не способный выполнять TLS, не сможет подключиться к сайту.

Защита применяется только после того, как пользователь посетил сайт хотя бы один раз, и способ работы этой защиты заключается в том, что пользователь, вводящий или выбирающий URL-адрес сайта, который указывает HTTP, автоматически обновляется до HTTPS, без выполнения HTTP-запроса, который предотвращает атаку HTTP «человек посередине».

История спецификаций [ править ]

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

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

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

Спецификация HSTS основана на оригинальной работе Джексона и Барта, описанной в их статье «ForceHTTPS: Защита веб-сайтов с высоким уровнем безопасности от сетевых атак». [7]

Кроме того, HSTS - это реализация одного из аспектов общего видения улучшения веб-безопасности, выдвинутого Джеффом Ходжесом и Энди Штейнгрублом в их статье 2010 года «Необходимость согласованных рамок политики веб-безопасности» . [8]

Обзор механизма HSTS [ править ]

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

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

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

Политика HSTS помогает защитить пользователей веб-приложений от некоторых пассивных ( перехват ) и активных сетевых атак . [10] человек-в-середине атакующий имеет значительно сниженную способность к запросам перехвата и ответов между пользователем и сервером веб - приложений , а браузер пользователя имеет HSTS политику в силу для этого веб - приложения.

Применимость [ править ]

Самая важная уязвимость системы безопасности, которую может исправить HSTS, - это атаки типа « злоумышленник в середине» с удалением SSL , впервые публично представленные Мокси Марлинспайком в его выступлении BlackHat Federal в 2009 году «Новые приемы для практической победы над SSL». [11] [12] Атака с удалением SSL (и TLS ) работает путем прозрачного преобразования защищенного HTTPS- соединения в обычное HTTP-соединение. Пользователь может видеть, что соединение небезопасно, но, что очень важно, нет способа узнать, должно ли соединениебыть в безопасности. Во время выступления Марлинспайка многие веб-сайты не использовали TLS / SSL, поэтому не было возможности узнать (без предварительного знания), было ли использование простого HTTP следствием атаки или просто потому, что на веб-сайте не реализован TLS. / SSL. Кроме того, во время перехода на более раннюю версию пользователю не выдается никаких предупреждений, что делает атаку довольно незаметной для всех, кроме самых бдительных. Инструмент sslstrip Marlinspike полностью автоматизирует атаку. [ необходима цитата ]

HSTS решает эту проблему [10] , сообщая браузеру, что соединения с сайтом всегда должны использовать TLS / SSL. Заголовок HSTS может быть удален злоумышленником, если это первое посещение пользователем. Google Chrome , Mozilla Firefox , Internet Explorer и Microsoft Edge пытаются решить эту проблему, добавляя «предварительно загруженный» список сайтов HSTS. [13] [14] [15] К сожалению, это решение не может масштабироваться для включения всех веб-сайтов в Интернете. См. Ограничения ниже.

HSTS также может помочь предотвратить кражу учетных данных для входа на веб-сайт на основе файлов cookie широко доступными инструментами, такими как Firesheep . [16]

Поскольку HSTS ограничен по времени, он чувствителен к атакам, включающим изменение времени компьютера жертвы, например, использование ложных пакетов NTP . [17]

Ограничения [ править ]

Первоначальный запрос остается незащищенным от активных атак, если он использует небезопасный протокол, такой как простой HTTP, или если URI для начального запроса был получен по незащищенному каналу . [18] То же самое относится к первому запросу после периода активности, указанного в объявленной политике HSTS max-age (сайты должны установить период в несколько дней или месяцев в зависимости от активности и поведения пользователя). Google Chrome , Mozilla Firefox и Internet Explorer / Microsoft Edge устраняют это ограничение, реализуя «предварительно загруженный список HSTS», который представляет собой список, содержащий известные сайты, поддерживающие HSTS. [19] [13][14] [15] Этот список распространяется вместе с браузером, поэтому он также использует HTTPS для первоначального запроса к перечисленным сайтам. Как упоминалось ранее, эти предварительно загруженные списки не могут масштабироваться для покрытия всей сети. Потенциальное решение может быть достигнуто путем использованиязаписей DNS для объявления политики HSTS и безопасного доступа к ним через DNSSEC , необязательно с помощью отпечатков сертификатов для обеспечения действительности (что требует запуска проверяющего преобразователя, чтобы избежатьпроблем последней мили ). [20]

Джунаде Али отметил, что HSTS неэффективен против использования фальшивых доменов; используя DNS-атаки, перехватчик Man-in-the-Middle может обслуживать трафик из искусственного домена, которого нет в списке предварительной загрузки HSTS, [21] это может быть сделано с помощью DNS Spoofing Attacks, [ 22] или просто доменное имя, которое обманчиво напоминает настоящее доменное имя, например www.example.org вместо www.example.com .

Даже с «предварительно загруженным списком HSTS» HSTS не может предотвратить расширенные атаки против самого TLS, такие как атаки BEAST или CRIME, представленные Джулиано Риццо и Тай Дуонг. Атаки на сам TLS ортогональны применению политики HSTS. Он также не может защитить от атак на сервер - если кто-то его скомпрометирует, он с радостью будет обслуживать любой контент через TLS. [ необходима цитата ]

См. RFC  6797 для обсуждения общих соображений безопасности HSTS.

Проблемы с конфиденциальностью [ править ]

HSTS можно использовать для почти несмываемой пометки посещающих браузеров восстанавливаемыми идентификационными данными ( супер-куки ), которые могут сохраняться в режимах конфиденциальности браузера « инкогнито » и вне их . Создавая веб-страницу, которая выполняет несколько HTTP-запросов к выбранным доменам, например, если используется двадцать запросов браузера к двадцати различным доменам, теоретически можно выделить более одного миллиона посетителей (2 20 ) из-за результирующих запросов, поступающих через HTTP vs. HTTPS; последние представляют собой ранее записанные двоичные «биты», установленные ранее через заголовки HSTS. [23]

Поддержка браузера [ править ]

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

Рекомендации по развертыванию [ править ]

В зависимости от фактического развертывания существуют определенные угрозы (например, атаки путем внедрения файлов cookie), которых можно избежать, следуя передовым методикам.

  • Узлы HSTS должны декларировать политику HSTS в своем доменном имени верхнего уровня. Например, хост HSTS на https://sub.example.com также должен ответить заголовком HSTS на https://example.com. В заголовке должна быть указана includeSubDomainsдиректива. [31]
  • В дополнение к развертыванию HSTS хост для https://www.example.com должен включать запрос к ресурсу с https://example.com, чтобы убедиться, что HSTS для родительского домена установлен и защищает пользователя от потенциальных Атаки с внедрением файлов cookie, выполняемые MITM, который вводит ссылку на родительский домен (или даже http://nonexistentpeer.example.com), на которую злоумышленник затем отвечает. [32]

См. Также [ править ]

  • Политика безопасности контента
  • Закрепление открытого ключа HTTP
  • HTTPsec

Ссылки [ править ]

  1. ^ a b c d "Строгая транспортная безопасность" . Веб-документы MDN . Mozilla . Проверено 31 января 2018 года .
  2. ^ Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). «Политика HSTS» . Строгая безопасность транспорта HTTP (HSTS) . IETF . DOI : 10,17487 / RFC6797 . RFC 6797 . Проверено 31 января 2018 года .
  3. ^ "[websec] Действие протокола: 'HTTP Strict Transport Security (HSTS)' до Предлагаемого стандарта (draft-ietf-websec-strict-transport-sec-14.txt)» . 2 октября 2012 . Проверено 2 октября 2012 года .
  4. ↑ Джефф Ходжес (30 июня 2010 г.). «Re: [HASMAT]« STS ​​», прозвище (было: IETF BoF @ IETF-78 Maastricht: HASMAT ...)» . Проверено 22 июля 2010 года .
  5. ^ "Строгая транспортная безопасность-06" . 18 декабря 2009 . Проверено 23 декабря 2009 года .
  6. ^ "Строгая транспортная безопасность-05" . 18 сентября 2009 . Проверено 19 ноября 2009 года .
  7. ^ «ForceHTTPS: Защита веб-сайта с высоким уровнем безопасности от сетевых атак» . Апрель 2008 . Проверено 19 ноября 2009 года .
  8. ^ Ходжес, Джефф; Steinguebl, Энди (29 октября 2010 г.). «Необходимость в согласованной структуре политики веб-безопасности» . Проверено 21 ноября 2012 года .
  9. ^ Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). «Раздел 5. Обзор механизма HSTS» . RFC 6797 . IETF . Проверено 21 ноября 2012 года .
  10. ^ a b Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). «2.3. Модель угрозы» . RFC 6797 . IETF . Проверено 21 ноября 2012 года .
  11. ^ «Новые приемы для победы над SSL на практике» (PDF) . Cite journal requires |journal= (help)
  12. ^ Защита от SSL с помощью Sslstrip на YouTube
  13. ^ Б Адам Лэнгли (8 июля 2010). «Строгая транспортная безопасность» . Проекты Chromium . Проверено 22 июля 2010 года .
  14. ^ a b c Дэвид Киллер (1 ноября 2012 г.). «Предварительная загрузка HSTS» . Блог по безопасности Mozilla . Проверено 6 февраля 2014 года .
  15. ^ a b Белл, Майк; Уолп, Дэвид (16 февраля 2015 г.). «HTTP Strict Transport Security приходит в Internet Explorer» . Проверено 16 февраля 2015 года .
  16. ↑ Джефф Ходжес (31 октября 2010 г.). «Firesheep и HSTS (строгая безопасность транспорта HTTP)» . Проверено 8 марта 2011 года .
  17. ↑ Хосе Селви (17 октября 2014 г.). «Обход строгой транспортной безопасности HTTP» (PDF) . Проверено 22 октября 2014 года .
  18. ^ Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). «Раздел 14.6. Уязвимость Bootstrap MITM» . RFC 6797 . IETF . Проверено 21 ноября 2012 года .
  19. ^ "Предварительно загруженный список Chromium HSTS" . cs.chromium.org . Проверено 10 июля 2019 .
  20. ↑ Мясник, Саймон (11 сентября 2011 г.). «Строгая безопасность транспорта HTTP» . Проверено 27 марта 2012 года .
  21. ↑ Али, Джунаде (20 октября 2017 г.). «Выполнение и предотвращение удаления SSL: простой английский учебник» . Блог Cloudflare .
  22. ^ Максутов, АА; Черепанов И.А.; Алексеев, М.С. (2017). 2017 Сибирский симпозиум по науке о данных и инженерии (SSDSE) . С. 84–87. DOI : 10.1109 / SSDSE.2017.8071970 . ISBN 978-1-5386-1593-5. S2CID  44866769 .
  23. ^ «Супер cookie HSTS заставляет вас выбирать:« конфиденциальность или безопасность? »-» . sophos.com . Проверено 1 декабря 2015 года .
  24. ^ Хром Разработчики (17 ноября 2010). «Строгая транспортная безопасность - проекты Chromium» . Проверено 17 ноября 2010 года .
  25. ↑ Джефф Ходжес (18 сентября 2009 г.). "fyi: строгая спецификация транспортной безопасности" . Проверено 19 ноября 2009 года .
  26. ^ Opera Software ASA (23 апреля 2012 г.). «Поддержка веб-спецификаций в Opera Presto 2.10» . Проверено 8 мая 2012 года .
  27. ^ @agl__ ( Адам Лэнгли ). «Подтверждено. См. ~ / Library / Cookies / HSTS.plist. Включает предварительные загрузки Chromium на определенную дату и обрабатывает заголовки HSTS» . в Твиттере . Проверено 20 декабря 2013 года .
  28. ^ «HTTP Strict Transport Security входит в Internet Explorer 11 в Windows 8.1 и Windows 7» . windows.com . Дата обращения 12 июня 2015 .
  29. ^ «Состояние веб-платформы Internet Explorer и план действий» . Проверено 14 апреля 2014 года .
  30. ^ «Project Spartan и предварительная сборка Windows 10 за январь - IEBlog» . Проверено 23 января 2015 года .
  31. ^ Ходжес; и другие. «Строгая транспортная безопасность HTTP (HSTS) 6.1.2» . ietf.org . Проверено 11 ноября +2016 .
  32. ^ «RFC 6797 - HTTP Strict Transport Security (HSTS)» . Инструменты IETF . Архивировано 28 мая 2019 года . Проверено 28 мая 2019 .

Внешние ссылки [ править ]

  • Состояние развертывания HSTS: обзор и распространенные ловушки содержит анализ статистики развертывания HSTS, шаблонов, ошибок и передовых методов.
  • RFC  6797 - строгая безопасность транспорта HTTP (HSTS)
  • Рабочая группа IETF WebSec
  • Security Now 262: строгая транспортная безопасность
  • Открытый проект безопасности веб-приложений (OWASP): описание HSTS
  • Тестирование HSTS онлайн-браузера и закрепления открытого ключа
  • Онлайн-тест HSTS для веб-серверов
  • Отправка предварительной загрузки HSTS для Google Chrome, Mozilla Firefox, Safari, IE 11 и Edge
  • Предварительно загруженный список Chromium HSTS
  • Строгая безопасность транспорта в веб-документах MDN