Manual do PHP
Anterior | Capítulo 16. Segurança | Próxima

# Instalado como binário CGI

## Possíveis ataques

Usando o PHP como um binário CGI é uma opção para configuração que por alguma razão não deseja integrar o PHP como módulo dentro de um programa de servidor (como o Apache), ou utilizará o PHP com CGI de diferentes tipos de roupagem para criar ambientes chroot e setuid seguros para scripts. Este setup geralmente envolve instalação do executável do PHP binário para o diretório cgi-bin do servidor web. CERT (Equipe de suporte a emergência de computadores) de consulta CA-96.11 é contra instalação de qualquer interpretador dentro do cgi-bin. Mesmo se o binário PHP pode ser usado como um interpretador em standalone (sozinho), o PHP é designado para prevenir os ataques que esta configuração é capaz:

- Acessando sistema de arquivos: `http://my.host/cgi-bin/php?/etc/passwd`

  A informação de query em uma url depois da interrogação (?) é como argumentos de linha de comando para o interpretador pela interface CGI. Normalmente interpretadores abrem e executam o arquivo especificado como o primeiro argumento na linha de comando.

  Quando invocado como um binário, o PHP recusa-se a interpretar os argumentos de linha de comando.

- Acessando qualquer documento do servidor web: `http://my.host/cgi-bin/php/secret/doc.html`

  A informação do caminho na parte da url após o nome do binário PHP, `/secret/doc.html` é convencionalmente usado para especificar o nome do arquivo para ser aberto e interpretado pelo programa CGI. Normalmente algumas diretivas de configuração de servidores (Apache: Action) são usadas para redirecionar pedidos para documentos como `http://my.host/secret/script.php` para o interpretador de PHP. Com este setup, o servidor primeiro checa as permissões de acesso aothe access permissions para o diretório `/secret`, e depois que cria o pedido redirecionado `http://my.host/cgi-bin/php/secret/script.php`. Desafortunadamente, se o pedido é originalmente feito desta forma, não são feitas checagens de acesso pelo servidor para o arquivo `/secret/script.php`, mas apenas para o arquivo `/cgi-bin/php`. Desta forma qualquer usuário está apto a acessar `/cgi-bin/php` está apto a acessar qualquer documento protegido dentro do servidor.

  No PHP, opção de configuração de compile-time (tempo de compilação) --enable-force-cgi-redirect e diretivas de configuração de tempo de execução doc_root e user_dir podem ser usadas para prevenir este ataque, se a árvore de documentos do servidor tem quaisquer diretórios com restrições de acesso. Veja abaixo para uma explicação completa de diferentes combinações.

## Caso 1: apenas arquivos públicos no servidor

Se seu servidor não tem qualquer conteúdo que não seja restrito por senha ou baseado em ip para controlar o acesso, não há necessidade ára estas opções de configuração. Se seu servidor não permite que você faça redirecionamentos, ou o servidor não uma forma de comunicar o binário PHP que a solicitação é um pedido de redirecionamento seguro, você pode especificar a opção --enable-force-cgi-redirect para o script de configuração. Você ainda tem que ter certeza que seu script PHP faça com que não dependa de uma ou outra forma de chamar de ser chamado, nenhum dos dois de modo direto `http://my.host/cgi-bin/php/dir/script.php` nem por redireção `http://my.host/dir/script.php`.

Redireção pode ser configurada no Apache usando AddHandler (adicionar manipulador) e diretivas de ação (veja abaixo).

## Caso 2: usando --enable-force-cgi-redirect

Esta opção de compilação evita de qualquer um chamar o PHP diretamente com uma url como `http://my.host/cgi-bin/php/secretdir/script.php`. Ao contrário, o php apenas analisa neste modo se ele atravessou uma regra de redirecionamento de um webserver.

Normalmente esta redireção na configuração do Apache é feita com as seguintes diretivas:

    Action php-script /cgi-bin/php
    AddHandler php-script .php

Esta opção foi testada apenas com o servidor Apache, e conta com o Apache para ajustar a variável de ambiente CGI non-standard (não-padrão) REDIRECT_STATUS em pedidos redirecionados. Se seu servidor não suporta nenhuma forma de descobrir se o pedido é direcionado ou redirecionado, você não pode usar esta opção e você deve usar umas das outras formas de executar a versão CGI documentada aqui.

## Caso 3: definindo doc_root ou user_dir

Para incluit conteúdo ativo, como scripts e executáveis, nos diretórios de documentos do servidor é considerada, às vezes uma prática insegura. Se, por causa de alguns erros de configuração, os scripts não são executados mas exibidos como documentod html normais, isto pode resultar em exibição de propriedades intelectuais e informações de segurança como senhas. Então alguns administradores de sistema irão preferir configurar outra estrutura de diretório para scripts que são acessíveis apenas por CGI PHP, então sempre interpretado e não é exibido como da outra forma.

Também se o método que verifica se o pedido não é redirecionado, como descrito na seção anterior, não está disponível, é necessário definir um doc_root de script que é diferente de um document root da web.

você pode definir o document root de script pela diretiva de configuração doc_root no arquivo de configuração, ou você pode definir a variável de ambiente PHP_DOCUMENT_ROOT. Se ela estiver definida, a versão CGI do PHP sempre construirá o nome do arquivo para abrir com este doc_root e a informação do caminho no pedido, então você pode que nenhum script será executado de fora deste diretório (exceto para user_dir abaixo).

Uma outra opção útil é user_dir. Quando user_dir não está definida, apenas uma coisa que tem o controle do nome de arquivo aberto é doc_root. Abrindo uma url como `http://my.host/~user/doc.php` não resulta em abertura de um arquivo de dentro do diretório home de usuários, mas um arquivo chamado `~user/doc.php` dentro de doc_root (sim, um nome de diretório começando com um til [~]).

Se user_dir está definido para, exemplo `public_php`, um pedido como `http://my.host/~user/doc.php` abrirá um arquivo chamado `doc.php` de dentro do diretório nomeado `public_php` de dentro do diretório do usuário. Se o home do usuário é `/home/user`, o arquivo executado é `/home/user/public_php/doc.php`.

A expansão de user_dir acontece apesar da configuração de doc_root, então você pode controlar o acesso de document root e diretório de usuário (user) separadamente.

## Caso 4: Analisador de PHP de fora da árvore web

Uma opção segura é colocar o analisador de PHP binário em algum lugar de fora da árvore de arquivos da web. Em `/usr/local/bin`, por exemplo. O único porém desta opção é que você agora terá que colocar uma linha similar a:

    #!/usr/local/bin/php

como a primeira linha de qualquer arquivo contendo tags de PHP. Você também precisará marcar o arquivo executável. Que é tratá-lo exatamente como você trataria um outro script CGI escrito em PERL ou SH ou qualquer outra linguagem comum que utiliza o mecanismo #! shell-escape para se auto-executar.

Obter o PHP para manipular a informação de PATH_INFO e PATH_TRANSLATED corretamente com este setup, o analisador de PHP seria compilado com a opção de configuração --enable-discard-path.

Anterior | Principal | Próxima
Segurança | Acima | Instalando como um módulo do Apache