stringtranslate.com

Строгая безопасность транспорта HTTP

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

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

Защита применяется только после того, как пользователь посетил сайт хотя бы один раз, полагаясь на принцип "". Принцип работы этой защиты заключается в том, что когда пользователь вводит или выбирает HTTP (не HTTPS) URL-адрес сайта, клиент, такой как веб-браузер, автоматически обновляется до HTTPS без отправки HTTP-запроса, тем самым предотвращая любую HTTP-атаку типа "man-in-the-middle".

История спецификаций

Спецификация HSTS была опубликована как RFC 6797 19 ноября 2012 года после одобрения IESG 2 октября 2012 года для публикации в качестве предлагаемого стандарта RFC . [3] Первоначально авторы представили его как интернет-проект 17 июня 2010 года. После преобразования в интернет-проект название спецификации было изменено с «Strict Transport Security» (STS) на «HTTP Strict Transport Security», поскольку спецификация применяется только к 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] Злоумышленник , использующий метод «man-in-the-middle», имеет значительно меньшие возможности перехвата запросов и ответов между пользователем и сервером веб-приложений, пока в браузере пользователя действует политика HSTS для этого веб-приложения.

Применимость

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

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, злоумышленник может перехватывать трафик с искусственного домена, которого нет в списке предварительной загрузки HSTS [21], это может быть сделано с помощью атак с подменой DNS [22] или просто доменного имени, которое обманчиво напоминает настоящее доменное имя, например www.example.org вместо www.example.com .

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

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

Вопросы конфиденциальности

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

Поддержка браузера

Страница настроек «Безопасность» в Chromium 45, отображающая статус политики безопасности для домена «en.wikipedia.org».
Страница настроек HTTPS Strict Transport Security в Chromium 45, отображающая статус политики безопасности для домена «en.wikipedia.org».

Лучшие практики развертывания

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

Смотрите также

Ссылки

