Joven hacker sonriendo

Evitar Ataques de Repetición

Nuestros ethical hackers explican cómo evitar vulnerabilidades de seguridad mediante la programación segura en WebSphere 8 al evitar los ataques de repetición. Un ataque de repetición se produce cuando un atacante reenvía el contenido de un token o hash para duplicar una solicitud del usuario.

Necesidad

Evitar ataques de tipo repetición en servicios web (JEE).

Contexto

A continuación se describe las circunstancias bajo las cuales la siguiente solución tiene sentido:

  1. Se está desarrollando una aplicación bajo la plataforma Java Enterprise Edition (JEE).

  2. Se desea utilizar la tecnología JAX-WS de la especificación JEE.

Solución

  1. Un ataque de repetición (replay attack) consiste en capturar y enviar de nuevo partes de la comunicación (aún si está cifrada o enmascarada) de tal modo de que el receptor asuma que es información enviada por el emisor original.

  2. Si bien el atacante no conoce el contenido de la información que está reenviando, en muchos casos no es necesario para causar eventos no deseados como por ejemplo repetir una solicitud de compra o incluso lograr una suplantación de identidad al enviar el token/hash que realmente corresponde a una sesión/clave verdadera.

  3. Métodos de mitigación [2]:

    • Token de sesión: Consiste en que el servidor envía un código token, el cual el cliente usa para transformar la clave (por ejemplo aplicando una función de resumen a la unión de la clave y el token) antes de enviarla de nuevo al servidor, valor con el que este podrá comparar la autenticidad del cliente. Si un atacante intentara luego un ataque de repetición, no funcionaría porque el token que el servidor le enviaría sería diferente (la generación de éste debe ser aleatoria).

    • Claves/números de un solo uso: Consiste en contraseñas que expiran luego de su primer uso o luego de un lapso de tiempo muy pequeño.

    • Marcas de tiempo: Implica que debe haber previamente una sincronización de relojes entre cliente y servidor. El servidor solo acepta mensajes con fecha y hora dentro de un margen de tolerancia. De este modo se minimiza el riesgo al proveer una ventana de tiempo más ajustada para explotación.

  4. Para configurar el servidor de aplicaciones WebSpere de IBM, se debe añadir las siguientes cuatro propiedades a la configuración de generación de token del callback handler, indicando un valor de true para cada una (de este modo se estará configurando los números de un solo uso y las marcas de tiempo) [3]:

com.ibm.wsspi.wssecurity.token.username.addNonce
com.ibm.wsspi.wssecurity.token.username.addTimestamp
com.ibm.wsspi.wssecurity.token.username.verifyNonce
com.ibm.wsspi.wssecurity.token.username.verifyTimestamp


Haz un comentario

Estado de los servicios - Términos de Uso