CGI e FastCGI: os fundamentos

Em resumo: O CGI (Common Gateway Interface) é uma interface antiga em que o servidor web inicia um programa novo para cada pedido, no caso do PHP o programa php-cgi. O FastCGI é a evolução: os processos PHP correm de forma permanente e aceitam muitos pedidos através de um socket. O PHP-FPM é a implementação FastCGI mais importante para o PHP. Relevantes para a segurança são sobretudo as definições cgi.* e a regra de que um acesso FastCGI nunca pode ser publicamente acessível.

O que é o CGI?

O CGI é um dos métodos mais antigos com que os servidores web geram conteúdos dinâmicos. O manual do PHP remete, na definição cgi.rfc2616_headers, para o RFC 3875, a especificação do Common Gateway Interface. Também os primórdios do PHP eram programas CGI: Rasmus Lerdorf escreveu em 1994 as primeiras «Personal Home Page Tools» como binários CGI em C.

O princípio: para cada pedido, o servidor web inicia um processo novo, passa os dados do pedido através de variáveis de ambiente e da entrada padrão e lê a resposta da saída padrão. Depois, o processo termina. Segundo o manual do PHP, no CGI e na CLI o PHP volta a ler o seu php.ini a cada chamada, nos módulos de servidor apenas no arranque.

Isto torna o CGI robusto, porque cada pedido começa com um processo novo. Mas também o torna lento: iniciar o processo, carregar a configuração e inicializar as extensões custam tempo a cada pedido.

O que é o FastCGI?

O FastCGI resolve o problema de desempenho mantendo os processos vivos. O servidor web liga-se, através de um socket Unix ou de uma porta TCP, a um processo em execução e envia-lhe o pedido no protocolo FastCGI. O processo trata-o e espera pelo seguinte.

Segundo o manual, o PHP-FPM é a implementação FastCGI principal do PHP. Complementa o protocolo com gestão de processos, pools, páginas de estado e um slowlog. Os pormenores estão em PHP-FPM explicado.

As definições cgi no php.ini

Para o funcionamento em CGI, o PHP conhece definições próprias. Os valores e descrições seguintes provêm do manual do PHP:

1. cgi.force_redirect (por defeito 1, INI_SYSTEM): segundo o manual, necessário para operar o PHP como CGI em segurança na maioria dos servidores web. Desligar apenas «por sua conta e risco»; no IIS tem de estar desligado.
2. cgi.fix_pathinfo (por defeito 1, INI_SYSTEM): assegura valores corretos de PATH_INFO e PATH_TRANSLATED. Os scripts devem usar SCRIPT_FILENAME em vez de PATH_TRANSLATED.
3. cgi.discard_path (por defeito 0, INI_SYSTEM): permite guardar o binário CGI em segurança fora da pasta web, sem que a proteção do .htaccess possa ser contornada.
4. fastcgi.impersonate (por defeito 0, INI_SYSTEM): relevante apenas para o IIS no Windows.
5. user_ini.filename e user_ini.cache_ttl (por defeito .user.ini e 300 segundos): controlam se e com que frequência o PHP lê ficheiros .user.ini.

No Nginx, faz parte disto uma passagem correta do caminho do script. Um modelo de base legível, sem garantia para todos os ambientes:

location ~ \.php$ {
    try_files $uri =404;               # só passar ao PHP ficheiros existentes
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

A linha try_files $uri =404; impede que pedidos para caminhos .php inexistentes sejam passados ao PHP.

Porque é que um acesso FastCGI aberto é perigoso

O manual do PHP avisa expressamente: quem consegue abrir uma ligação FastCGI ao PHP controla a configuração do pedido, por exemplo auto_prepend_file, e pode assim executar código arbitrário. A razão é que os servidores web podem enviar definições do PHP através de parâmetros FastCGI como PHP_VALUE e PHP_ADMIN_VALUE.

Daqui resultam regras claras:

• Ligar o PHP-FPM ou o php-cgi em modo FastCGI apenas através de um socket Unix, quando o servidor web corre no mesmo anfitrião.
• Com TCP, definir listen.allowed_clients e bloquear a porta na firewall; indicações no artigo Firewall para servidores web.
• Manter restritas as permissões do socket com listen.owner, listen.group e listen.mode.

CGI, FastCGI e PHP2Shell

O PHP2Shell afeta tanto o php-cgi como o PHP-FPM. Para ambos vale: atualização para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou um backport confirmado, e depois terminar e reiniciar todos os processos PHP em execução. Em configurações FastCGI com php-cgi, os processos muitas vezes continuam a correr sem darem nas vistas, porque nenhum serviço próprio os gere. Como encontrar e substituir este legado explica-o php-cgi: legado com risco. No Plesk, as variantes têm outros nomes; ajuda Plesk: compreender os handlers PHP.

Como ajuda concretamente a PHP SOS?

• Levantar os handlers: Apuramos se os seus sites correm via CGI, FastCGI com php-cgi ou PHP-FPM.
• Fechar acessos: Verificamos sockets, portas e regras de firewall, para que nenhum acesso FastCGI seja acessível a partir do exterior.
• Aplicar patches e limpar: Atualizamos o PHP e terminamos todos os processos antigos, também as instâncias órfãs do php-cgi.
• Substituir: No âmbito do reforço de servidores, substituímos o legado CGI por PHP-FPM com pools próprios.

Perguntas frequentes

Fontes

• Manual do PHP: definições do núcleo (cgi.*)
• Manual do PHP: ficheiros .user.ini
• Manual do PHP: configuração do FPM
• Documentação do Nginx