Resumo

  • CGI/1.1 definiu uma passagem comum de requisição e resposta entre servidor HTTP e script, embora alguns detalhes continuassem definidos pelo sistema ou pela implementação.
  • A RFC 3875 situou o TLS entre cliente e servidor: o servidor era autenticado perante o cliente, enquanto o script não recebia prova incorporada de quem o invocou nem integridade garantida para a mensagem CGI.

A conexão é segura. O aplicativo talvez não esteja na outra ponta.

Esse é o limite discreto da RFC 3875, a especificação Common Gateway Interface (CGI) versão 1.1, publicada em 2004. Um navegador pode estabelecer TLS com um servidor web. Depois, o servidor pode repassar os dados da requisição a um programa CGI. Mas a relação de segurança descrita pela RFC não atravessa intacta essa segunda passagem. O servidor é o par de rede; o script é um processo de aplicação atrás dele.

O CGI já fazia um trabalho útil muito antes da RFC 3875. Um servidor HTTP podia atuar como gateway para um banco de dados ou outro sistema de informação existente, enquanto um script produzia a resposta a partir da requisição. A página histórica do W3C descreve o CGI como um acordo entre implementadores de servidores para integrar scripts e programas de gateway. Ela registra uma tentativa de atualizar o CGI 1.1 em 1995 e a retomada, em novembro de 1997, de um esforço para transformar uma interface de fato em uma RFC Informational. O documento final saiu em outubro de 2004 pelo Independent Stream.

O intervalo importa menos como curiosidade sobre o processo de padrões do que como pista sobre o que o texto queria registrar. O CGI já era uma convenção prática. A RFC 3875 não inventou aplicações web dinâmicas; colocou por escrito um contrato portável para uma requisição que precisava passar de um servidor exposto à rede a um programa de aplicação.

O contrato nomeia “metavariáveis” como REQUEST_METHOD, QUERY_STRING, CONTENT_LENGTH, PATH_INFO e REMOTE_ADDR. Define como o script devolve cabeçalhos e corpo, inclusive respostas de documento e redirecionamento. Programas executados por servidores diferentes passam a ter um vocabulário comum. As responsabilidades também ficam divididas: o servidor cuida da conexão com o cliente, da transferência de dados e do protocolo de rede; o script trata do trabalho da aplicação, como acesso a dados e processamento de documentos.

Essa divisão não transfere as obrigações do servidor. A RFC 3875 afirma que, mesmo se um script não estiver em conformidade, o servidor continua responsável perante o cliente por cumprir o protocolo de rede. Se aplicar autenticação, o servidor também não pode executar o script antes de a requisição passar pelos controles de acesso definidos. O servidor não é um tubo transparente que possa culpar o processo filho por uma resposta inválida ou por uma verificação omitida.

A seção 9.4 delimita então a fronteira de confiança. Em uma conexão TLS, o modelo de segurança se aplica entre cliente e servidor, não entre cliente e script. O servidor é autenticado perante o cliente. A especificação não oferece ao script um mecanismo para autenticar o servidor que o invocou e não impõe integridade às mensagens CGI de requisição e resposta.

Isso não significa que o script tenha de ser considerado hostil, nem que o operador não possa proteger o processo local. O servidor pode usar permissões do sistema operacional, um canal privado ou outros controles locais. O ponto mais restrito é que o TLS na borda HTTP, por si só, não autentica o script posterior como se ele fosse o mesmo par de rede. Se o script recebe HTTPS=on ou um nome de usuário no ambiente, recebe valores; a interface CGI não entrega uma prova criptográfica que vincule esses valores a uma sessão de cliente autenticada.

A arquitetura não se limitava a um modelo de processo. A RFC 3875 descreve como implementação mais comum um processo filho executado sob o usuário e o grupo do servidor, mas também reconhece scripts vinculados ao próprio servidor. Distingue comportamentos “definidos pelo sistema” e “definidos pela implementação”. A interface comum podia atravessar servidores, mas essa portabilidade tinha limites.

A documentação do mod_cgi do Apache é um exemplo de implementação, não um levantamento de toda a web. Ela mostra uma família de servidores selecionando scripts por handlers ou ScriptAlias e devolvendo sua saída aos clientes. Esse mecanismo ajuda a visualizar a passagem, mas não muda a afirmação da RFC sobre onde o TLS termina nem prova como todos os servidores eram configurados.

A conquista histórica do CGI foi uma fronteira compartilhada, não um processo comum nem um canal de segurança de ponta a ponta. Servidor e script podiam cooperar por uma interface nomeada e ainda assim permanecer principais distintos, com responsabilidades diferentes. Ler a RFC dessa forma evita um erro de categoria: uma requisição protegida entre navegador e servidor não se converte automaticamente em uma relação protegida entre navegador e aplicação. A RFC 3875 tornou a separação explícita; não a desfez.

Fontes