Кратко

  • CGI/1.1 определил общий обмен запросами и ответами между HTTP-сервером и скриптом, оставив часть деталей на усмотрение системы или реализации.
  • RFC 3875 провёл границу TLS между клиентом и сервером: клиент аутентифицировал сервер, но скрипт не получал встроенного подтверждения того, кто его вызвал, и защиты целостности сообщений CGI.

Соединение защищено. Но приложение может находиться не на другом его конце.

Это незаметная граница в RFC 3875 — спецификации Common Gateway Interface (CGI) версии 1.1, опубликованной в 2004 году. Браузер может установить TLS-соединение с веб-сервером. Затем сервер передаёт данные запроса программе CGI. Но описанная в RFC модель безопасности не переносится через эту вторую передачу в неизменном виде. Сетевой узел — сервер; скрипт — прикладной процесс за ним.

CGI приносил практическую пользу задолго до RFC 3875. HTTP-сервер мог выступать шлюзом к базе данных или другой существующей информационной системе, а скрипт формировал ответ на запрос. Историческая страница CGI у W3C называет этот интерфейс соглашением между разработчиками серверов о подключении шлюзовых скриптов и программ. В ней отмечена попытка обновить CGI 1.1 в 1995 году и возобновление в ноябре 1997-го работы над тем, чтобы превратить фактический интерфейс в информационную RFC. Итоговый документ вышел в октябре 2004 года в рамках Independent Stream.

Этот промежуток важен не столько как история стандартизации, сколько как ключ к замыслу документа. CGI уже был рабочей практикой. RFC 3875 не изобрёл динамические веб-приложения; он зафиксировал переносимый договор о передаче запроса от сервера, обращённого к сети, прикладной программе.

Договор вводит «метапеременные» запроса: REQUEST_METHOD, QUERY_STRING, CONTENT_LENGTH, PATH_INFO, REMOTE_ADDR и другие. Он определяет, как скрипт возвращает заголовки и тело, включая документ и перенаправление. Программы на разных серверах получают общий словарь. Распределяются и обязанности: сервер управляет соединением с клиентом, передачей данных и сетевым протоколом; скрипт выполняет прикладные задачи, например обращается к данным и обрабатывает документы.

Такое разделение не снимает с сервера его обязательств. RFC 3875 говорит, что даже при несоответствии скрипта сервер остаётся ответственным перед клиентом за соблюдение сетевого протокола. Если сервер применяет аутентификацию, он также не должен запускать скрипт до прохождения запросом установленных проверок доступа. Сервер — не прозрачная труба, которая может переложить ответственность за неверный ответ или пропущенную проверку на дочерний процесс.

Затем раздел 9.4 уточняет границу доверия. Для TLS-соединения клиента модель безопасности действует между клиентом и сервером, а не между клиентом и скриптом. Клиенту аутентифицируется сервер. Спецификация не даёт скрипту механизма аутентификации сервера, который его вызвал, и не обеспечивает целостность сообщений CGI-запроса и ответа.

Это не означает, что скрипт нужно считать враждебным или что оператор не способен защитить локальную границу процесса. Сервер может использовать права ОС, отдельный канал или другие локальные меры. Более узкий вывод таков: TLS на HTTP-границе сам по себе не удостоверяет, что последующий скрипт — тот же аутентифицированный сетевой узел. Если скрипт получает HTTPS=on или имя пользователя в окружении, он получил значения; интерфейс CGI не передал криптографическое доказательство, связывающее их с аутентифицированным клиентским сеансом.

Архитектура не требовала единственной модели процесса. RFC 3875 называет наиболее распространённой реализацию с дочерним процессом от имени пользователя и группы сервера, но признаёт и скрипты, скомпонованные непосредственно с сервером. Документ различает поведение, «определяемое системой», и поведение, «определяемое реализацией». Общий интерфейс переносился между серверами, но переносимость имела пределы.

Документация Apache mod_cgi — пример реализации, а не перепись всего веба. Она показывает, как одно семейство серверов выбирает скрипты через обработчики или ScriptAlias и возвращает их вывод клиентам. Этот механизм помогает представить передачу, но не меняет тезис RFC о завершении TLS и не доказывает, как были настроены все серверы.

Историческое достижение CGI — общая граница, а не единый процесс или сквозной канал безопасности. Сервер и скрипт могли взаимодействовать через именованный интерфейс и при этом оставаться разными субъектами с разными обязанностями. Такое прочтение предотвращает ошибку категорий: защищённый запрос между браузером и сервером автоматически не превращается в защищённое отношение между браузером и приложением. RFC 3875 обозначил разделение, но не устранил его.

Источники