De forma predeterminada, los servidores de ASP.NET almacenan el objeto HttpSessionState, sus atributos y cualquier objeto al que hagan referencia en la memoria. Este modelo limita el estado de sesiones activas que puede alojar la memoria del sistema de un solo equipo. Para ampliar la capacidad más allá de estas limitaciones, los servidores se configuran con frecuencia para almacenar la información de estado de sesión, lo que permite ampliar la capacidad y efectuar la replicación entre varios equipos a fin de mejorar el rendimiento general. Para almacenar su estado de sesión, el servidor debe serializar el objeto HttpSessionState, para lo que es necesario que todos los objetos almacenados sean serializables.

Para poder serializar la sesión correctamente, todos los objetos que almacena la aplicación como atributos de sesión deben declarar el atributo [Serializable]. Además, si el objeto requiere métodos de serialización personalizados, también debe implementar la interfaz ISerializable.

Ejemplo 1: la siguiente clase se añade a sí misma a la sesión, pero como no es serializable, la sesión no se puede serializar correctamente.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

Si hay varios subprocesos intentando obtener el bloqueo de un recurso, llamar sleep() mientras se mantiene un bloqueo podría causar que todos los demás subprocesos esperen a que el recurso se libere, lo que podría dar lugar a un rendimiento degradado y un interbloqueo.

Ejemplo 1: el código siguiente llama sleep() mientras mantiene un bloqueo.

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

Un gran número de individuos con talento han dedicado mucho tiempo a sopesar formas de hacer funcionar el bloqueo de doble comprobación para mejorar el rendimiento. Ninguno de ellos lo ha logrado.

Ejemplo 1: a primera vista parece que el siguiente fragmento de código logra la protección de los subprocesos, al mismo tiempo que evita la sincronización innecesaria.

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

El programador desea garantiza que solo se asigne el objeto Fitzer(), pero no desea pagar el coste de la sincronización cada vez que se llame al código. A este giro se le conoce como bloqueo de doble comprobación.

Por desgracia, no funciona y se pueden asignar varios objetos Fitzer(). Consulte la declaración "El bloqueo de doble comprobación está roto" para obtener más información [1].

Después de que un subproceso señale otros a la espera de una exclusión mutua, este debe desbloquear la exclusión mutua llamando pthread_mutex_unlock() antes de que otro subproceso empiece a ejecutarse. Si el subproceso que señala no puede desbloquear la exclusión mutua, la llamada pthread_cond_wait() del segundo subproceso no volverá y el subproceso no se ejecutará.

Ejemplo 1: el código siguiente señala otro subproceso a la espera de una exclusión mutua llamando pthread_cond_signal(), pero no puede desbloquear la exclusión mutua en la que espera el otro subproceso.

   ...
   pthread_mutex_lock(&count_mutex);

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

Las aplicaciones requieren archivos temporales con tanta frecuencia que existen muchos mecanismos diferentes para crearlos en la biblioteca de C y la API de Windows(R). Muchas de estas funciones son vulnerables a diversas formas de ataques.
Ejemplo 1: El siguiente código utiliza un archivo temporal para almacenar datos intermedios recopilados de la red antes de procesarlos.

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

Este código que, por lo general, es bastante corriente, es vulnerable a una serie de distintos ataques debido a que utiliza un método poco seguro para crear archivos temporales. Las vulnerabilidades que presenta esta función y otras se describen en las siguientes secciones. Los problemas de seguridad más destacables relacionados con la creación de archivos temporales se han producido en sistemas operativos basados en Unix. No obstante, las aplicaciones de Windows presentan riesgos paralelos. Esta sección incluye un debate sobre la creación de archivos temporales tanto en los sistemas Unix como Windows.

Los métodos y los comportamientos pueden variar de un sistema a otro, pero los riesgos fundamentales planteados por cada uno de ellos son razonablemente constantes. Consulte la sección Recomendaciones para obtener información sobre las funciones seguras de lenguaje del núcleo y consejos en cuanto a un método seguro para crear archivos temporales.

Las funciones diseñadas para ayudar en la creación de archivos temporales se pueden dividir en dos grupos en función de si simplemente proporcionan un nombre de archivo o de si realmente abren un archivo.

Grupo 1 - Nombres de archivo "exclusivos":

