Os invasores podem duplicar deliberadamente os nomes das classes para fazer com que um programa execute um código mal-intencionado. Por esse motivo, os nomes das classes não são bons identificadores de tipo e não devem ser usados como base para conceder confiança a determinado objeto.

Exemplo 1: O código a seguir determina se a entrada de um objeto inputReader é confiável com base em seu nome de classe. Se um invasor puder fornecer uma implementação de inputReader que executa comandos mal-intencionados, esse código não poderá diferenciar as versões bem-intencionadas das mal-intencionadas do objeto.

if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
   input = inputReader.getInput();
   ...
}

A Especificação da Linguagem Java afirma que é uma boa prática um método finalize() chamar super.finalize() [1].

Exemplo 1: O seguinte método omite a chamada para super.finalize().

protected void finalize() {
  discardNative();
}

Esse campo foi anotado com FortifyNonNegative, que é usado para indicar que valores negativos não são permitidos.

No caso de PL/SQL, o valor NULL é indeterminado. Não será equivalente a nada, nem mesmo a um outro valor NULL. Além disso, um valor null nunca é equivalente a outro valor.

Exemplo 1: Esta instrução será sempre false.

checkNull BOOLEAN := x = NULL;

Exemplo 2: Esta instrução será sempre false.

checkNotNull BOOLEAN := x != NULL;

Esse programa usa == ou != para comparar a igualdade de duas strings, o que compara a igualdade de dois objetos, e não seus valores. São boas as chances de que as duas referências nunca serão iguais.

Exemplo 1: A seguinte ramificação nunca deve ser usada.

  if (args[0] == STRING_CONSTANT) {
      logger.info("miracle");
  }

Os operadores == e != apenas se comportarão conforme esperado quando forem usados para comparar strings contidas em objetos que são iguais. A maneira mais comum de isso acontecer é internalizando as strings, processo pelo qual elas são adicionadas a um pool de objetos mantidos pela classe String. Após a internalização de uma string, todas as suas aplicações usarão o mesmo objeto, e os operadores de igualdade terão o comportamento esperado. Todos os literais de string e constantes com valores de string são internalizados automaticamente. Outras strings podem ser internalizadas manualmente chamando String.intern(), o que retornará uma instância canônica da string atual, criando uma se necessário.

Depois que um thread sinaliza outros threads à espera de um mutex, ele deve desbloquear esse mutex chamando pthread_mutex_unlock() antes que a execução de outro thread possa começar. Se o thread de sinalização não conseguir desbloquear o mutex, a chamada pthread_cond_wait() no segundo thread não será retornada, e o thread não será executado.

Exemplo 1: O código a seguir sinaliza outro thread aguardando em um mutex chamando pthread_cond_signal(), mas não consegue desbloquear esse mutex no qual o outro thread está aguardando.

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

Esse campo foi anotado com FortifyNonZero, que é usado para indicar que zero não é um valor permitido.

Essa expressão sempre será nula, pois faz referência a um ponteiro de função, e não ao valor de retorno da função.

Exemplo 1: A seguir condição nunca será disparada. O predicado getChunk == NULL sempre será "false", pois getChunk é o nome de uma função definida no programa.

  if (getChunk == NULL)
    return ERR;

Como variáveis locais são alocadas na pilha, quando um programa retorna um ponteiro para uma variável local, ele está retornando um endereço de pilha. Uma chamada de função subsequente provavelmente reutilizará esse mesmo endereço de pilha, substituindo assim o valor do ponteiro, que já não corresponde à mesma variável uma vez que a estrutura de pilha de uma função é invalidada quando esta é retornada. Na melhor das hipóteses, isso fará com que o valor do ponteiro mude inesperadamente. Em muitos casos, isso faz com que o programa trave da próxima vez em que ocorrer a desreferência ao ponteiro. O problema pode ser difícil de depurar, pois a sua causa está muitas vezes bem distante do sintoma.

Exemplo 1: A função a seguir retorna um endereço de pilha.

char* getName() {
  char name[STR_MAX];
  fillInName(name);
  return name;
}

Métodos estáticos não podem ser substituídos por definição, uma vez que pertencem à classe e não a uma instância da classe. Mesmo assim, existem casos em que parece que um método estático foi substituído em uma subclasse, o que pode causar confusão e fazer com que uma versão incorreta do método seja chamada.

