Durante la deserialización, readObject() actúa como un constructor, por lo que la inicialización del objeto no se completa hasta que finaliza esta función. Así, cuando una función readObject() de una clase Serializable llama a una función que se puede sobrescribir, puede permitir que el método de sobrescritura acceda al estado del objeto antes de que se inicialice por completo.

Ejemplo 1: la siguiente función readObject() llama a un método que se puede sobrescribir.

  ...
  private void readObject(final ObjectInputStream ois) throws IOException, ClassNotFoundException {
    checkStream(ois);
    ois.defaultReadObject();
  }

  public void checkStream(ObjectInputStream stream){
    ...
  }

Como la función checkStream() y su clase envolvente no son final y públicas, la función se puede sobrescribir y un atacante puede sobrescribir la función checkStream() para tener acceso al objeto durante la deserialización.

Devolver una variable de lista private readonly desde una propiedad de solo getter permite que el código de llamada modifique el contenido de la lista, lo cual proporciona a la lista acceso de escritura y contradice las intenciones del programador que la hizo private readonly.

Ejemplo 1: el siguiente código contiene una lista _item declarada como private readonly.

       class Order
      {
          private readonly List<string> _item = new List<string>();
          public IEnumerable<string> Item { get { return _item; } }
          
          public Order()
          {
              /*class initialize            */
          }

          /*some important function......*/
      }
    

Un ataque de reentrada ocurre cuando un contrato malicioso vuelve a llamar al contrato de llamada antes de que finalice la primera invocación. Esto sucede cuando el contrato vulnerable expone una función que interactúa con contratos externos antes de llevar a cabo localmente el efecto de la llamada actual. Esto puede llevar a que el contrato externo asuma el flujo de control de la interacción.

Si un contrato malicioso llama a la función expuesta de una víctima que interacciona de manera insegura con el contrato de llamada, el contrato atacante recibirá y procesará la interacción (por ejemplo, a través de una función alternativa) e inmediatamente volverá a llamar a la función expuesta de la víctima para entrar en un bucle de llamada-interacción-llamada. Este estado recursivo evita que se ejecute más código en la víctima y puede provocar un drenaje parcial o total de activos o valores dependiendo de la naturaleza de la interacción.

El patrón comprobaciones-efectos-interacción se usa comúnmente en contratos inteligentes para evitar una lógica incorrecta. El patrón designa que el código compruebe primero las condiciones requeridas, luego lleve a cabo el cambio de estado relacionado (el efecto) y finalmente interactúe con el contrato externo en relación con ese efecto.

Ejemplo 1: El siguiente ejemplo permite un ataque de reentrada realizando una comprobación, una interacción y luego un efecto sin seguir el patrón comprobaciones-efectos-interacción.

El código:

1. Comprueba el saldo del remitente (Comprobaciones).
2. Envía Ether a la persona que llama a través de msg.sender.call.value (Interacción).
3. Realiza un cambio de estado disminuyendo el saldo del remitente (Efectos).

function withdraw(uint amount) public{
    if (credit[msg.sender] >= amount) {
        require(msg.sender.call.value(amount)());
        credit[msg.sender]-=amount;
    }
}

El código en el Example 1 rompe el patrón comprobaciones-efectos-interacción haciendo comprobaciones-interacción-efectos en su lugar. Esto puede conducir a una reentrada si un contrato inteligente atacante recibe Ether en una función alternativa e inmediatamente vuelve a llamar a withdraw, creando una situación recursiva en la que Ether se agota porque la línea de código que disminuye el saldo (también conocida como el efecto) nunca se ejecuta.

El uso de la recursividad es un elemento básico para crear y administrar estructuras de datos vinculados. La recursividad también corre el riesgo de procesarse indefinidamente si los datos incorporan un enlace circular, que a su vez agotará la pila y bloqueará el programa.

Ejemplo 1: El siguiente fragmento de código demuestra esta vulnerabilidad con Apache Log4j2.

Marker child = MarkerManager.getMarker("child");
Marker parent = MarkerManager.getMarker("parent");

child.addParents(parent);
parent.addParents(child); 
        
String toInfinity = child.toString();

Cuando el elemento secundario llama a toString(), que incluye un método de procesamiento recursivo, desencadena una excepción de desbordamiento de pila (agotamiento de pila). Esta excepción se produce debido al enlace circular entre elemento secundario y elemento principal.

Para comparar un valor de punto flotante con un objeto String, es necesario cambiarlo primero por un objeto String, por lo general, mediante una función como Double.toString(). En función de la forma y el valor de la variable de punto flotante, al convertirla en un objeto String, puede ser "NaN", "Infinity" o "-Infinity", incluir alguna cantidad de decimales finales con ceros o contener un campo de exponente. Si se convierte en una cadena hexadecimal, la representación también podría diferir en gran medida.

Ejemplo 1: el siguiente ejemplo compara una variable de punto flotante con una String.

  ...
  int initialNum = 1;
  ...
  String resultString = Double.valueOf(initialNum/10000.0).toString();
  if (s.equals("0.0001")){
    //do something
    ...
  }
  ...

Base de datos SQL de Windows Azure solo admite la autenticación de SQL Server. No se admite autenticación de Windows (seguridad integrada). Los usuarios deben proporcionar credenciales (nombre de usuario y contraseña) cada vez que se conecten a Base de datos SQL de Windows Azure. Según las directrices y limitaciones generales de Base de datos SQL de Microsoft Windows Azure, no están disponibles los siguientes nombres de cuentas: admin, administrador, invitado, raíz, sa.

El código adyacente imposibilita la ejecución de esta instrucción.

Ejemplo: es imposible cumplir la condición para la segunda instrucción if. Exige que la variable s sea no nula, mientras que en la única ruta de acceso en la que a s se le puede asignar un valor no nulo hay una instrucción return.

String s = null;

if (b) {
   s = "Yes";
   return;
}

if (s != null) {
   Dead();
}