HTTPS и доверие к прокси

Cookie получила Secure-флаг для HTTPS-режима, а приложение принимает только известные хосты. Теперь рассмотрим, как внешний HTTPS связан с внутренним процессом. В реальном размещении браузер часто обращается к прокси, а тот передаёт запрос приложению по отдельному соединению.

Результат урока — схема доверия транспорта и проверяемые условия настройки. Мы не разворачиваем настоящий сервер ProfessorWeb. Команды и конфигурации относятся к будущему отдельному окружению и дополняют курс деплоя.

Два соединения

Первое соединение идёт от браузера к внешнему домену и должно соответствовать требованиям HTTPS. Второе соединяет доверенный прокси с приложением. Оно может быть локальным на сервере, но это не делает внешнюю часть автоматически защищённой.

Браузер → HTTPS → доверенный прокси
                         ↓
                  локальный процесс
                         ↓
                    база заметок

Приложение может видеть внутреннее HTTP и при этом обслуживать внешний HTTPS. Чтобы правильно построить внешний адрес или определить схему, ему иногда нужны сведения прокси. Но такие заголовки должны поступать именно от доверенного узла.

Пользователь тоже умеет отправить X-Forwarded-Proto. Если принять его от любого соединения, строка https не докажет шифрование. Конфигурация должна связать источник сведений с доступной сетью и количеством промежуточных узлов.

Заголовки прокси

Ниже содержательный фрагмент Nginx для одного известного прокси. TLS-конфигурация, промышленный WSGI-процесс и домен подготавливаются отдельно в курсе деплоя.

location / {
    proxy_pass http://127.0.0.1:4270;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $remote_addr;
}

Этот вариант заменяет переданные посетителем значения известными сведениями прокси. При другой цепочке балансировщиков договор будет отличаться. Нельзя механически увеличить число доверенных узлов до большого значения, чтобы «всё заработало».

Внутренний процесс не должен быть доступен напрямую внешнему посетителю в обход прокси. Иначе он сможет отправить собственные forwarded-заголовки по маршруту, который приложение ошибочно считает доверенным.

Зафиксируйте в схеме адрес, на котором слушает приложение, и разрешённый источник подключения к нему. При переносе процесса в контейнер прежнее обозначение localhost уже не описывает всю цепочку: заново сопоставьте адреса участников и правила доступа, прежде чем доверять заголовкам.

Порт 4270 относится к учебной схеме. Встроенный сервер разработки не становится промышленным сервером приложения из-за появления Nginx перед ним. Способ обслуживания выбирается отдельно; адрес в конфигурации только обозначает связь.

Применение ProxyFix

Werkzeug предоставляет middleware для известной цепочки. Ниже фрагмент для одного доверенного прокси, передающего адрес и схему:

from werkzeug.middleware.proxy_fix import ProxyFix

app.wsgi_app = ProxyFix(
    app.wsgi_app,
    x_for=1, x_proto=1, x_host=0, x_port=0, x_prefix=0,
)

Каждый счётчик относится к соответствующему заголовку. Нулевое значение означает, что эту разновидность сведений middleware не использует. Такая настройка должна соответствовать фактической инфраструктуре, а не произвольной форме запроса.

В локальном заключительном исходнике ProxyFix не включён автоматически. Там браузер обращается прямо к 127.0.0.1. Фрагмент добавляется только при подготовленном доверенном внешнем окружении. Это сохраняет исходную модель стенда.

Порядок применения и риски неверного количества доверенных прокси описаны в документации Werkzeug ProxyFix. Middleware интерпретирует сведения; оно не создаёт саму доверенную сеть.

Хост и cookie

Для внешнего домена список TRUSTED_HOSTS должен содержать согласованное имя. Успех локального запроса к 127.0.0.1 не проверяет внешний Host. Эта граница нужна для функций, использующих адрес приложения и маршрутизацию.

LAB_HTTPS включается в конфигурации HTTPS-окружения. Тогда сессионная cookie получает Secure. Проверить следует фактический Set-Cookie и передачу через браузер, а не только значение переменной в файле.

HttpOnly и SameSite сохраняются. TLS защищает транспорт между участниками соединения, но не разрешает доступ к чужой заметке и не исправляет XSS. Механизмы работают на разных границах одной операции.

Перенаправление и HSTS

Редирект с HTTP на HTTPS помогает выбрать правильный внешний адрес. Он не шифрует первый уже выполненный HTTP-запрос. Для домена после подготовки HTTPS можно рассмотреть HSTS по принятой политике.

Срок HSTS и распространение на поддомены требуют решения об их состоянии. Не копируйте длинный preload-набор в локальную практику без понимания: это влияет на будущие обращения браузера. Наш стенд не заявляет регистрацию домена в таком списке.

Приложение не должно строить бесконечный цикл перенаправления из-за неправильного понимания внешней схемы. Если прокси передаёт HTTPS, а процесс всё равно считает запрос внешним HTTP, сначала проверьте доверенный договор заголовков.

Наблюдение цепочки

Проверьте внешнюю страницу, сертификат, редирект и параметры cookie. Затем отдельно убедитесь, что внутренний порт недоступен по нежелательному пути. Один успешный ответ 200 не охватывает все эти условия.

Для лимита попыток полезно сравнить remote_addr после middleware с реально наблюдаемой сетью. Если все посетители выглядят одним прокси, ограничение IP будет иметь другой смысл. Если адрес берётся из произвольного пользовательского заголовка, его можно менять без изменения сети.

Отказ сертификата не нужно устранять отключением проверки клиента. Сначала разберите имя, доверенную цепочку и срок. В учебной интеграции предыдущего урока HTTP был локальной осознанной предпосылкой, а не образцом внешнего секретного обмена.

Один согласованный внешний адрес

Домен, доверенный Host и политика cookie должны описывать одну площадку. Если браузер открывает example.com, а приложение принимает только localhost, отказ Host является ожидаемым следствием конфигурации. Не исправляйте его разрешением любого имени без понимания назначения.

Напротив, список допустимых имён не создаёт DNS или сертификат. Проверки относятся к разным слоям: имя приходит по сети, прокси выбирает виртуальный сервер, TLS подтверждает согласованный домен, приложение ограничивает свой контекст.

Для нескольких прокси полезно нарисовать реальную цепочку и указать, какой узел заменяет каждый forwarded-заголовок. Только после этого выбираются числа middleware. Один заголовок может проходить через меньше узлов, чем другой.

Проверьте попытку прислать собственный X-Forwarded-Proto через внешний вход. Доверенный прокси должен сформировать свой договор. Само наличие строки https в итоговом запросе не доказывает, что источник был проверен.

На изолированном стенде без прокси эти заголовки не используются для личности и схемы. Такое исходное состояние позволяет изучать сессию, сохраняя явно меньшую модель сети.

Теперь транспорт, заголовки и конфигурация описывают одну известную цепочку. Следующий урок рассмотрит данные после завершения запроса: где они остаются, как связаны с копиями и что значит их удаление.