El primer grupo de funciones de WinAPI y la biblioteca de C diseñado para ayudar en el proceso de creación de archivos temporales generando un nombre de archivo exclusivo para un nuevo archivo temporal, que se supone que el programa debe abrir a continuación. Este grupo incluye funciones de la biblioteca de C, como tmpnam(), tempnam(), mktemp() y sus equivalentes de C++ precedidos de un _ (carácter de subrayado), así como de la función GetTempFileName() de la API de Windows. Este grupo de funciones presenta una condición de carrera subyacente en relación con el nombre de archivo seleccionado. Aunque las funciones garantizan que el nombre de archivo es exclusivo en el momento de seleccionarlo, no hay ningún mecanismo que impida que otro proceso o un usuario malintencionado cree un archivo con el mismo nombre tras seleccionarlo, pero antes de que la aplicación intente abrirlo. Más allá del riesgo de conflicto legítimo provocado por otra llamada a la misma función, hay una alta probabilidad de que un usuario malintencionado pueda crear un conflicto malicioso debido a que los nombres de archivo generados por estas funciones no son lo suficientemente aleatorios para que sean difíciles de adivinar.

Si se crea un archivo con el nombre seleccionado, en función de cómo este se abra, el contenido o los permisos de acceso existentes del mismo permanecerán intactos. Si el contenido existente del archivo presenta una naturaleza maliciosa, es posible que un usuario malintencionado pueda introducir datos peligrosos en la aplicación cuando esta lea el archivo temporal. Si un usuario malintencionado crea previamente el archivo con permisos de acceso moderados, es posible que este pueda acceder a los datos que ha almacenado la aplicación en el archivo temporal, así como modificarlos o dañarlos. En los sistemas basados en Unix, se puede dar un ataque más insidioso si el usuario malintencionado crea previamente el archivo como vínculo a otro archivo importante. A continuación, si la aplicación se trunca o escribe datos en el archivo, puede realizar de forma inconsciente operaciones dañinas en nombre del usuario malintencionado. Resulta una amenaza especialmente grave si el programa funciona con permisos elevados.

Por último, en el mejor de los casos, el archivo se abrirá con una llamada a open() mediante los indicadores O_CREAT y O_EXCL, o a CreateFile() mediante el atributo CREATE_NEW, que presentará errores si el archivo ya existe y, por lo tanto, impide los tipos de ataques descritos anteriormente. Sin embargo, si un usuario malintencionado puede predecir con precisión una secuencia de nombres de archivo temporales, es posible que se impida que la aplicación abra el almacenamiento temporal necesario, lo que provocaría un ataque de denegación de servicio (DoS). Este tipo de ataque no sería difícil de implementar dado el reducido nivel de aleatoriedad empleado en la selección de los nombres de archivo generados por estas funciones.

Grupo 2 - Archivos "exclusivos":

El segundo grupo de funciones de la biblioteca de C intenta solucionar algunos de los problemas de seguridad relacionados con los archivos temporales, no solo generando un archivo exclusivo, sino abriéndolo. Este grupo incluye funciones de la biblioteca de C como, por ejemplo, tmpfile() y sus equivalentes de C++ precedidos de _ (carácter de subrayado), así como de una función de biblioteca C mkstemp() con un comportamiento más eficaz.

Las funciones del estilo tmpfile() crean un nombre de archivo exclusivo y abren el archivo del mismo modo que lo haría fopen() si transfiriese los indicadores "wb+", es decir, como un archivo binario en modo de lectura/escritura. Si el archivo ya existe, tmpfile() se truncará para establecer el tamaño cero, posiblemente en un intento por apaciguar las inquietudes de seguridad mencionadas anteriormente en cuanto a la condición de carrera que se produce entre la selección del nombre de archivo supuestamente exclusivo y la posterior apertura del archivo seleccionado. Sin embargo, este comportamiento no soluciona claramente los problemas de seguridad de la función. En primer lugar, un atacante puede crear previamente el archivo con permisos de acceso moderados que probablemente conservará el archivo abierto por tmpfile(). Además, en los sistemas basados en Unix, si el usuario malintencionado crea previamente el archivo como vínculo a otro archivo importante, la aplicación puede utilizar los permisos posiblemente elevados para truncar ese archivo, dañándolo en nombre del usuario malintencionado. Por último, si tmpfile() crea un nuevo archivo, los permisos de acceso aplicados al mismo variarán de un sistema operativo a otro, lo que puede dejar vulnerable la aplicación, incluso aunque el usuario malintencionado pueda predecir por adelantado el nombre de archivo que se va a usar.

