Strict transport security что это
Strict-Transport-Security
| Header type | Response header (en-US) |
|---|---|
| Forbidden header name | no |
Syntax
Директивы
Описание
Если сайт поддерживает доступ с помощью HTTP и перенаправляет на HTTPS, посетители могут изначально коммуницировать с незащищённой версией сайта до перенаправления, если, к примеру, введут http://www.foo.com/ или даже просто foo.com. Это открывает возможности для атак посредников. Перенаправление может быть использовано для перевода посетителей на сайт злоумышленников вместо защищённой версии оригинального сайта.
HTTP Strict Transport Security заголовок сообщает браузеру, что тот никогда не должен загружать сайт через HTTP и всегда должен автоматически конвертировать все попытки доступа к сайту с помощью HTTP в HTTPS.
Пример сценария
Вы залогинились через бесплатную точку доступа WiFi в аэропорту и начали серфить в сети, посещая ваш сервис online-банкинга для того, чтобы проверить баланс и оплатить пару счетов. К сожалению, точка доступа на самом деле хакерский ноутбук, и они перехватывают ваш оригинальный HTTP запрос и перенаправляют вас на клонированную версию вашего банковского сайта. Теперь ваша личная информация доступна хакерам.
Strict Transport Security разрешает эту проблему; пока вы подключены к вашему банковскому сайту с помощью HTTPS и тот использует Strict Transport Security, ваш браузер знает, что должен автоматически использовать только HTTPS, который не позволяет хакерам производить подобные атаки посредников.
Как ведёт себя браузер
При первом доступе к сайту с помощью HTTPS и возврате Strict-Transport-Security заголовка, браузер сохраняет эту информацию, чтобы в дальнейшем при загрузке сайта через HTTP тот автоматически использовал HTTPS.
Когда время истечения, заданное Strict-Transport-Security заголовком, заканчивается, следующая попытка загрузки сайта с помощью HTTP будет воспринята, как обычная без автоматического использования HTTPS.
Каждый раз, когда браузер получает Strict-Transport-Security заголовок, он обновляет время истечения этого сайта, так что сайт может обновлять эту информацию и предотвратить его завершение. Если необходимо отключить Strict-Transport-Security, установите max-age в 0 (через https соединение) и тот моментально завершит Strict-Transport-Security заголовок, открывая доступ через http.
Предзагрузка Strict Transport Security
Google поддерживает HSTS preload service. Следуя инструкциям и удачно отправив свой домен, браузер никогда не подключится к вашему домену через незащищённое соединение. Так как сервис хостится Google, все браузеры должны изъявить о намерении использовать (или на самом деле начать пользоваться) предзагруженным списком. Однако, это не часть HSTS спецификации и не должно считаться официальным.
Пример
Все текущие и будущие субдомены будут HTTPS по max-age на 1 год. Это блокирует доступ к страницам или субдоменам, которые могут быть доступны только по HTTP.
Полное руководство по настройке HTTP-заголовков для безопасности
Компании, продающие «системы показателей безопасности», сейчас на подъеме, их влияние в сфере корпоративных продаж растет. К тому же есть те, кого низкий рейтинг безопасности у продавцов смущает, и те, кто хотя бы однажды, глядя на рейтинг, отказался от покупки, — я с такими людьми общался.
Я посмотрел, как эти компании вычисляют показатели безопасности других компаний. Оказалось, они смотрят на сочетание использования НТТР-заголовка для безопасности и репутации IP-адресов.
Репутация IP-адреса основывается на данных черных списков и списков спамеров в сочетании с данными о владельце общедоступного IP-адреса. Она, в принципе, должна быть чистой, если ваша компания не рассылает спам и в состоянии быстро определить и остановить вредоносное внедрение. Использование заголовка безопасности НТТР вычисляется аналогично тому, как работает Observatory от Mozilla.
Таким образом, рейтинг большинства компаний, в основном, определяется заголовками, включенными на общедоступных веб-сайтах для безопасности.
Настроить заголовок правильно — это недолго (серьезной проверки не потребуется), но это улучшит безопасность сайта и поможет не растерять покупателей, для которых безопасность — не пустой звук
В ценности упомянутой методики проверки я сомневаюсь, к том же ценник за услугу выставлен заоблачный. Вряд ли компании-поставщики этой услуги способны определить безопасность ресурса с заявленной точностью. Впрочем, ситуация лишний раз подчеркивает, как важно сесть и уделить время тому, чтобы включить и настроить правильные заголовки.
В этой статье я буду говорить о наиболее часто проверяемых заголовках, для каждого посоветую значения безопасности и приведу пример настройки. В конце дам примеры настройки для распространенных приложений и веб-серверов.
Важные заголовки для безопасности
Content-Security-Policy
CSP применяется, чтобы предотвращать межсайтовый скриптинг — путем определения, какие ресурсы могут быть загружены. Из всего списка этот заголовок отнимет больше остальных времени на создание и правильную поддержку, а еще больше других подвержен рискам. Разрабатывая CSP, тщательно его проверяйте — если вдруг заблокируете используемый вами же источник, то нарушите функциональность собственного сайта.
Для предварительной версии можно использовать замечательный инструмент — расширение для браузера Mozilla, Laboratory CSP. Установите его в браузере, тщательно изучите сайт, для которого хотите создать CSP, а после используйте сгенерированную CSP на своем сайте. В идеале, нужно еще переработать JavaScript, так что можно удалить директиву «unsafe inline».
CSP может показаться сложной и сбить с толку, поэтому, если хотите углубиться в тему, посетите официальный сайт.
Предварительно можно настроить CSP так (на боевом сайте она, скорее всего, потребует множества модификаций). Добавьте в каждый раздел вашего сайта домены.
Strict-Transport-Security
Этот заголовок сообщает браузеру, что на сайт заходить можно только по протоколу HTTPS — всегда включайте его, если на вашем сайта активирован HTTPS. Включите его на всех используемых субдоменах, если таковые имеются.
X-Content-Type-Options
Благодаря этому заголовку браузеры придерживаются типов MIME, установленных приложением, что помогает предотвратить часть атак с межсайтовым скриптингом.
Также он снижает риск неожиданного поведения приложения, когда браузер неверно «угадывает» тип контента на сайте — например, если разработчик обозначает страницу «HTML», а браузер видит JavaScript и пытается отрисовать страницу соответственно. Также благодаря этому заголовку браузер всегда держится установленных сервером MIME-типов.
Cache-Control
Этот будет позаковыристее прочих, потому что для разных типов контента вам наверняка нужны разные политики кэширования.
Никакая деликатная информация — вроде страницы пользователя или страницы оплаты товара — не должна кэшироваться. Одна из причин для этого — чтобы другой пользователь компьютера не нажал кнопку «назад», не прочел историю и не увидел личных данных другого пользователя.
Впрочем, кэшировать можно и нужно те страницы, которые обновляются редко, например статические ресурсы (картинки, файлы CSS и JS). Кэширование можно настроить на постраничной основе, или используя regex в настройках сервера.
Expires
Этот заголовок устанавливает время, на которое текущий запрос сохраняется в кэше. Он игнорируется, если включен заголовок Cache-Control max-age, так что мы включаем его только на случай, если его проверяет простенький сканер — без учета контроля кэширования.
Мы предполагаем, что в целях безопасности браузер не кэширует ничего, так что дата в заголовке всегда будет в прошлом.
X-Frame-Options
Этот заголовок разрешает отображение сайта в iFrame.
Поместив ваш веб-сайт в iFrame, вредоносный ресурс получает возможность произвести кликджекинг атаку — запустив некий JavaScript, который обманом вынудит пользователя кликнуть по iFrame, а после начнет взаимодействовать с ресурсом от его, пользователя, имени (то есть человек кликнет по вредоносной ссылке или кнопке, даже не подозревая об этом!).
Этот заголовок всегда надо настраивать на отказ, исключение — если вы намеренно используете фреймы. Тогда заголовок нужно настраивать на тот же источник. Если вы по умолчанию используете фреймы с другим сайтом, занесите сторонний домен в белый список.
Следует также отметить, что этот заголовок замещается директивой CSP frame-ancestors. Я его рекомендую пока включать, но только для того, чтобы заткнуть инструменты для проверки заголовков, в будущем от него скорее всего избавятся.
Access-Control-Allow-Origin
Этот заголовок сообщает браузеру, внешний код каких посторонних сайтов имеет право делать запросы к определенной странице. Настройки по умолчанию обычно правильные, но если надо — можно и поменять.
Например, сайт А содержит некий JavaScript, который хочет сделать запрос к сайту В. Сайт В должен ответить на этот запрос — если заголовок разрешает сайту А сделать запрос. Если нужно настроить множество источников, подробности на странице на MDN.
Тут можно слегка запутаться, поэтому я составил схему — проиллюстрировать, как работает этот заголовок:
Поток данных с Access-Control-Allow-Origin
Set-Cookie
Убедитесь, что ваши cookies устанавливаются только через протокол HTTPS (с шифрованием), и что к ним нет доступа через JavaScript. Эти файлы можно посылать, только если ваш сайт тоже поддерживает HTTPS, как и должно быть. Всегда нужно выставлять вот такие флаги:
Пример определения Cookie:
X-XSS-Protection
Этот заголовок приказывает браузеру прервать выполнение обнаруженных атак межсайтового скриптинга. Включая его, вы не сильно рискуете, но перед запуском в производственную среду все равно протестируйте.
Пример настроек веб-сервера
Вообще, в настройках сервера лучше всего добавлять заголовки на весь сайт. Исключение — файлы cookie, поскольку они определяются в самом приложении.
Советую, прежде чем добавить на сайт заголовки, сперва свериться с Observatory или вручную заглянуть в заголовки — проверить, какие уже установлены. Некоторые движки сайтов и сервера самостоятельно все установят, поэтому просто реализуйте нужные вам заголовки или измените те, которые в этом нуждаются.
Конфигурация Apache
Конфигурация Nginx
Настройка заголовка уровня приложения
Если у вас нет доступа к веб-серверу или требования к настройке заголовков сложные, то вам наверняка придется настроить их в самом приложении. Обычно для всего сайта это осуществляется с помощью промежуточного ПО, или на основе однократной установки заголовков при каждом запросе.
Для краткости в каждый пример я включил только по одному заголовку. Вы же добавляйте по тому же способу все, которые нужны.
Добавьте global mount path:
Java и Spring
У меня мало опыта работы со Spring, но у Baeldung есть отличное руководство по настройке заголовков в Spring.
Я не знаком с разнообразными средами PHP. Ищите промежуточное ПО для запросов. Для единичного запроса все просто.
Python / Django
Django включает настраиваемое промежуточное ПО для обеспечения безопасности, которое выполнит за вас все эти настройки. Активируйте сначала их.
Ответы некоторых страниц можно трактовать как словарь. В Django есть особый способ работы с кэшированием, и если хотите настроить заголовки кэширования таким образом, с ним надо ознакомиться.
Выводы
Настройка заголовков — процесс относительно простой и быстрый, зато дает прирост уровня безопасности сайта — в плане защиты данных, от межсайтового скриптинга и кликджекинга.
В будущем вы оградите себя от срыва сделок, потому что ваш рейтинг безопасности останется на уровне. Практика его оценки на основе рассмотренных мной параметров набирает обороты, и мне кажется, ее роль в ближайшие годы в сфере продаж только усилится.
Дайте знать, если я упустил какой-то важный заголовок!
Осторожно: HSTS
Про HSTS на Хабре уже писали, этот механизм включен в генераторе конфигов для веб-серверов от Mozilla. Написать этот пост я решил за один день столкнувшись с недоступность сразу двух крупных сайтов из-за HSTS.
Что такое HSTS?
HSTS (HTTP Strict Transport Security) — это механизм защиты от даунгрейд-атак на TLS, указывающий браузеру всегда использовать TLS для сайтов с соответствующими политиками. Стандарт описан в RFC6797, а политики бывают двух видов:
Динамические
Политика применяется из HTTP-заголовка Strict-Transport-Security при первом заходе на сайт по HTTPS, в нём указан срок действия и применимость к субдоменам:
Статические
Статические политики захардкожены в браузер и для некоторых сайтов включает привязку к вышестоящему CA, выпустевшему сертификат (например: google.com, paypal.com или torproject.org). Причем она может действовать только когда сайт открыт через TLS, разрешая незащищённое соединение, но блокируя MitM с подменой сертификата.
Список из Chromium используют все популярные браузеры (Firefox, Safari и IE 11+Edge) и добавить в него сайт может любой желающий, если веб-сервер отдаёт заголовок Strict-Transport-Security со сроком действия от двух лет и ключевым словом preload в конце:
Как выстрелись себе в ногу?
На днях коллеги пожаловались на недоступность некоторых разделов сайта 1С (dist.1c.ru и partweb.1c.ru). Поддержка уверяла что всё работает, у меня проблема не воспроизводилась и даже у коллег сайты открылись из всех браузеров, кроме основного Chrome. Тот выдал ERR_CONNECTION_TIMED_OUT спустя 20 секунд и почему-то настойчиво подставлял HTTPS в URL, даже если адрес был написан полностью с HTTP.
Решение пришло почти сразу, так как недавно упоминали HSTS в контексте корпоративного MitM. Гуглёж по ключевому слову первой ссылкой подсказал, что посмотреть кэш политик можно в chrome://net-internals/#hsts и догадка подтвердилась:
Политика включала все субдомены, хотя многие из них были доступны только на 80 порту без TLS.
После её удаления нужные разделы стали открываться, по дате получения (в формате unix time) в истории браузера нашли страницу с неверными настройками и отправили багрепорт в 1С.
Вторым сайтом оказался ask.mcdonalds.ru, который открывался первый раз, однако Chrome всё равно показал предупреждение с уже знакомой четырёхбуквенной аббревиатурой и без привычной кнопки Proceed to (unsafe):
Ошибка говорит о несоответствии имени сертификата, окончании срока действия или его отзыве, а показ кнопки для открытия сайта прямо запрещён в RFC. При этом политика для mcdonalds.ru оказалась статической, которую нельзя удалить из chrome://net-internals/#hsts.
Обойти такую заглушку в Chrome можно набрав thisisunsafe (предыдущим волшебным словом были badidea, а до него danger) или запустив браузер с ключом —ignore-certificate-errors.
В Firefox надо нажать «Forge About This Site» напротив сайта в истории, открыть about:config и создать новый Integer с именем «test.currentTimeOffsetSeconds» и значением 11491200, а затем открыть сайт в новой вкладке.
Выводы
Не включайте потенциально опасные функции без понимания принципов их работы. Оценку «A» в тесте от SSL Labs вы получите и без HSTS, а включить его можно после проверки всего функционала через TLS. Со статическим листом в браузере пути назад уже не будет, поэтому лучше сразу приобрести сертификат с wildcard.
Chrome и Firefox поддерживают дополнительный механизм защиты: HTTP Public Key Pinning (HPKP), позволяющий привязать хэш сертификата и отправлять уведомление владельцу, если браузеру попадётся сертификат от публичного CA для его домена с другим хэшем. Он помог раскрыть несколько инцидентов с публичными CA, но на практике используется очень редко из-за высокой цены ошибки.
Интересен состав захардкоженных политик в Chromium: кроме сети фастуда, нескольких доменов Mail.ru и Яндекса, там есть только ЮниКредит из ТОП-15 российски банков. Нет ни модного ТКС, ни Qiwi, ни WebMoney, а динамические политики оказались включены лишь у Qiwi и для адресов интернет-банков Бинбанка, МКБ, Открытия, Райффайзена и РСХБ.
Ещё там нет Телеграма, но есть Whatsapp, а в логе изменений встречаются запросы на удаление (!) ошибочно включенных сайтов, где какое-то время был preload в заголовке.
«HTTP Strict-Transport-Security» или как обезопасить себя от атак «man-in-the-middle» и заставить браузер всегда использовать HTTPS
Внимание к мелочам рождает совершенство,
а вот совершенство уже не мелочь.
C 2012 года администраторам веб-ресурсов стала доступна новая технология HTTP Strict Transport Security (HSTS) — механизм, активирующий форсированное защищённое соединение по HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение, вместо использования HTTP. Механизм использует особый заголовок HTTP Strict-Transport-Security, для переключения пользователя, зашедшего по HTTP, на HTTPS-сервер [1].
HSTS направлен на закрытие следующих уязвимостей к атакам:
| Пользователь помещает в закладки или набирает в адресной строке http://example.com/ и становится жертвой атаки «man-in-the-middle» | HSTS автоматически преобразует HTTP-запросы в HTTPS для целевого домена |
| Веб-приложение, предполагаемое к использованию строго по HTTPS, по небрежности содержит HTTP-ссылки или отдает контент по HTTP | HSTS автоматически преобразует HTTP-запросы в HTTPS для целевого домена |
| Атакующий «man-in-the-middle» пытается перехватить трафик жертвы используя поддельный сертификат в надежде, что пользователь не обратит внимания на сообщение о невалидном сертификате | HSTS не даст пользователю пройти дальше сообщения о проблемах с сертификатом |
Включается данная технология проще простого, необходимо возвращать пользователю HTTP-заголовок «Strict-Transport-Security» в тот момент, когда он заходит на сайт по HTTPS:
expireTime
Время в секундах, на которое браузер должен запомнить, что данный сайт должен посещаться исключительно по HTTPS. includeSubdomains (опционально)
Если указать этот необязательный параметр, правила так же применятся ко всем поддоменам.
Что это дает
В случае, если веб-сайт принимает соединения по HTTP и перенаправляет их на HTTPS, пользователь вполне может обратиться к незашифрованной версии сайта до перенаправления если, к примеру, он наберет в адресной строке http://example.com/ или, еще проще, example.com. Это открывает потенциальную возможность проведения атаки «man-in-the-middle», в которой HTTP-перенаправление вместо оригинальной зашифрованной страницы отправит пользователя прямиком на сайт злоумышленника.
Механизм HTTP Strict Transport Security позволяет веб-сайту проинформировать браузер, что тот не должен использовать HTTP и, вместо этого, автоматически со своей стороны преобразовывать все HTTP-запросы в HTTPS.
Например, вы подключаетесь к открытой точке доступа Wi-Fi в публичном месте и открываете ДБО своего любимого банка, чтобы проверить баланс и совершить пару платежей. К несчастью, используемая вами точка доступа на самом-то деле — ноутбук злоумышленника, перехватывающего ваши HTTP-запросы и перенаправляющего вас вместо оригинального сайта банка на страничку-клон. Ваши данные попадают прямо ему в руки.
HSTS решает данную проблему. Если вы хоть раз успешно подключились к веб-сайту банка по HTTPS, использующему «Strict Transport Security», браузер автоматически начнет использовать HTTS для всех запросов. Это предотвратит возможность атак «man-in-the-middle» вышеописанного типа.
Как поступает браузер
Кстати: заголовок «Strict-Transport-Security» игнорируется браузером в случае подключения по HTTP, так как атакующий может перехватить HTTP-соединение и подменить заголовок. Браузер поймет, что сайт HTTPS-совместим и должным образом обработает заголовок «Strict-Transport-Security» в том случае, если доступ к сайту происходит по HTTPS без ошибок с сертификатами.
Поддержка браузерами
Детали реализации
Заголовки «Strict-Transport-Security» должны передаваться только по HTTPS. Клиенты не должны обрабатывать HSTS заголовки, присланные, не в HTTPS-ответах или по HTTPS с невалидными, неверно настроенными сертификатами. Следующие отрывки конфигурации должны находиться внутри контекста SSL и примеры кода предполагаются исключительно в контексте HTTPS ответов.
Имейте ввиду, что директива «max-age» представлена в секундах. 31536000 секунд (12 месяцев) в примерах ниже м.б. изменены в зависимости от того, как долго администратор веб-сервера предполагает использовать сайт исключительно по HTTPS. Рекомендовано устанавливать значение «max-age» довольно большим вроде 31536000 (12 мес.) или 63072000 (24 мес.). [3]
Strict transport security что это
При вводе домена в адресной строке без протокола https либо в формате «site.ru» в браузере сперва выводится незащищенная версия сайта. Даже если на нем установлен SSL-сертификат, перенаправление происходит уже после первого перехода. Этим моментом пользуются мошенники с целью перехвата данных пользователя и перенаправления его на подставную страницу.
HSTS — это алгоритм взаимодействия между браузером и сервером, при котором сайту присваивается статус защищенного на заданный период. Это делается с помощью заголовка HTTP Strict Transport Security. Он выдается при ответе сервера и указывает браузеру на необходимость постоянной автоматической переадресации на версию сайта под протоколом https.
Несмотря на основное предназначение HSTS — защитить соединение, клиент остается уязвим при:
Для решения этой проблемы был создан список Preload List от Google. После обращения к сайту браузер проверяет наличие сайта в этом списке и лишь потом соединяет клиента с сервером по безопасному протоколу. Попасть в Preload List можно с помощью онлайн-запроса:
При активной технологии HSTS, если сертификат SSL окажется просроченным либо какие-то страницы ресурса не будут доступны по защищенному соединению — пользователь не получит доступ к ним. Обойти шифрованное соединение через HSTS не удастся ни в одном из браузеров.
Выйти из Preload List сложно. Чтобы это сделать, необходимо подать запрос на этом же ресурсе и ждать ответа. Для Chrome это происходит более трех месяцев, а для других браузеров — еще дольше. В этот период сайт недоступен пользователям. Перед внесением в Preload List определитесь наверняка, собираетесь ли постоянно поддерживать на сайте работу протокола https.
При подключенной технологии в браузере пользователю будут высвечиваться сайты, работающие исключительно по протоколу https. Даже если он введет в адресную строку домен через http, браузер автоматически перенаправит его на версию сайта с https. Механизм HSTS призван уменьшить количество незашифрованных соединений и свести к минимуму риски перехвата данных и кукисов.