Exemplo 1: O exemplo a seguir tenta definir uma API para a autenticação de usuários.

class AccessLevel{
  public static final int ROOT = 0;
  //...
  public static final int NONE = 9;
}
//...
class User {
  private static int access;
  public User(){
    access = AccessLevel.ROOT;
  }
  public static int getAccessLevel(){
    return access;
  }
  //...
}
class RegularUser extends User {
  private static int access;
  public RegularUser(){
    access = AccessLevel.NONE;
  }
  public static int getAccessLevel(){
    return access;
  }
  public static void escalatePrivilege(){
    access = AccessLevel.ROOT;
  }
  //...
}
//...
class SecureArea {
  //...
  public static void doRestrictedOperation(User user){
    if (user instanceof RegularUser){
      if (user.getAccessLevel() == AccessLevel.ROOT){
        System.out.println("doing a privileged operation");
      }else{
        throw new RuntimeException();
      }
    }
  }
}

À primeira vista, esse código parece bom. No entanto, como estamos chamando o método getAccessLevel() em relação à instância user, e não contra as classes User ou RegularUser, isso significa que essa condição sempre retornará true e a operação restrita será realizada mesmo que instanceof tenha sido usado para entrar nessa parte do bloco if/else.

Integridade do código: Problemas de Assinatura de Método Serializável Incorreta ocorrem quando uma classe serializável cria uma função de serialização ou desserialização, mas não segue as assinaturas corretas:

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

O desvio de assinaturas de método exibidas pela serialização pode significar que o método nunca será chamado durante a serialização/desserialização, provocando serializações/desserializações incompletas, ou pode significar que um código não confiável pode obter acesso aos objetos.
No caso em que existem exceções não lançadas, isso pode significar que a serialização/desserialização falhará e travará o aplicativo ou que ela até mesmo pode falhar silenciosamente de forma que os objetos possam ser apenas parcialmente construídos corretamente, levando a falhas que podem ser extremamente difíceis de depurar. O chamador deve capturar essas exceções de forma que a serialização/desserialização incorreta possa ser tratada adequadamente sem travamentos ou objetos parcialmente construídos.

A Especificação de Serialização de Objeto Java permite que os desenvolvedores definam manualmente campos Serializáveis para uma classe especificando-os na matriz serialPersistentFields. Esse recurso somente funcionará se serialPersistentFields for declarado como private, static e final.

Exemplo 1: A seguinte declaração de serialPersistentFields não será usada para definir campos Serializable porque não é private, static e final.

class List implements Serializable {
public ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("myField", List.class) };
...
}

Chamar Object.equals() contra um array é um erro na maioria dos casos, pois isso verificará a igualdade dos endereços dos arrays, em vez da igualdade dos elementos dos arrays, e, em geral, deve ser substituído por java.util.Arrays.equals().

Exemplo 1: O exemplo a seguir tenta verificar dois arrays utilizando a função Object.equals().

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

Isso quase sempre resultará em um código que nunca é executado, a menos que, em algum momento, houver uma atribuição de um array ao outro.

Certas famílias de funções são implementadas como funções em algumas plataformas e como macros em outras. Se as funções dependerem de um recurso compartilhado que é mantido internamente em vez de ser transmitido quando elas são invocadas, essas funções deverão ser usadas no mesmo escopo de programa, caso contrário, o recurso compartilhado será inacessível.

Exemplo 1: O código a seguir usa pthread_cleanup_push() a fim de enviar a função routine para a pilha de limpeza do thread de chamada e, em seguida, é retornado. Como pthread_cleanup_push() e sua função parceira pthread_cleanup_pop() são implementadas como macros em plataformas diferentes do IBM AIX, a estrutura de dados criada por pthread_cleanup_push() não será acessível a chamadas subsequentes para pthread_cleanup_pop(). O código não conseguirá compilar ou apresentará um comportamento incorreto em tempo de execução em todas as plataformas nas quais essas funções são implementadas como macros.

void helper() {
   ...
   pthread_cleanup_push (routine, arg);
}

Não desaloque explicitamente a memória da pilha. Uma função que define um buffer de pilha desalocará automaticamente o buffer quando for retornada.
Exemplo 1:

