Quando a opção safe_mode está habilitada, a opção safe_mode_exec_dir impede que o PHP execute comandos apenas dos diretórios especificados. Embora a ausência da entrada safe_mode_exec_dir não represente por si só uma vulnerabilidade de segurança, essa complacência adicional pode ser explorada por invasores em conjunto com outras vulnerabilidades para tornar as explorações ainda mais perigosas.

Quando presente, a opção de configuração open_basedir tenta impedir que programas PHP operem em arquivos fora das árvores de diretórios especificadas em php.ini. Se o diretório de trabalho for especificado com ., isso poderá ser alterado por um invasor com o uso de chdir().

Embora a opção open_basedir seja uma vantagem geral para a segurança, a implementação é afetada por uma condição de corrida que pode permitir que os invasores se esquivem de suas restrições em algumas circunstâncias [2]. Existe uma condição de corrida TOCTOU (tempo de verificação/tempo de uso) entre o momento em que o PHP realiza a verificação de permissão de acesso e o momento em que o arquivo é aberto. Tal como acontece com condições de corrida no sistema de arquivos em outras linguagens, essa condição de corrida pode permitir que os invasores substituam um link simbólico para um arquivo, aprovado em uma verificação de controle de acesso, por outro para o qual o teste seria reprovado de outra forma, obtendo assim acesso ao arquivo protegido.

A janela de vulnerabilidade para um ataque como esse é o período de tempo entre o momento em que a verificação de acesso é realizada e o momento em que o arquivo é aberto. Mesmo que as chamadas sejam realizadas em estreita sucessão, os sistemas operacionais modernos não oferecem nenhuma garantia sobre a quantidade de código que será executada antes que o processo se alastre na CPU. Os invasores possuem várias técnicas para expandir a duração da janela de oportunidade a fim de facilitar as explorações, mas, mesmo com uma janela pequena, uma tentativa de exploração pode ser repetida simplesmente várias vezes até ser bem-sucedida.

Quando habilitada, a opção register_globals faz com que o PHP registre todas as variáveis EGPCS (Ambiente, GET, POST, Cookie e Servidor) em um nível global, em que elas podem ser acessadas em qualquer escopo de qualquer programa PHP. Essa opção incentiva os programadores a escrever programas mais ou menos inconscientes da origem dos valores dos quais eles dependem, o que pode provocar comportamentos inesperados em ambientes bem-intencionados e deixar as portas abertas para invasores em ambientes mal-intencionados. Reconhecendo as perigosas implicações de segurança de register_globals, essa opção foi desabilitada por padrão no PHP 4.2.0 e foi preterida e removida no PHP 6.

Exemplo 1: O código a seguir é vulnerável à criação de scripts entre sites. O programador supõe que o valor de $username origina-se da sessão controlada pelo servidor, mas, em vez disso, um invasor pode fornecer um valor mal-intencionado para $username como um parâmetro de solicitação. Com a opção register_globals habilitada, esse código incluirá um valor mal-intencionado enviado por um invasor no conteúdo HTML dinâmico que ele gera.

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

A opção safe_mode é um dos recursos de segurança mais importantes no PHP. Quando safe_mode está desabilitada, o PHP opera em arquivos com as permissões do usuário que a invocou, que muitas vezes é um usuário privilegiado. Embora a configuração do PHP com a opção safe_mode desabilitada por si só não introduza uma vulnerabilidade de segurança, essa complacência adicional pode ser explorada por invasores em conjunto com outras vulnerabilidades para tornar as explorações ainda mais perigosas.

Quando habilitada, a opção session.use_trans_sid faz com que o PHP transmita a ID de sessão na URL, tornando muito mais fácil para os invasores sequestrar sessões ativas ou enganar os usuários a usarem uma sessão existente que já está sob controle desses invasores.

Parâmetros transmitidos na URL são mais visíveis do que parâmetros POST e valores de cookies, pois aparecem frequentemente em históricos de navegador, marcadores, arquivos de log e outros locais altamente expostos. Se os invasores descobrirem o identificador da sessão secreto de uma sessão ativa em um sistema, eles poderão fornecer esse identificador de sessão de volta ao programa para sequestrar a sessão do usuário.

Além do sequestro de sessão, expor uma ID de sessão na URL também facilita ataques de fixação de sessão. Na exploração canônica de vulnerabilidades de fixação de sessão, o invasor cria uma nova sessão em um aplicativo Web e registra o identificador de sessão associado. Em seguida, o invasor faz com que a vítima se autentique no servidor usando esse identificador de sessão, o que dá a ele acesso à conta do usuário através da sessão ativa. Transmitir o identificador de sessão na URL permite que os invasores atinjam um grande número de vítimas potenciais, enviando a elas URLs que incluem um identificador de sessão comprometido por e-mail ou outro mecanismo de comunicação em massa.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas premissas duvidosas que são fáceis de detectar no código são "esta chamada de método jamais falha" e "não fará diferença se esta chamada falhar". Quando um programador ignora uma condição, ele declara implicitamente que está trabalhando sob uma dessas premissas.

