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: 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.

Los valores asociados con block.timestamp o block.number suelen ser usados por los desarrolladores para activar eventos dependientes del tiempo; sin embargo, estos valores a menudo dan una sensación de tiempo que no es seguro usar.

Debido a la naturaleza descentralizada de blockchain, los nodos pueden sincronizar el tiempo solo hasta cierto punto. En el mejor de los casos, usar block.timestamp no es fiable y, en el peor, los mineros maliciosos pueden alterar la marca de tiempo de sus bloques si ven una ventaja en hacerlo.

En cuanto a block.number, aunque es posible predecir el tiempo entre bloques (aproximadamente 14 segundos), los tiempos de los bloques no son constantes y pueden variar dependiendo de la actividad de la red. Esto hace que block.number no sea fiable para los cálculos relacionados con el tiempo.

Ejemplo 1: El siguiente código utiliza block.number para desbloquear fondos después de un cierto período de tiempo.

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}

Node.js permite a los desarrolladores asignar devoluciones de llamada a eventos bloqueados de E/S. Esto permite una mejora del rendimiento, ya que las devoluciones de llamada se ejecutan de forma asíncrona de manera que la E/S no bloquee la aplicación. Sin embargo, esto a su vez puede dar lugar a condiciones de carrera cuando algo fuera de la devolución de llamada dependa de que se ejecute primero código que se encuentra dentro de la devolución de llamada.

Ejemplo 1: el siguiente código contrasta la información de un usuario con una base de datos para su autenticación.

 
...
var authenticated = true; 
...
database_connect.query('SELECT * FROM users WHERE name == ? AND password = ? LIMIT 1', userNameFromUser, passwordFromUser, function(err, results){
  if (!err && results.length > 0){
    authenticated = true;
  }else{
    authenticated = false;
  }
});

if (authenticated){
  //do something privileged stuff
  authenticatedActions();
}else{
  sendUnathenticatedMessage();
}

En este ejemplo, supondremos que estamos llamando a una base de datos de back-end para confirmar las credenciales de un usuario para iniciar sesión y, si se confirman, definiremos una variable como true; en caso contrario, como false. Desafortunadamente, como hay E/S que bloquea la devolución de llamada, esta se ejecutará de forma asíncrona y puede que se ejecute después de la comprobación if (authenticated), y como el valor predeterminado era true, irá en la instrucción if tanto si el usuario se ha autenticado realmente como si no.

La aplicación instala un formulario de aplicación desde el almacenamiento compartido en el que puede escribir cualquier aplicación con permisos de lectura/escritura de almacenamiento externo. Debido a una condición de carrera, la aplicación maliciosa que supervise la carpeta podrá cambiar un archivo APK descargado por otro archivo APK, el cual se usará en el proceso de instalación en lugar del archivo legítimo.

Ejemplo 1: El código siguiente instala aplicaciones desde el almacenamiento compartido:

    Intent intent = new Intent(Intent.ACTION_VIEW);
    intent.setDataAndType(Uri.fromFile(new File(Environment.getExternalStorageDirectory() + "/download/" + "app.apk")), "application/vnd.android.package-archive");
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);

Las condiciones de carrera de acceso a archivos, conocidas como condiciones de carrera de momento de comprobación y momento de uso (TOCTOU, por sus siglas en inglés) se producen cuando:

1. El programa comprueba una propiedad de un archivo, haciendo referencia a este por el nombre.

2. A continuación el programa realiza una operación de sistema del archivo utilizando el mismo nombre de archivo y asume que la propiedad que ya se comprobó anteriormente no ha cambiado.
Ejemplo 1: El siguiente código procede de un programa instalado setuid root. El programa realiza ciertas operaciones de archivo en nombre de usuarios no privilegiados, y usa comprobaciones de acceso para asegurar que este no usa sus privilegios origen para realizar operaciones que no deberían estar disponibles para el usuario actual. El programa utiliza la llamada al sistema access() para comprobar si la persona que está ejecutando el programa tiene permiso para acceder al archivo especificado antes de que abra el archivo y realiza las operaciones necesarias.

  if (!access(file,W_OK)) {
    f = fopen(file,"w+");
    operate(f);
    ...
  }
  else {
    fprintf(stderr,"Unable to open file %s.\n",file);
  }