void clean_up()
{
    char tmp[256];
    ...
    free(tmp);
    return;
}

A liberação explícita de memória pode corromper estruturas de dados de alocação de memória. Isso pode levar ao encerramento anormal do programa ou a maiores corrupções de dados.

O nome desse método é semelhante a um nome de método Java comum, mas está escrito incorretamente ou a lista de argumentos faz com que ele não substitua o método pretendido.

Exemplo 1: O método a seguir tem o objetivo de substituir Object.equals():

public boolean equals(Object obj1, Object obj2) {
  ...
}

Porém, como Object.equals() usa apenas um argumento, o método no Example 1 nunca é chamado.

O tempo de execução .NET permitirá a serialização de qualquer objeto que declare o atributo [Serializable]. Se a classe puder ser serializada usando os métodos de serialização padrão definidos pelo .NET Framework, será necessário e suficiente que o objeto seja serializado corretamente. Se a classe exigir métodos de serialização personalizados, ela também deverá implementar a interface ISerializable. No entanto, a classe ainda deve declarar o atributo [Serializable].

Exemplo 1: A classe CustomStorage implementa a interface ISerializable. No entanto, por não declarar o atributo [Serializable], ela não será serializada.

public class CustomStorage: ISerializable {
	...
}

Encaminhar um HttpServletRequest, redirecionar uma HttpServletResponse ou descarregar o fluxo de saída do servlet faz com que o fluxo associado seja confirmado. Quaisquer redefinições de buffer ou confirmações de fluxo subsequentes, como descarregamentos ou redirecionamentos adicionais, resultarão em IllegalStateExceptions.

Além disso, servlets Java permitem que dados sejam gravados no fluxo de resposta usando ServletOutputStream ou PrintWriter, mas não ambos. Chamar getWriter() depois de ter chamado getOutputStream(), ou vice-versa, também causará uma IllegalStateException.



Em tempo de execução, uma IllegalStateException impede que o manipulador de resposta seja executado até sua conclusão, eliminando eficientemente a resposta. Isso pode causar instabilidade no servidor, o que é um sinal de um servlet inadequadamente aplicado.

Exemplo 1: O código a seguir redireciona a resposta do servlet após o descarregamento do seu buffer de fluxo de saída.

public class RedirectServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        OutputStream out = res.getOutputStream();
        ...
        // flushes, and thereby commits, the output stream
        out.flush();
        out.close();        // redirecting the response causes an IllegalStateException
        res.sendRedirect("http://www.acme.com");
    }
}

Exemplo 2: Por outro lado, o código a seguir tenta gravar e descarregar o buffer de PrintWriter depois que a solicitação foi encaminhada.

public class FlushServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        // forwards the request, implicitly committing the stream
        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);
        ...

        // IllegalStateException; cannot redirect after forwarding
        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

        PrintWriter out = res.getWriter();

        // writing to an already-committed stream will not cause an exception,
        // but will not apply these changes to the final output, either
        out.print("Writing here does nothing");

        // IllegalStateException; cannot flush a response's buffer after forwarding the request
        out.flush();
        out.close();
    }
}

Na maioria dos casos, a configuração do cabeçalho Content-Length de um pedido indica que um programador está interessado na
comunicação do tamanho dos dados POST enviados ao servidor. No entanto, esse cabeçalho deverá ser 0 ou um
número inteiro positivo.

Exemplo 1: O código a seguir definirá um Content-Length incorreto.

  URL url = nova URL("http://www.exemplo.com");
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

A serialização de classes internas resulta na serialização da classe externa, o que pode deixar vazar informações ou provocar erros de tempo de execução se a classe externa não for serializável. Além disso, a serialização de classes internas pode causar dependências de plataforma, já que o compilador Java cria campos sintéticos para implementar classes internas, mas estas são dependentes da implementação e podem variar de um compilador para outro.

Exemplo 1: O código a seguir permite a serialização de uma classe interna.

  ...
  class User implements Serializable {
    private int accessLevel;
    class Registrator implements Serializable {
      ...
    }
  }

No Example 1, quando a classe interna Registrator for serializada, ela também serializará o campo accessLevel da classe externa User.