HTTP Strict Transport Security (HSTS) в NGINX

Исследование от Netcraft показало, что всего 5% веб-сайтов, использующих SSL/TLS для шифрования данных, правильно настроены для использования HSTS (HTTP Strict Transport Security). Этот стандарт обеспечивает дополнительный уровень безопасности, но многие сайты не используют его правильно

Что такое HSTS

HTTPS (HTTP, зашифрованный с помощью SSL или TLS) является важной частью мер по защите трафика на веб-сайт, что очень затрудняет злоумышленнику перехват, изменение или подделку трафика между пользователем и веб-сайтом.

Когда пользователь вводит веб-домен вручную (указывая доменное имя без префикса http:// или https://) или переходит по простой ссылке http://, первый запрос на веб-сайт отправляется в незашифрованном виде, используя обычный HTTP. Большинство защищенных веб‑сайтов немедленно отправляют обратно перенаправление, чтобы перевести пользователя на HTTPS‑соединение, но хорошо подготовленный злоумышленник может организовать атаку посредника или "человек посередине" (MITM), чтобы перехватить первоначальный HTTP‑запрос и с этого момента контролировать сеанс пользователя.

HSTS устраняет эту потенциальную уязвимость, сообщая браузеру, что доступ к домену возможен только по протоколу HTTPS. Даже если пользователь вводит простую HTTP-ссылку или переходит по ней, браузер строго обновляет соединение до HTTPS:

Как работает HSTS

Когда владелец сайта включает HSTS, сервер отправляет специальный заголовок в ответ на запросы, указывая, что клиенты должны использовать только защищенное HTTPS-соединение.

Strict-Transport-Security: max-age=31536000

Когда браузер видит этот заголовок с веб-сайта через HTTPS, он "запоминает", что этот домен должен использоваться только через HTTPS (SSL или TLS). Браузер кэширует эту информацию в течение периода max-age (обычно 31 536 000 секунд, что равно примерно 1 год).

Необязательный параметр includeSubDomains сообщает браузеру, что политика HSTS также распространяется на все поддомены текущего домена.

Например, HTML-ответ для https://www.example.com может содержать запрос к ресурсу с https://example.com, чтобы убедиться, что политика HSTS установлена для всех поддоменов example.com.

Настройка HSTS в NGINX и NGINX Plus

Настройка заголовка ответа Strict Transport Security (STS) в NGINX и NGINX Plus довольно проста:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Параметр always гарантирует, что заголовок устанавливается для всех ответов, включая внутренне сгенерированные ошибочные ответы. В старых версиях NGINX (до версии 1.7.5 или NGINX Plus R5) нет поддержки параметра always, и заголовок не устанавливается для внутренне сгенерированных ошибок.

Правила наследования директив add_header

В конфигурации NGINX директивы add_header передаются из более общего блока внутрь более специфичного. Поэтому, чтобы применить заголовки ко всему серверу, достаточно указать их в самом верхнем блоке сервера. Но есть исключение: если в блоке уже есть своя директива add_header, то он не наследует заголовки из внешних блоков, и их нужно указывать заново внутри этого блока.

server {
    listen 443 ssl;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Этот блок 'location' наследует заголовок STS
    location / {
        root /usr/share/nginx/html;
    }

    # Поскольку в этом блоке 'location' есть другая директива 'add_header',
    # мы должны повторно объявить заголовок STS
    location /servlet {
        add_header X-Served-By "My Servlet Handler";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        proxy_pass http://localhost:8080;
    }
}

Тестируйте HTTP Strict Transport Security осторожно

Когда браузер клиента впервые получает политику HSTS, он сохраняет эту информацию на определенный период (max-age). В течение этого времени браузер отказывается подключаться к веб-сервису через незашифрованный HTTP и не дает исключений для ошибок сертификата (если сайт ранее представил действительный и доверенный сертификат). Если вы указываете параметр includeSubDomains для политики HSTS, эти ограничения также распространяются на все поддомены текущего домена.

Отменить политику HSTS и вернуться к HTTP-версии веб-сайта или сервиса достаточно сложно. При тестировании HSTS используйте очень короткий период max-age и убедитесь, что вы удовлетворены влиянием и обязанностью поддерживать HTTPS-версию вашего сайта. Когда вы впервые запускаете свою политику HSTS, устанавливайте небольшое значение для max-age и увеличивайте его только тогда, когда вы уверены, что это безопасно.

Должен ли каждый HTTPS-ответ иметь заголовок STS?

Цель - представить политику HSTS вашим пользователям как можно скорее, как только они начинают безопасную сессию HTTPS. Если они не получают политику HSTS в течение этой сессии, они остаются уязвимыми к будущим атакам перехвата на HTTP.

Браузеру нужно увидеть заголовок STS только один раз, поэтому не обязательно добавлять его в каждый блок расположения и каждый ответ. Однако, если добавить его только на главную страницу или страницу входа, это, вероятно, будет недостаточным, и если добавить заголовок только к кэшируемым ответам, клиент может его не увидеть. Убедитесь, что вы охватываете как можно больше адресов ваших URL, особенно обращая внимание на динамический (некэшируемый) контент.

Одновременное использование HTTP- и HTTPS-версий веб-сайта

Некоторые сайты запускают версии веб-сайта для протоколов HTTP и HTTPS на одном и том же сервере с использованием NGINX или NGINX Plus, чтобы обеспечить доступ к контенту через любой из этих протоколов.

server {
    listen  80;
    listen  443 ssl;
    # ...
}

Это не подойдет при использовании HSTS, потому что вы не хотите, чтобы пользователи получали доступ к контенту через HTTP. Вместо этого вы хотите перенаправлять все запросы к веб-сайту через HTTP на HTTPS.

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;

    # Используя постоянное перенаправление на домашнюю страницу сайта через HTTPS
    return 301 https://$host;

    # В альтернативе, можно перенаправить все HTTP-ссылки на соответствующую страницу через HTTPS
    # return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Усиление политики HSTS

Браузер клиента защищен от перехвата данных через HTTP после того, как он видел заголовок STS для соответствующего домена в течение объявленного периода max-age.

Однако HSTS не является идеальным решением для предотвращения перехвата HTTP-сессии. Пользователи по-прежнему уязвимы для атаки, если они заходят на защищенный HSTS-сайт через HTTP, когда у них:

• Никогда раньше не было посещений этого сайта.
• Недавно переустановили свою операционную систему.
• Недавно переустановили свой браузер.
• Переключились на новый браузер.
• Переключились на новое устройство (например, мобильный телефон).
• Удалили кэш своего браузера.
• Не посещали сайт давно, и время действия max-age истекло.

Источник: Netcraft

Для решения этой проблемы Google поддерживает "Список предварительной загрузки HSTS" для веб-доменов и поддоменов, использующих HSTS и отправивших свои имена на https://hstspreload.appspot.com/. Этот список доменов распространяется и зашит в код крупных веб-браузеров. Клиенты, обращающиеся к доменам из этого списка, автоматически используют HTTPS и отказываются от доступа к сайту через HTTP.

Почитать об этом больше

Для получения дополнительной информации о HSTS вам помогут следующие ресурсы:

• RFC 6797, HTTP Strict Transport Security (HSTS);
• HTTP Strict Transport Security на Wikipedia;
• Поддержка HSTS в браузерах.

Если вы рассматриваете возможность добавления заголовка STS в свою конфигурацию NGINX, также можете рассмотреть использование других заголовков, направленных на обеспечение безопасности, таких как X-Frame-Options и X-XSS-Protection.

Оригинал статьи: HTTP Strict Transport Security (HSTS) and NGINX