HSTS, Mixed Content и другие защитные механизмы
HSTS, Mixed Content и другие защитные механизмы
TLS шифрует соединение, но одного шифрования недостаточно. Атакующий может попытаться понизить HTTPS до HTTP, внедрить незащищённый ресурс на защищённую страницу или использовать другие трюки. В этом уроке разберём защитные механизмы, которые браузеры используют для предотвращения таких атак.
HSTS: Strict-Transport-Security
Проблема: пользователь впервые заходит на example.com, набирая в адресной строке просто example.com (без https://). Браузер по умолчанию пробует HTTP. Сервер делает редирект 301 на HTTPS. Но этот первый HTTP-запрос уязвим — атакующий может перехватить его и не дать редиректу случиться (SSL Stripping attack).
HSTS (HTTP Strict Transport Security) решает эту проблему. Сервер при первом успешном HTTPS-соединении отправляет заголовок:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Это означает: «год (31536000 секунд) общайся со мной только по HTTPS, включая поддомены». Браузер запоминает это и при следующем вводе example.com в адресной строке сам перепишет URL на https://example.com, не делая HTTP-запрос.
Ключевое: HSTS работает только ПОСЛЕ первого успешного HTTPS-соединения. Проблема самого первого захода (TOFU — Trust On First Use) остаётся. Для её решения существует HSTS Preload List — список доменов, встроенный прямо в браузер. Владелец домена может зарегистрироваться в списке через hstspreload.org, и тогда даже самый первый заход на сайт будет по HTTPS.
Mixed Content: HTTPS-страница с HTTP-ресурсами
Сайт перешёл на HTTPS, но забыл обновить URL картинок, скриптов или стилей. Страница загружается по HTTPS, но внутри ссылается на http://.... Браузер блокирует такие ресурсы, так как они разрушают безопасность страницы:
- Active Mixed Content (блокируется всегда): скрипты, стили, iframe, WebSocket, fetch/XHR. Атакующий может изменить скрипт на лету и получить контроль над страницей.
- Passive Mixed Content (блокируется в современных браузерах): изображения, видео, аудио. Риск меньше, но атакующий может подменить картинки и изменить восприятие страницы.
Решение: всегда использовать https:// в URL ресурсов. Или протокол-относительные URL: //cdn.example.com/logo.png — браузер сам подставит тот же протокол, что у страницы.
Браузер показывает предупреждение в консоли: Mixed Content: The page at '...' was loaded over HTTPS, but requested an insecure script. Разработчик должен исправить все такие случаи — страница с Mixed Content не считается безопасной.
CAA DNS-запись: кто может выдавать сертификаты
CAA (Certification Authority Authorization) — это DNS-запись, в которой владелец домена указывает, какие центры сертификации имеют право выдавать сертификаты на его домен:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
Если злоумышленник взломает аккаунт у стороннего CA и попытается выпустить сертификат на example.com, CA ОБЯЗАН проверить CAA-запись и отказать, если его нет в списке. CAA защищает от атак через компрометацию центров сертификации и от ошибок в автоматизации (например, CI/CD случайно заказал сертификат у неправильного CA).
Дополнительно можно указать email для уведомлений о нарушениях:
example.com. CAA 0 iodef "mailto:security@example.com"
ALPN: согласование протокола прикладного уровня
При TLS handshake клиент и сервер должны договориться не только о шифровании, но и о протоколе прикладного уровня. ALPN (Application-Layer Protocol Negotiation) — расширение TLS, позволяющее согласовать HTTP/1.1, HTTP/2 или HTTP/3:
ClientHello содержит ALPN: ["h2", "http/1.1"]
ServerHello выбирает: "h2"
Без ALPN сервер не знал бы, какой протокол использовать, и клиенту пришлось бы делать дополнительный round-trip. ALPN решает это за один обмен в рамках рукопожатия.
Заголовки безопасности, связанные с HTTPS
Современные сайты на HTTPS используют несколько дополнительных заголовков для усиления безопасности:
Expect-CT (устарел, но концепция важна): сообщал браузеру, что сайт ожидает присутствия сертификата в Certificate Transparency логах. Сейчас CT обязателен для всех новых сертификатов, поэтому Expect-CT больше не нужен.
Clear-Site-Data: позволяет сайту попросить браузер очистить данные, связанные с доменом (cookies, cache, storage). Полезно при выходе из аккаунта:
Clear-Site-Data: "cookies", "storage", "cache"
Другие защитные заголовки
Помимо HSTS и CAA, современные HTTPS-сайты используют несколько дополнительных заголовков безопасности. Хотя они относятся скорее к безопасности приложения, чем к транспорту, их важно знать как часть общей картины:
Content-Security-Policy (CSP) — указывает браузеру, откуда можно загружать ресурсы (скрипты, стили, изображения). Значительно снижает риск XSS-атак:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
X-Content-Type-Options — запрещает браузеру угадывать MIME-тип содержимого (MIME sniffing). Без этого заголовка браузер может выполнить текстовый файл как JavaScript:
X-Content-Type-Options: nosniff
X-Frame-Options — запрещает встраивать сайт в iframe на других доменах, защищая от clickjacking:
X-Frame-Options: DENY
Эти заголовки не заменяют TLS, а дополняют его. TLS шифрует трафик, а security-заголовки защищают от атак на уровне приложения.
Что происходит, когда сертификат недействителен
Если сертификат просрочен, не соответствует домену или не проходит проверку цепочки, браузер показывает предупреждение:
Ваше соединение не защищено
NET::ERR_CERT_DATE_INVALID
Раньше пользователь мог нажать «Всё равно продолжить». Современные браузеры всё чаще убирают эту возможность для большинства ошибок. HSTS-сайты не позволяют обойти предупреждение — кнопка просто отсутствует.
Это правильный подход: если соединение не защищено, лучше не открывать сайт вообще, чем дать пользователю ложное чувство безопасности.
Проверь себя
- Почему HSTS не защищает самый первый заход на сайт без preload?
- Чем Active Mixed Content опаснее Passive?
- Зачем нужна CAA DNS-запись?
- HSTS устанавливается заголовком при первом HTTPS-ответе. Если атакующий перехватит самый первый HTTP-запрос до редиректа, HSTS ещё не будет в кэше браузера. Preload решает это, встраивая HSTS в браузер заранее.
- Active Mixed Content (скрипты, стили) позволяет атакующему выполнить код на странице — полный контроль. Passive (изображения) может только исказить внешний вид, не даёт выполнения кода.
- CAA указывает, какие CA могут выдавать сертификаты на домен. Защищает от мошеннических сертификатов через компрометацию CA или ошибки автоматизации.
Что унести с урока
- HSTS заставляет браузер всегда использовать HTTPS, предотвращая SSL Stripping. HSTS Preload List защищает даже первый заход.
- Mixed Content (HTTP-ресурсы на HTTPS-странице) блокируется браузером. Active блокируется всегда, Passive — в современных браузерах.
- CAA DNS-запись ограничивает, какие CA могут выпускать сертификаты на домен.
- ALPN позволяет согласовать HTTP/1.1, HTTP/2 или HTTP/3 в рамках TLS handshake.
Модуль «HTTPS и TLS» завершён. Мы разобрали, как HTTP превращается в защищённый HTTPS и какие механизмы обеспечивают безопасность в вебе. Теперь пора посмотреть, как всё это работает вместе — в следующем модуле разберём что происходит, когда ты нажимаешь Enter в адресной строке: полный путь от URL до отрисованной страницы.