Por último, mkstemp() supone un método razonablemente seguro para crear archivos temporales. Este intentará crear y abrir un archivo exclusivo basado en una plantilla de nombre de archivo proporcionada por el usuario, junto con una serie de caracteres generados aleatoriamente. Si no puede crear este archivo, presentará errores y devolverá -1. En los sistemas modernos, el archivo se abre mediante el modo 0600, lo que implica que el archivo se protegerá frente a su manipulación a menos que el usuario cambie de forma explícita los permisos de acceso. No obstante, mkstemp() aún presenta problemas en relación con el uso de nombres de archivo predecibles y puede dejar vulnerable una aplicación frente a ataques de denegación de servicio si un usuario malintencionado provoca que mkstemp() presente fallos mediante la predicción y la creación previa de los nombres de archivo que se van a utilizar.

Cuanto más tiempo permanezca una sesión abierta, más oportunidades tendrá un atacante para poner en peligros las cuentas de los usuarios. Durante el tiempo que una sesión permanece activa, un usuario malintencionado puede ser capaz de forzar el robo de la contraseña de un usuario, descifrar la clave de cifrado inalámbrico de un usuario o dirigir una sesión desde un explorador abierto. Los tiempos de expiración de sesión largos pueden, además, impedir que se libere memoria y que se produzca al final una denegación de servicio si se crea un número de sesiones suficientemente largo.

Ejemplo 1: el código del siguiente ejemplo establece un valor negativo para el intervalo inactivo máximo producido en una sesión que permanece activa indefinidamente.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

Nunca es recomendable que una aplicación web intente cerrar el contenedor de aplicaciones. Una llamada a un método de finalización es probablemente parte de un código de depuración sobrante o un código importado de una aplicación que no es de J2EE.

Una aplicación J2EE puede utilizar varios JVM a fin de mejorar la confiabilidad y el rendimiento de la aplicación. A fin de hacer que varios JVM aparezcan como una única aplicación para el usuario final, el contenedor J2EE puede replicar un objeto HttpSession entre varios JVM. De este modo, si un JVM deja de estar disponible otro puede intervenir y ocupar su lugar sin deteriorar el flujo de la aplicación.

Para que la replicación de sesión funcione, los valores que almacena a aplicación como atributos en la sesión deben implementar la interfaz Serializable.

Ejemplo 1: la clase siguiente se agrega a la sesión, pero como no es serializable, la sesión ya no puede replicarse.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

La administración de subprocesos en una aplicación web está prohibida por el estándar J2EE en algunas circunstancias y siempre es susceptible a errores. La administración de subprocesos es una tarea complicada y es muy probable que esta interfiera de forma impredecible en el comportamiento del contenedor de aplicaciones. Incluso aunque no interfiera en el contenedor, la administración de subprocesos suele provocar errores difíciles de detectar y diagnosticar, como interbloqueos, condiciones de carrera y otros errores de sincronización.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de método no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una condición, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: el siguiente fragmento de código ignora una condición de error que puede darse durante una transacción de CICS.

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

Si una transacción nunca hubiese fallado con esta condición de error, el programa debería seguir ejecutándose como si nada inusual hubiese ocurrido. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de método no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una excepción, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: El fragmento de código siguiente ignora una excepción iniciada en pocas ocasiones desde doExchange().

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

Si una RareException se fuese a iniciar en algún momento, el programa seguiría ejecutándose como si no hubiese ocurrido nada inusual. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de función no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una excepción, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: el siguiente código pasa por alto varias excepciones que se podrían producir al ejecutar la instrucción INSERT.

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

Se podría producir una excepción porque no existe la tabla, no se ha proporcionado un valor requerido o por alguna otra razón. Si se produce un error, no hay ninguna manera de saberlo porque el procedimiento no informa del error ni registra el tipo de error producido.

Si los bloques catch son varios, pueden volverse repetitivos, pero si se "condensan" bloques catch obteniendo una clase de alto nivel como Exception, se pueden ocultar excepciones que requieran un tratamiento especial o que no se deberían obtener en este punto del programa. Si se obtiene una excepción demasiado amplia, básicamente hace fracasar el propósito de las excepciones tipificadas de Java, y puede resultar particularmente peligroso si el programa se desarrolla y comienza a iniciar nuevos tipos de excepciones. Los nuevos tipos de excepciones quedarán desatendidas.

