✖


Jump to content

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

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

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

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

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

[ редактировать ]

Спецификация HSTS была опубликована как RFC 6797 19 ноября 2012 года после того, как 2 октября 2012 года она была одобрена IESG для публикации в качестве предлагаемого стандарта 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 сертификат сервера не является доверенным), пользовательский агент должен разорвать соединение (раздел 8.4 RFC 6797, Ошибки при установлении безопасного транспорта) и не должен разрешать пользователю доступ к веб-приложению. (раздел 12.1, Отсутствие возможности обращения со стороны пользователя).

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

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

[ редактировать ]

Самая важная уязвимость безопасности, которую может устранить HSTS, — это атаки типа «посредник» с отключением SSL , впервые публично представленные Мокси Марлинспайком в его докладе BlackHat Federal в 2009 году «Новые приемы для победы над SSL на практике». [11] [12] Атака с удалением SSL (и TLS ) работает путем прозрачного преобразования безопасного HTTPS- соединения в простое HTTP-соединение. Пользователь может видеть, что соединение небезопасно, но, что крайне важно, невозможно узнать, должно ли соединение быть безопасным. На момент выступления Марлинспайка многие веб-сайты не использовали TLS/SSL, поэтому не было возможности узнать (без предварительного знания), было ли использование простого HTTP результатом атаки или просто потому, что веб-сайт не реализовал TLS/SSL. 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, перехватчик «посредник» может обслуживать трафик из искусственного домена, которого нет в списке предварительной загрузки HSTS, [21] это может стать возможным благодаря атакам спуфинга DNS, [22] или просто доменное имя, которое ошибочно напоминает настоящее доменное имя, например www.example.org вместо www.example.com .

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

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

Проблемы конфиденциальности

[ редактировать ]

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

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

[ редактировать ]
Страница настроек «Безопасность в Chromium 45», показывающая состояние политики безопасности для домена «en.wikipedia.org».
Settings page for HTTPS Strict Transport Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org".

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

[ редактировать ]

В зависимости от фактического развертывания существуют определенные угрозы (например, атаки с использованием файлов 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]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б с «Строгая транспортная безопасность» . Веб-документы MDN . Мозилла . Архивировано из оригинала 20 марта 2020 года . Проверено 31 января 2018 г.
  2. ^ Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). «Политика HSTS» . Строгая транспортная безопасность HTTP (HSTS) . IETF . сек. 5.2. дои : 10.17487/RFC6797 . РФК 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» (было: IETF BoF @IETF-78 Маастрихт: 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. дои : 10.17487/RFC6797 . РФК 6797 .
  10. ^ Перейти обратно: а б Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). 2.4. Модель угроз . IETF. сек. 2.3. дои : 10.17487/RFC6797 . РФК 6797 .
  11. ^ Марлинспайк, Мокси (2009). Новые приемы борьбы с SSL на практике (PDF) . Брифинги «Черной шляпы» . Вашингтон, округ Колумбия. Архивировано (PDF) из оригинала 30 декабря 2014 года . Проверено 15 марта 2012 г.
  12. ^ Победа над SSL с помощью Sslstrip на YouTube
  13. ^ Перейти обратно: а б Лэнгли, Адам (8 июля 2010 г.). «Строгая транспортная безопасность» . Проекты Хрома . Архивировано из оригинала 1 сентября 2019 года . Проверено 22 июля 2010 г.
  14. ^ Перейти обратно: а б с Килер, Дэвид (1 ноября 2012 г.). «Предварительная загрузка HSTS» . Блог о безопасности Mozilla . Архивировано из оригинала 24 февраля 2020 года . Проверено 6 февраля 2014 г.
  15. ^ Перейти обратно: а б Белл, Майк; Уолп, Дэвид (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. ^ Сельви, Хосе (17 октября 2014 г.). Обход строгой транспортной безопасности HTTP (PDF) . Брифинги «Черной шляпы» . Амстердам. Архивировано (PDF) из оригинала 22 октября 2014 г. Проверено 22 октября 2014 г.
  18. ^ Ходжес, Джефф; Джексон, Коллин; Барт, Адам (ноябрь 2012 г.). Раздел 14.6. Уязвимость Bootstrap MITM . IETF. сек. 14.6. дои : 10.17487/RFC6797 . РФК 6797 .
  19. ^ «Список предварительно загруженных Chromium HSTS» . cs.chromium.org . Архивировано из оригинала 18 февраля 2020 года . Проверено 10 июля 2019 г.
  20. ^ Мясник, Саймон (11 сентября 2011 г.). «HTTP Строгая транспортная безопасность» . Архивировано из оригинала 26 апреля 2019 года . Проверено 27 марта 2012 г.
  21. ^ Али, Джунаде (20 октября 2017 г.). «Выполнение и предотвращение удаления SSL: простой английский учебник» . Блог Cloudflare . Архивировано из оригинала 14 декабря 2019 года . Проверено 7 декабря 2017 г.
  22. ^ Максутов А.А.; Черепанов И.А.; Алексеев, М.С. (2017). Обнаружение и предотвращение атак с подменой DNS . 2017 Сибирский симпозиум по науке о данных и инженерии (SSDSE). стр. 84–87. дои : 10.1109/SSDSE.2017.8071970 . ISBN  978-1-5386-1593-5 . S2CID   44866769 .
  23. ^ «Суперкуки HSTS, заставляющие вас выбирать: «конфиденциальность или безопасность?» —» . sophos.com . 2 февраля 2015 г. Архивировано из оригинала 11 февраля 2020 г. Проверено 1 декабря 2015 г.
  24. ^ Разработчики Chromium (17 ноября 2010 г.). «Строгая транспортная безопасность — Проекты Хрома» . Архивировано из оригинала 20 марта 2020 года . Проверено 17 ноября 2010 г.
  25. ^ Ходжес, Джефф (18 сентября 2009 г.). «К вашему сведению: строгая спецификация транспортной безопасности» . Архивировано из оригинала 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 и план действий» . Архивировано из оригинала 29 июня 2015 года . Проверено 14 апреля 2014 г.
  30. ^ «Проект Spartan и январская предварительная сборка Windows 10 — IEBlog» . 22 января 2015 г. Архивировано из оригинала 29 ноября 2019 г. . Проверено 23 января 2015 г.
  31. ^ Ходжес; и др. «HTTP Строгая транспортная безопасность (HSTS) 6.1.2» . ietf.org . Архивировано из оригинала 22 июля 2019 года . Проверено 11 ноября 2016 г.
  32. ^ Ходжес, Дж.; Джексон, К.; Барт, А. (2012). «RFC 6797 — Строгая транспортная безопасность HTTP (HSTS) 11.4. Последствия использования includeSubDomains» . Инструменты IETF . сек. 11.4. дои : 10.17487/RFC6797 . РФК 6797 .
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=HTTP_Strict_Transport_Security&oldid=1238575758"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: e38eed8e8efea0793fee221c44b4c704__1722777900
URL1:https://arc.ask3.ru/arc/aa/e3/04/e38eed8e8efea0793fee221c44b4c704.html
Заголовок, (Title) документа по адресу, URL1:
HTTP Strict Transport Security - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)