La llamada a access() presenta el comportamiento previsto y devuelve 0 si el usuario que ejecuta el programa dispone de los permisos necesarios para escribir en el archivo y, de no ser así, devuelve -1. Sin embargo, debido a que tanto access() como fopen() realizan operaciones en los nombres de archivo en lugar de en los identificadores de archivo, no hay ninguna garantía de que la variable file aún haga referencia al mismo archivo en el disco al transferirlo a fopen() que cuando se transfirió a access(). Si un usuario malintencionado sustituye file tras la llamada a access() por un vínculo simbólico a un archivo diferente, el programa utilizará sus privilegios raíz para realizar operaciones en el archivo, aunque se trate de un archivo que, de lo contrario, el usuario no podría modificar. Al engañar al programa para que realice una operación que, de lo contrario, no sería permisible, el usuario malintencionado ha obtenido privilegios elevados.

Este tipo de vulnerabilidad no se limita a programas con privilegios root. Si la aplicación es capaz de realizar cualquier operación que el usuario malintencionado no tendría permiso para realizar, se trata de un posible objetivo.

La ventana de vulnerabilidad para un ataque de esta naturaleza se da en el período de tiempo entre cuando una propiedad de archivo se comprueba y cuando el archivo se usa. Incluso si el uso se produce inmediatamente después de la comprobación, los sistemas de operación modernos no garantizan la cantidad de código que se ejecuta antes de que el proceso abandona la CPU. Los atacantes disponen de una amplia variedad de técnicas para expandir la longitud de la ventana de oportunidad para que sea más fácil de explotar. Sin embargo, incluso con una ventana pequeña, un intento de ataque puede repetirse una y otra vez hasta que tiene éxito.

Ejemplo 2: el siguiente código crea un archivo y, a continuación, cambia el propietario del mismo.

    fd = creat(FILE, 0644);  /* Create file */
    if (fd == -1)
        return;
    if (chown(FILE, UID, -1) < 0) {  /* Change file owner */
      ...
    }

Este código presupone que el archivo utilizado por la llamada a chown() es el mismo que el archivo creado por la llamada a creat(), pero esto no siempre es así. Como chown() funciona en un nombre de archivo y no en un identificador de archivo, un atacante podría ser capaz de reemplazar el archivo con un vínculo a un archivo que no posee el atacante. La llamada a chown() proporcionaría así al atacante la propiedad del archivo vinculado.

Los métodos parse() y format() de java.text.Format contienen una condición de carrera que puede ocasionar que un usuario vea los datos de otro usuario.

Ejemplo 1: El código siguiente muestra cómo se puede manifestar el error de diseño.

public class Common {

    private static SimpleDateFormat dateFormat;
    ...

    public String format(Date date) {
        return dateFormat.format(date);
    }
    ...

    final OtherClass dateFormatAccess=new OtherClass();
    ...

    public void function_running_in_thread1(){
        System.out.println("Time in thread 1 should be 12/31/69 4:00 PM, found: "+ dateFormatAccess.format(new Date(0)));
    }

    public void function_running_in_thread2(){
        System.out.println("Time in thread 2 should be around 12/29/09 6:26 AM, found: "+ dateFormatAccess.format(new Date(System.currentTimeMillis())));
    }
}

Mientras que este código se comporta correctamente en un entorno de usuario único, si dos subprocesos se ejecutan a la vez podrían producir la salida siguiente:

La hora en el subproceso 1 debería ser 31/12/69 4:00 PM, encontrado: 31/12/69 4:00 PM
La hora en el subproceso 2 debería ser 12/29/09 6:26 AM, encontrado: 31/12/69 4:00 PM

En este caso, la fecha desde el primer subproceso se muestra en la salida desde el segundo subproceso debido a una condición de carrera en la implementación de format().