Ejemplo 1: El fragmento de código siguiente trata tres tipos de excepciones de manera idéntica.

  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);
  }

A primera vista, puede parecer preferible tratar estas excepciones en un solo bloque catch, de la siguiente forma:

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

No obstante, si se modifica doExchange() para iniciar un nuevo tipo de excepción que debería tratarse de forma diferente, el amplio bloque catch evitará que el compilador señale la situación. Es más, el nuevo bloque de filtrado ahora también administra las excepciones derivadas de RuntimeException como ClassCastException y NullPointerException, que no es el propósito del programador.

Declarar un método para lanzar Exception o Throwable dificulta a los autores de llamada hacer un buen trabajo en cuanto al tratamiento y la recuperación de errores. El mecanismo de excepciones de Java se ha configurado para facilitar a los autores de llamada la anticipación de qué puede salir mal y escribir código para administrar cada circunstancia de excepción específica. Declarar que un método lance una forma genérica de excepción frustra este sistema.

Ejemplo 1: El método siguiente lanza tres tipos de excepciones.

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

Aunque pueda parecer que es más organizado a la hora de escribir

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

al hacerlo se puede alterar la capacidad del autor de llamada para comprender y administrar las excepciones que se producen. Es más, si una revisión posterior de doExchange() introduce un nuevo tipo de excepción que debería tratarse de forma diferente a las excepciones anteriores, no hay una forma fácil de exigir este requisito.

Habitualmente, los programadores obtienen NullPointerException bajo tres circunstancias:

1. El programa contiene una anulación de referencia de puntero nulo. Obtener la excepción resultante era más sencillo que solucionar el problema subyacente.

2. El programa inicia de forma explícita una NullPointerException para señalar una condición de error.

3. El código es parte de un test de aprovechamiento que proporciona una entrada inesperada en las clases que se están probando.

De estas tres circunstancias, solo la última es aceptable.

Ejemplo 1: El código siguiente obtiene de forma errónea una NullPointerException.

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

Habitualmente, los programadores obtienen NullReferenceException bajo tres circunstancias:

1. El programa contiene una anulación de referencia de puntero nulo. Obtener la excepción resultante era más sencillo que solucionar el problema subyacente.

2. El programa inicia de forma explícita una NullReferenceException para señalar una condición de error.

3. El código es parte de un test de aprovechamiento que proporciona una entrada inesperada en las clases que se están probando.

De estas tres circunstancias, solo la última es aceptable.

Ejemplo 1: El código siguiente obtiene de forma errónea una NullReferenceException.

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

Una instrucción return dentro de un bloque finally provocará que todas las excepciones que se puedan lanzar en el bloque try se descarten.

Ejemplo 1: en la siguiente cita de código, la MagicException lanzada por la segunda llamada para doMagic con true transferido a ella nunca se entregará al autor de llamada. La instrucción return dentro del bloque finally provocará que la excepción se descarte.

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;
    }
  }
}

}

Los errores ThreadDeath solo deben filtrarse si una aplicación tiene que limpiar después de finalizar de forma asíncrona. Si se filtra un error ThreadDeath, es importante que se vuelva a lanzar para que el subproceso finalice realmente. El propósito de lanzar ThreadDeath es detener un subproceso. Si ThreadDeath es absorbido, puede impedir que un subproceso se detenga y dé lugar a un comportamiento inesperado, puesto que quien haya lanzado originalmente ThreadDeath espera que el subproceso se detenga.

Ejemplo 1: el código siguiente filtra ThreadDeath, pero no lo vuelve a lanzar.

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

En Java, los bloques finally siempre se ejecutan después de su bloque try-catch correspondiente y se utilizan frecuentemente para liberar recursos asignados, como controladores de archivos o cursores de base de datos. Lanzar una excepción en un bloque finally puede derivar el código de limpieza crítico, puesto que la ejecución normal del programa se interrumpirá.

Ejemplo 1: en el código siguiente, la llamada para stmt.close() se deriva cuando se lanza la FileNotFoundException.

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);
            }
        }
    }
}

Las vulnerabilidades de excepción no administradas se producen cuando:

1. Se arroja una excepción.

2. La excepción no se administra correctamente antes de que salga de la página actual.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta función no puede tener nunca errores" y "no importa si se produce un error en esta operación". Cuando un programador no puede detectar una excepción que puede arrojar una operación, implícitamente indica que está funcionando según uno de estos supuestos.