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.