Under possible attacks, there are attacks on the php file themselves. Some php viruses, (injecktor and variations) scan the visible directory tree for php and/or html files, then inject code (such as spam-ware to generate fraudulent page hits) into otherwise harmless and useful .php scripts. One way to block this is by using open_basedir to restrict the visible file system directories to directory tree(s) which do NOT contain any .php scripts. (see doc page "Description of core php.ini directives" Note under open_basedir to tighten open_basedir scope from /www/ which would contain .php scripts to /www/tmp/ which would protect any scripts in /www/ from modification.) If the php.ini is outside the open_basedir tree, than a malware php script has no way to alter the core web site files, even if it were succesfully uploaded via ftp or other mechanism. The damage done by the spam-ware may seem trivial, but as browsers and virus programs eventually recognize the spam-ware the web site becomes effectively completely blocked and un-browsable.
Caso 1: apenas arquivos públicos são disponibilizados
Instalando como binário CGI
[edit] Last updated: Fri, 28 Jun 2013
Instalando como binário CGI
[edit] Last updated: Fri, 28 Jun 2013
Ataque Possível
Usando o PHP como binário CGI é uma opção de instalação que por alguma razão não deseja integrar o PHP como um módulo no servidor (como o Apache), ou usará o PHP com tipos diferentes de CGI wrappers para criar ambientes chroot e setuid seguros para os scripts. Esse tipo de instalação normalmente involve copiar o binário executável para o diretório cgi-bin do servidor web. CERT advisory » CA-96.11 recomenda não colocar qualquer interpretador nesse diretório. Mesmo se o binário do PHP pode ser usado como um interpretador autônomo, o PHP foi desenhado para previnir os ataques que essa forma de instalação torna possível:
- Acessar arquivos de sistema: http://my.host/cgi-bin/php?/etc/passwd A informação de consulta em uma URML depois da interrogração (?) é passada como argumentos de linha de comando para o interpretador pea interface CGI. Normalmente os interpretadores abrem e executam o arquivo especificado como primeiro argumento na linha de comando. Quando invocado como binárgio CGI, o PHP se recusa a interpretar os argumentos de linha de comando.
- Acessar qualquer domento web no servidor: http://my.host/cgi-bin/php/secret/doc.html A parte de informação de caminho da URL depois do nome do binário do PHP, /secret/doc.html é convencionalmente usada para especificar o nome do arquivo a ser aberto e interpretado pelo programa CGI Normalmente algumas diretivas de configuração do servidor web (Apache: Action) são usadas para redirecionar requisições para documentos como http://my.host/secret/script.php para o interpretados do PHP. Dessa maneira, o servidor web primeiro checa as permissões de acesso ao diretório /secret, e depois cria a requisição redirecionada http://my.host/cgi-bin/php/secret/script.php. Infelizmente, se a requisição é dada originalmente nessa forma, a checagem de permissão não é feita para o arquivo /secret/script.php, mas apenas para o arquivo /cgi-bin/php. Dessa maneira qualquer usuário que pode acessar /cgi-bin/php pode acessar quaisquer documentos protegidos no servidor web. No PHP, a opção de configuração em tempo de compilação --enable-force-cgi-redirect e as diretivas de configuração de tempo de execução doc_root e user_dir podem ser usadas para previnir esse ataque, se a árvore de documentos do servidor tiver qualquer diretório com restrições de acesso. Veja abaixo para uma explicação completa de combinações diferentes.
add a note
User Contributed Notes
Ataque Possível - [1 notes]
bill1 at nospam dot windhome dot com ¶
1 year ago