archived-doc-pt-br/security/errors.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- EN-Revision: ae725a44023db78b9f6e9d2a0baac8c8dc337d38 Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, fabioluciano -->
<!-- splitted from ./index.xml, last change in rev 1.66 -->
  <chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
   <title>Relatando Erros</title>
   <para>
    Com relação a segurança, relatório de erros é uma faca de dois gumes.
    Pode beneficiar o aumento da segurança, ou fornecer informação ao atacante.
   </para>
   <para>
    Uma tática padrão de ataque envolve determinar como um sistema funciona entrando
    dados incorretos e checando os tipos e contextos dos erros
    que são retornados. Isso permite que um cracker sonde
    por informações sobre o servidor, para determinar possíveis fraquezas.
    Por exemplo, se um atacantes tinha recolhido informação sobre uma página
    baseado em uma submissão de dados anterior, ele pode tentar sobrescrever
    variáveis, ou modificá-las:
    <example>
     <title>Atacando variáveis com uma página HTML personalizada</title>
     <programlisting role="html">
<![CDATA[
<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>
]]>
     </programlisting>
    </example>
   </para>
   <para>
    Os erros do PHP que são retornados normalmente podem ser úteis para
    um desenvolvedor que está tentando depurar um script, indicando coisas
    como a função ou arquivo que falhou, o arquivo PHP no qual a falha ocorreu,
    e o número da linha de código causadora da falha. Toda essa informação
    pode ser explorada. Não é incomum para um desenvolvedor PHP
    usar <function>show_source</function>,
    <function>highlight_string</function>, ou
    <function>highlight_file</function> como medidas de depuração, mas
    em um site de produção, isso pode expor variáveis ocultas, sintaxe incorreta,
    ou outra informações perigosas. Especialmente perigoso é rodar
    código de fontes conhecidas com tratadores de depuração integrados, ou usar
    técnicas de depuração comuns. Se o atacante pode determinar qual
    técnica geral você estiver usando, eles podem tentar, por força-bruta,
    enviar várias strings de depuração comuns para a página:
    <example>
     <title>Explorando variáveis comuns de depuração</title>
     <programlisting role="html">
<![CDATA[
<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="showerrors" value="1" />
<input type="hidden" name="debug" value="1" />
</form>
]]>
     </programlisting>
    </example>
   </para>
   <para>
    Independente do método de tratamento de erros, a habilidade de sondar um
    sistema por erros acaba dando informações úteis
    a um atacante.
   </para>
   <para>
    Por exemplo, o próprio estilo de um erro genérico do PHP indica que o sistema
    está rodando o PHP. Se o atacante estava procurando por uma página <literal>.html</literal>, e
    queria sondar qual o back-end (para procurar fraquezas conhecidas no
    sistema) enviando dados incorretos, ele pode ser capaz de
    determinar que um sistema foi feito com PHP.
   </para>
   <para>
    Uma função de erro pode indicar se o sistema pode está executando um
    engine de banco de dados específico, ou dar dicas de como uma página foi
    programada ou desenhada. Isso permite uma investigação profunda sobre
    portas abertas de bancos de dados, ou procurar por bugs específicos ou fraquezas
    de uma página. Enviando diferentes pedaços de dados ruins, por exemplo,
    um atacante pode determinar a ordem de autenticação em um script,
    (a partir da linha do erro) assim como sondar por exploits que
    podem ser aproveitados em diferentes partes do script.
   </para>
   <para>
    Um erro geral do PHP ou do sistema de arquivos indicam quais permissões
    o servidor web tem, assim como a estrutura e organização dos
    arquivos no servidor web. Códigos de erros escritos pelo desenvolvedor podem
    agravar o problema, levando à exploração fácil de informação até então
    "escondida".
   </para>
   <para>
    Existem três soluções principais para esse problema. A primeira é
    verificar exaustivamente todas as funções, e tentar compensar pelo volume dos
    erros. A segunda é desabilitar completamente os relatórios de erros
    no código de produção. A terceira é usar as funções personalizáveis
    de tratamento de erro do PHP para criar seu próprio tratador de erro.
    Dependendo da sua política de segurança, você pode perceber que todas são
    aplicáveis à sua situação.
   </para>
   <para>
    Uma maneira de perceber esse problema antes que o pior aconteça é usar
    a diretiva <function>error_reporting</function>, para ajudar a
    aumentar a segurança de seu código e achar uso de variáveis que pode ser perigoso.
    Ao testar o seu código, antes de colocar em produção, com <constant>E_ALL</constant>, você pode
    rapidamente encontrar áreas onde suas variáveis podem sofrer alterações nocivas
    ou modificações quaisquer. Uma vez que esteja pronto para produção,
    você deve ou desabilitar mensagens de erro completamente configurando a diretiva
    <function>error_reporting</function> com o valor 0, ou desligar o envio
    de erros usando a opção <literal>display_errors</literal> do arquivo &php.ini;,
    para evitar sondagem do seu código. Se você escolher a segunda opção,
    você deve também definir o caminho para o arquivo de registro usando a
    diretiva <literal>error_log</literal>, e ligar a diretiva
    <literal>log_errors</literal>.
    <example>
     <title>Encontrado variáveis perigosas com E_ALL</title>
     <programlisting role="php">
<![CDATA[
<?php
if ($username) { // Não inicializado ou verificado antes do uso
    $good_login = 1;
}
if ($good_login == 1) { // Se o teste acima falhar, não inicializado ou verificado antes do uso
    readfile ("/dados/altamente/sensiveis/index.html");
}
?>
]]>
     </programlisting>
    </example>
   </para>
  </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->