Las propiedades RoamingFolder y RoamingSettings obtienen un contenedor en el almacén de datos de aplicaciones de movilidad, que luego se puede usar para compartir datos entre dos o varios dispositivos. Al escribir y leer los objetos almacenados en el almacén de datos de aplicaciones de movilidad, el desarrollador aumenta los riesgos. Estos abarcan la confidencialidad, la integridad y la disponibilidad de los datos, las aplicaciones y los sistemas que comparten esos objetos a través de dicho almacén.

Los desarrolladores deben abstenerse de usar esta funcionalidad sin implementar primero los controles técnicos necesarios.

Las condiciones de carrera de los identificadores de señales pueden producirse siempre que una función instalada como identificador de señales no sea reentrante, es decir, mantiene parte del estado interno o llama otra función para que lo haga. Es incluso más probable que se produzcan dichas condiciones de carrera cuando la misma función se instala para identificar varias señales.

Es más probable que se produzcan las condiciones de carrera del identificador de señales cuando:

1. El programa instala un solo identificador de señales para más de una señal.

2. Dos señales diferentes para las que se ha instalado el identificador llegan en una corta sucesión, provocando una condición de carrera en el identificador de señales.

Ejemplo: el código siguiente instala el mismo identificador de señales simple y no reentrante para dos señales diferentes. Si un atacante hace que las señales se envíen en los momentos precisos, el identificador de señales experimentará una vulnerabilidad doble y libre. Al llamar a free() dos veces con el mismo valor, se puede producir un buffer overflow. Si un programa llama a free() dos veces con el mismo argumento, las estructuras de datos de administración de memoria del programa se dañan. Esto puede provocar que el programa se bloquee o, en algunas circunstancias, que se realicen dos llamadas posteriores a malloc() para devolver la misma referencia. Si malloc() devuelve el mismo valor dos veces y el programa concede posteriormente al usuario malintencionado control de los datos escritos en la memoria que se ha asignado dos veces, el programa será vulnerable a un ataque de buffer overflow.

void sh(int dummy) {
  ...
  free(global2);
  free(global1);
  ...
}

int main(int argc,char* argv[]) {
  ...
  signal(SIGHUP,sh);
  signal(SIGTERM,sh);
  ...
}

Muchos desarrolladores de servlet no entienden que un servlet es un singleton. Hay una instancia del servlet, que se utiliza y reutiliza para administrar varias solicitudes que diferentes subprocesos procesan simultáneamente.

Un resultado habitual de esta confusión es que los desarrolladores usan campos miembros de servlet de forma que un usuario podría ver accidentalmente los datos de otro usuario. Es decir, al almacenar datos de usuarios en los campos miembros de servlet se introduce una condición de carrera de acceso de datos.

Ejemplo 1: el siguiente servlet almacena el valor de un parámetro de solicitud en un campo miembro y, a continuación, repite el valor del parámetro en el flujo de salida de respuesta.

public class GuestBook extends HttpServlet {

   String name;

   protected void doPost (HttpServletRequest req, HttpServletResponse res) {
     name = req.getParameter("name");
     ...
     out.println(name + ", thanks for visiting!");
   }
}

Aunque este código funciona a la perfección en un entorno de usuario único, si dos usuarios acceden al servlet más o menos a la vez, es posible que los dos subprocesos de controladores de solicitudes se intercalen de la forma siguiente:

Subproceso 1: asigne "Dick" a name
Subproceso 2: asigne "Jane" a name
Subproceso 1: imprime "Jane, thanks for visiting!"
Subproceso 2: imprime "Jane, thanks for visiting!"

De este modo, se muestra al primer usuario el nombre del segundo usuario.

Un objeto de recurso transaccional, como una conexión de base de datos, solo puede asociarse con las transacciones de una en una. Por este motivo, los subprocesos no deben compartir una conexión, ni esta debe almacenarse en un campo estático. Consulte la Sección 4.2.3 de la especificación J2EE para obtener más información.

Ejemplo 1:

public class ConnectionManager {

private static Connection conn = initDbConn();
...
}

Las vulnerabilidades de fijación de sesión se producen cuando:

1. Una aplicación web autentica a un usuario sin invalidar antes la sesión existente, por lo que se sigue usando la sesión que ya está asociada al usuario.
2. Un atacante puede forzar un identificador de sesión conocido en un usuario para que, una vez que este se autentique, el atacante tenga acceso a la sesión autenticada.

En la explotación genérica de las vulnerabilidades de fijación de sesión, un atacante crea una nueva sesión en una aplicación web y registra el identificador de sesión asociado. A continuación, el atacante hace que la víctima se autentique en el servidor con ese identificador de sesión, con lo que el atacante obtiene acceso a la cuenta del usuario a través de la sesión activa.

Algunos marcos de trabajo, como Spring Security, invalidan automáticamente las sesiones existentes cuando se crea una nueva. Es posible deshabilitar este comportamiento y dejar la aplicación vulnerable a este tipo de ataque.

Ejemplo 1: El siguiente ejemplo muestra un fragmento de código de una aplicación protegida con Spring Security donde se ha deshabilitado la protección contra fijación de sesión.

	<http auto-config="true">
        ...
        <session-management session-fixation-protection="none"/>
	</http>

Incluso en una aplicación vulnerable, el éxito del ataque específico descrito aquí depende de que varios factores favorezcan al atacante: el acceso a un terminal público no supervisado, la capacidad de mantener activa la sesión comprometida y la presencia de una víctima interesada en iniciar sesión en la aplicación vulnerable del terminal público. En la mayoría de los casos, se pueden superar los dos primeros desafíos si se dedica suficiente tiempo a esta tarea. También es factible buscar una víctima que utilice un terminal público y que esté interesada en iniciar sesión en una aplicación vulnerable, siempre que el sitio sea razonablemente popular. Cuanto menos conocido sea el sitio, menos probabilidades habrá de encontrar una víctima interesada que utilice un terminal público y menos posibilidades de éxito del vector de ataque descrito anteriormente.

El mayor desafío al que se enfrenta un usuario malintencionado al explotar vulnerabilidades de fijación de sesión es inducir a la víctima a que se autentique en la aplicación vulnerable con el identificador de sesión que conoce el usuario malintencionado. En el Example 1, el atacante logra esto mediante un método directo obvio que no resulta adecuado para ataques donde los sitios web son menos populares. Sin embargo, no hay que bajar la guardia, ya que los atacantes disponen de muchas herramientas para eludir las limitaciones de este vector de ataque. La técnica más habitual que utilizan los atacantes consiste en aprovechar las vulnerabilidades Cross-Site Scripting o de división de respuestas HTTP en el sitio de destino [1]. Al engañar a la víctima para que envíe una solicitud malintencionada a una aplicación vulnerable que muestra JavaScript u otro código en su explorador, el atacante puede crear una cookie que provocará que la víctima vuelva a utilizar el identificador de sesión controlado por el atacante.

Conviene destacar que las cookies a menudo están vinculadas al dominio de nivel superior asociado a una determinada URL. Si varias aplicaciones residen en el mismo dominio de nivel superior, por ejemplo, bank.example.com y recipes.example.com, una vulnerabilidad en una aplicación puede permitir que un atacante establezca una cookie con un identificador de sesión fijo, que se utilizará en todas las interacciones con cualquier aplicación que se encuentre en el dominio example.com [2].

Otros vectores de ataque pueden ser el envenenamiento de DNS y los ataques relacionados basados en la red en los que el atacante redirecciona una solicitud de estado válido para hacer que el usuario visite un sitio malintencionado. Normalmente, los ataques basados en la red conllevan una presencia física en la red de la víctima, además del control de un equipo comprometido en la red, lo que complica aún más la explotación remota. No obstante, no se puede subestimar su importancia. Los mecanismos de administración de sesión menos seguros, como la implementación predeterminada en Apache Tomcat, permiten que los identificadores de sesión normalmente esperados en una cookie se especifiquen también en la URL. Esto permite que un atacante haga que una víctima use un identificador de sesión fijo simplemente mediante el envío por correo electrónico de una URL malintencionada.