Внешние ссылки

  1. ^ abc "Strict-Transport-Security". MDN Web Docs . Mozilla . Архивировано из оригинала 20 марта 2020 г. Получено 31 января 2018 г.
  2. ^ Ходжес, Джефф; Джексон, Колин; Барт, Адам (ноябрь 2012 г.). «Политика HSTS». HTTP Strict Transport Security (HSTS). IETF . раздел 5.2. doi : 10.17487/RFC6797 . RFC 6797.
  3. ^ "[websec] Действие протокола: 'HTTP Strict Transport Security (HSTS)' для предлагаемого стандарта (draft-ietf-websec-strict-transport-sec-14.txt)". 2 октября 2012 г. Архивировано из оригинала 29 января 2017 г. Получено 2 октября 2012 г.
  4. ↑ Ходжес, Джефф (30 июня 2010 г.). "Re: [HASMAT] "STS" moniker (было: IETF BoF @IETF-78 Maastricht: HASMAT...)". Архивировано из оригинала 2 февраля 2017 г. Получено 22 июля 2010 г.
  5. ^ "Строгая транспортная безопасность -06". 18 декабря 2009 г. Архивировано из оригинала 21 февраля 2017 г. Получено 23 декабря 2009 г.
  6. ^ "Строгая транспортная безопасность -05". 18 сентября 2009 г. Архивировано из оригинала 24 февраля 2020 г. Получено 19 ноября 2009 г.
  7. ^ "ForceHTTPS: Защита веб-сайта с высокой степенью безопасности от сетевых атак". Апрель 2008 г. Архивировано из оригинала 28 февраля 2020 г. Получено 19 ноября 2009 г.
  8. ^ Ходжес, Джефф; Стайнгуэбл, Энди (29 октября 2010 г.). «Необходимость согласованной структуры политики веб-безопасности». Архивировано из оригинала 14 августа 2017 г. Получено 21 ноября 2012 г.
  9. ^ Ходжес, Джефф; Джексон, Колин; Барт, Адам (ноябрь 2012 г.). Раздел 5. Обзор механизма HSTS. IETF. раздел 5. doi : 10.17487/RFC6797 . RFC 6797.
  10. ^ ab Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). 2.4. Модель угроз. IETF. раздел 2.3. doi : 10.17487/RFC6797 . RFC 6797.
  11. ^ Marlinspike, Moxie (2009). Новые приемы для победы над SSL на практике (PDF) . Black Hat Briefings . Вашингтон, округ Колумбия. Архивировано (PDF) из оригинала 30 декабря 2014 года . Получено 15 марта 2012 года .
  12. ^ Обход SSL с помощью Sslstrip на YouTube
  13. ^ ab Langley, Adam (8 июля 2010 г.). «Строгая транспортная безопасность». Проекты Chromium . Архивировано из оригинала 1 сентября 2019 г. Получено 22 июля 2010 г.
  14. ^ abc Keeler, David (1 ноября 2012 г.). "Предварительная загрузка HSTS". Mozilla Security Blog . Архивировано из оригинала 24 февраля 2020 г. Получено 6 февраля 2014 г.
  15. ^ ab Bell, Mike; Walp, David (16 февраля 2015 г.). "HTTP Strict Transport Security приходит в Internet Explorer". Архивировано из оригинала 15 ноября 2015 г. Получено 16 февраля 2015 г.
  16. ^ Ходжес, Джефф (31 октября 2010 г.). «Firesheep и HSTS (HTTP Strict Transport Security)». Архивировано из оригинала 23 июня 2016 г. Получено 8 марта 2011 г.
  17. ^ Selvi, Jose (17 октября 2014 г.). Обход HTTP Strict Transport Security (PDF) . Black Hat Briefings . Амстердам. Архивировано (PDF) из оригинала 22 октября 2014 г. . Получено 22 октября 2014 г. .
  18. ^ Ходжес, Джефф; Джексон, Колин; Барт, Адам (ноябрь 2012 г.). Раздел 14.6. Уязвимость Bootstrap MITM. IETF. раздел 14.6. doi : 10.17487/RFC6797 . RFC 6797.
  19. ^ "Chromium HSTS Preloaded list". cs.chromium.org . Архивировано из оригинала 18 февраля 2020 г. . Получено 10 июля 2019 г. .
  20. ↑ Butcher, Simon (11 сентября 2011 г.). «HTTP Strict Transport Security». Архивировано из оригинала 26 апреля 2019 г. Получено 27 марта 2012 г.
  21. ^ Али, Джунад (20 октября 2017 г.). «Выполнение и предотвращение удаления SSL: простой английский учебник». Блог Cloudflare . Архивировано из оригинала 14 декабря 2019 г. Получено 7 декабря 2017 г.
  22. ^ Максутов, АА; Черепанов, ИА; Алексеев, М.С. (2017). Обнаружение и предотвращение атак DNS-спуфинга . 2017 Сибирский симпозиум по науке о данных и инженерии (SSDSE). С. 84–87. doi :10.1109/SSDSE.2017.8071970. ISBN 978-1-5386-1593-5. S2CID  44866769.
  23. ^ «HSTS super cookie заставляет вас выбирать: «конфиденциальность или безопасность?» -». sophos.com . 2 февраля 2015 г. Архивировано из оригинала 11 февраля 2020 г. Получено 1 декабря 2015 г.
  24. ↑ The Chromium Developers (17 ноября 2010 г.). «Строгая безопасность на транспорте — проекты Chromium». Архивировано из оригинала 20 марта 2020 г. Получено 17 ноября 2010 г.
  25. ^ Ходжес, Джефф (18 сентября 2009 г.). "fyi: Strict Transport Security specification". Архивировано из оригинала 29 февраля 2020 г. Получено 19 ноября 2009 г.
  26. ^ Opera Software ASA (23 апреля 2012 г.). "Поддержка веб-спецификации в Opera Presto 2.10". Архивировано из оригинала 20 июня 2018 г. Получено 8 мая 2012 г.
  27. ^ Лэнгли, Адам [@agl__] (20 декабря 2013 г.). «Подтверждено. См. ~/Library/Cookies/HSTS.plist. Включает предварительные загрузки Chromium с некоторой даты и обрабатывает заголовки HSTS» ( Твит ). Архивировано из оригинала 9 мая 2019 г. Получено 20 декабря 2013 г. – через Twitter .
  28. ^ "HTTP Strict Transport Security приходит в Internet Explorer 11 в Windows 8.1 и Windows 7". windows.com . Архивировано из оригинала 27 ноября 2019 . Получено 12 июня 2015 .
  29. ^ "Internet Explorer Web Platform Status and Roadmap". Архивировано из оригинала 29 июня 2015 г. Получено 14 апреля 2014 г.
  30. ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog". 22 января 2015 г. Архивировано из оригинала 29 ноября 2019 г. Получено 23 января 2015 г.
  31. ^ Hodges; et al. "HTTP Strict Transport Security (HSTS) 6.1.2". ietf.org . Архивировано из оригинала 22 июля 2019 г. . Получено 11 ноября 2016 г. .
  32. ^ Ходжес, Дж.; Джексон, К.; Барт, А. (2012). "RFC 6797 - HTTP Strict Transport Security (HSTS) 11.4 Последствия includeSubDomains". Инструменты IETF . раздел 11.4. doi : 10.17487/RFC6797 . RFC 6797.