Exemplo 1: O seguinte trecho de código ignora uma condição de erro que pode acontecer durante uma transação CICS.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

Se uma transação em algum momento falhasse com essa condição de erro, o programa continuaria a ser executado como se nada de anormal tivesse ocorrido. O programa não registra nenhuma evidência que indique a situação especial, possivelmente frustrando qualquer tentativa posterior de explicar o comportamento do programa.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas premissas duvidosas que são fáceis de detectar no código são "esta chamada de método jamais falha" e "não fará diferença se esta chamada falhar". Quando um programador ignora uma exceção, ele afirma implicitamente estar operando de acordo com uma dessas suposições.

Exemplo 1: O seguinte trecho de código ignora uma exceção raramente lançada de doExchange().

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

Se uma RareException tivesse que ser lançada alguma vez, o programa continuaria a ser executado como se nada incomum tivesse ocorrido. O programa não registra nenhuma evidência que indique a situação especial, possivelmente frustrando qualquer tentativa posterior de explicar o comportamento do programa.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Dois pressupostos duvidosos fáceis de detectar no código são "esta chamada de função nunca pode falhar" e "não importa se esta chamada falhar". Quando um programador ignora uma exceção, ele afirma implicitamente estar operando de acordo com uma dessas suposições.

Exemplo 1: Este código ignora várias exceções que podem ser lançadas durante a execução da instrução de inserção.

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

Uma exceção pode ser acionada porque a tabela não existe, um valor necessário não foi fornecido, ou por algum outro motivo. Se houver uma falha, não há nenhuma maneira de dizer, uma vez que o procedimento não a relatará ou registrará que tipo de falha ocorreu.

Vários blocos "catch" podem se tornar repetitivos, mas a "condensação" desses blocos por meio da captura de uma classe de alto nível, como Exception, pode obscurecer exceções que merecem tratamento especial ou que não devem ser detectadas a essa altura no programa. A captura uma exceção excessivamente ampla destrói em essência a finalidade de exceções de Java com tipo definido, podendo tornar-se um procedimento particularmente perigoso se o programa crescer e começar a lançar novos tipos de exceções. Os novos tipos de exceção não receberão nenhuma atenção.

Exemplo 1: O seguinte trecho de código lida com três tipos de exceções de modo idêntico.

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

À primeira vista, pode parecer preferível lidar com essas exceções em um único bloco "catch", da seguinte maneira:

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

No entanto, se doExchange() for modificado de forma a lançar um novo tipo de exceção que deve ser tratado de maneira diferente, o bloco "catch" amplo impedirá que o compilador aponte a situação. Além disso, o novo bloco "catch" também passará a lidar com exceções derivadas de RuntimeException, como ClassCastException e NullPointerException, o que não é a intenção do programador.

Declarar um método para lançar Exception ou Throwable dificulta o trabalho de tratamento de erros e recuperação por parte dos chamadores. O mecanismo de exceção do Java está configurado para facilitar a tarefa dos chamadores de antecipar o que pode dar errado e escrever um código para lidar com cada circunstância excepcional específica. Declarar que um método lança uma forma genérica de exceção derrota esse sistema.

Exemplo 1: O método a seguir lança três tipos de exceções.

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

Embora possa parecer mais apropriado escrever

public void doExchange()
  throws Exception {
  ...
}

isso dificulta a capacidade do chamador de compreender e lidar com as exceções que possam ocorrer. Além disso, se uma revisão posterior de doExchange() introduz um novo tipo de exceção que deve ser tratado de forma diferente do que exceções anteriores, não haverá nenhuma maneira simples de fazer cumprir essa exigência.

Em geral, os programadores capturam NullPointerException em três circunstâncias:

1. O programa contém um cancelamento de referência a ponteiro nulo. Capturar a exceção resultante foi mais fácil do que corrigir o problema subjacente.

2. O programa lança explicitamente uma NullPointerException para sinalizar uma condição de erro.

3. O código faz parte de um conjunto de teste que fornece entradas inesperadas para as classes sob teste.

Dessas três circunstâncias, somente a última é aceitável.

Exemplo 1: O seguinte código captura uma NullPointerException por engano.

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

Em geral, os programadores capturam NullReferenceException em três circunstâncias:

1. O programa contém um cancelamento de referência a ponteiro nulo. Capturar a exceção resultante foi mais fácil do que corrigir o problema subjacente.

2. O programa lança explicitamente uma NullReferenceException para sinalizar uma condição de erro.

3. O código faz parte de um conjunto de teste que fornece entradas inesperadas para as classes sob teste.

Dessas três circunstâncias, somente a última é aceitável.

Exemplo 1: O seguinte código captura uma NullReferenceException por engano.

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

Uma instrução de retorno dentro de um bloco finally fará com que qualquer exceção que possa ser lançada no bloco "try" seja descartada.

Exemplo 1: No seguinte trecho de código, a MagicException lançada pela segunda chamada para doMagic com true transmitido para ela nunca será entregue para o chamador. A instrução de retorno dentro do bloco finally fará com que a exceção seja descartada.

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

Erros de ThreadDeath só devem ser capturados se um aplicativos precisar de uma limpeza depois de ter sido finalizado de forma assíncrona. Se um erro ThreadDeath for capturado, é importante que ele seja novamente lançado para que o thread realmente seja desativado. O objetivo de lançar ThreadDeath é interromper um thread. Se ThreadDeath for engolido, ele poderá impedir que um thread seja interrompido e resultar em um comportamento inesperado, pois, quem quer que tenha lançado ThreadDeath originalmente, espera que o thread seja interrompido.

Exemplo 1: O código a seguir captura ThreadDeath, mas não volta a lançá-lo.

try
{
//some code
}
catch(ThreadDeath td)
{
//clean up code
}

Em Java, blocos finally são sempre executados depois de seus blocos try-catch correspondentes e são frequentemente utilizados para liberar recursos alocados, como identificadores de arquivos ou cursores de banco de dados. Lançar uma exceção em um bloco finally pode ignorar o código de limpeza crítico, pois a execução normal do programa será interrompida.

Exemplo 1: No código a seguir, a chamada para stmt.close() é ignorada quando a FileNotFoundException é lançada.

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

Vulnerabilidades de exceção sem tratamento ocorrem quando:

1. Uma exceção é lançada

2. A exceção não é devidamente tratada antes de escapar da página atual.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas premissas duvidosas que são fáceis de detectar no código são "essa operação nunca pode falhar" e "não importa se essa operação falhar". Quando os programadores não conseguem capturar uma exceção que uma operação pode lançar, eles afirmam implicitamente que estão operando segundo uma dessas premissas.

Vulnerabilidades de exceção SSL sem tratamento ocorrem quando:

1. Uma exceção específica de SSL é lançada.

2. A exceção não é explicitamente manipulada.

As exceções específicas de SSL javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLKeyException e javax.net.ssl.SSLPeerUnverifiedException transmitem erros importantes relacionados a uma conexão SSL. Se esses erros não forem tratados explicitamente, a conexão poderá ser deixada em um estado inesperado e potencialmente inseguro.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas premissas duvidosas que são fáceis de detectar no código são "essa operação nunca pode falhar" e "não importa se essa operação falhar". Quando os programadores não conseguem capturar uma exceção que uma operação pode lançar, eles afirmam implicitamente que estão operando segundo uma dessas premissas.

É uma boa prática de programação compartilhar um único objeto de agente de log entre todas as instâncias de uma classe particular e usar o mesmo agente de log durante o programa.

Exemplo 1: A seguinte instrução declara erroneamente um agente de log não estático.

private final Logger logger =
            Logger.getLogger(MyClass.class);

Boas práticas de registro em log determinam o uso de um único agente de log para cada classe.

Exemplo 1: O código a seguir declara incorretamente vários agentes de log.

public class MyClass {
  private final static Logger good =
            Logger.getLogger(MyClass.class);
  private final static Logger bad =
            Logger.getLogger(MyClass.class);
  private final static Logger ugly =
            Logger.getLogger(MyClass.class);
  ...
}

Exemplo 1: O primeiro programa Java que um desenvolvedor aprende a escrever é o seguinte:

public class MyClass
  ...
    System.out.println("hello world");
  ...
}

Embora a maioria dos programadores siga em frente e aprenda muitas nuances e sutilezas sobre o Java, um número surpreendente permanece nessa primeira lição e nunca desiste de escrever mensagens para a saída padrão utilizando System.out.println().

O problema é que escrever diretamente para a saída padrão ou erro padrão é frequentemente utilizado como uma forma não estruturada de registro. As instalações estruturadas de registro em log fornecem recursos como níveis de registro em log, formatação uniforme, um identificador de agente, carimbos de data/hora, e, talvez de maneira mais crítica, a capacidade de direcionar as mensagens de log ao lugar certo. Quando o uso de fluxos de saída do sistema é misturado com o código que utiliza agentes corretamente, o resultado é muitas vezes um log bem mantido ao qual faltam informações críticas.

Os desenvolvedores aceitam amplamente a necessidade por um registro em log estruturado, mas muitos continuam a usar fluxos de saída do sistema no desenvolvimento "pré-produção". Se o código que você está analisando já passou das fases iniciais de desenvolvimento, o uso de System.out ou System.err pode indicar um descuido na mudança para um sistema de registro em log estruturado.