¿Cómo debo proteger el parámetro de URL en la consulta de JPQL para restablecer el flujo de contraseña?

1

Estoy implementando una aplicación web con un flujo de restablecimiento de contraseña. Esto es lo que he hecho para intentar que sea seguro.

  1. Introduzca la dirección de correo electrónico en el formulario de contraseña olvidada.
  2. Independientemente de si el cliente existe, la aplicación informa de un correo electrónico enviado, esto evita revelar la existencia de una dirección de correo electrónico.
  3. Genero una cadena aleatoria segura, luego la cifro y la uso como un token de acceso con una validez de 1 día.
  4. El cliente vuelve a hacer clic en el enlace que contiene un parámetro de token, reviso la tabla de clientes y les permito ingresar al formulario de restablecimiento de contraseña si el token es válido.
  5. En esa forma, puse el valor del token, no el ID del cliente que se está restableciendo, lo que evita exponer el ID.

La primera pregunta es: ¿es esto lo suficientemente seguro?

Pero mi pregunta principal está relacionada con la hibernación y los parámetros: mi consulta es como "Seleccione c del cliente donde c.token =? 1 y c.activeDate > DATe_NOW". Paso en el valor del parámetro token en bruto.

En JPA / Hibernate o JPQL, ¿existe algún riesgo de un ataque de inyección al modificar el parámetro del token cuando estoy usando parámetros posicionales como este en la consulta?

    
pregunta Richard G 23.07.2015 - 15:04
fuente

2 respuestas

0

Primero, no veo ningún beneficio de cifrar la cadena aleatoria en el paso 3. (No veo una diferencia entre tratar de adivinar una cadena aleatoria y una cadena aleatoria cifrada, que podría considerarse simplemente otra cadena aleatoria .) Pero tampoco veo cómo esto duele ...

Para su primera pregunta, ¿es su algoritmo lo suficientemente seguro? Eso depende de qué tipo de datos / funcionalidad está protegiendo. Su método simplemente asume que si tiene acceso a la dirección de correo electrónico asociada con la cuenta, debería poder restablecer la contraseña, y parece que lo está logrando de una manera bien pensada y razonablemente segura. Si su sitio tiene transacciones financieras o registros de salud, puede considerar agregar un paso de verificación adicional; Las preguntas de seguridad son la forma más común de hacer esto. Si su sitio tiene secretos gubernamentales o códigos nucleares, probablemente querrá obligar a las personas a restablecer su contraseña en persona ...

En cuanto a su segunda pregunta, con SQL parametrizado está protegido contra la inyección de SQL. Realmente no importa lo que es el token o si alguien se pone elegante al poner "TABLE TABLE" en su cadena de token. Coincidirá con el token esperado o no.

Además, supongo que incluso si lo dejas abierto para que se produzca la inyección de SQL, el hecho de que estés cifrando / desencriptando el token dificultaría que alguien inyecte un código SQL significativo a menos que supiera que lo estás haciendo Esto, y cómo lo estabas haciendo. Entonces, aunque empecé diciendo que el cifrado no es necesario, creo que podría ayudar como "seguridad por oscuridad" si no tuviera protección contra la inyección de SQL.

    
respondido por el TTT 23.07.2015 - 18:07
fuente
0

No estoy muy seguro de a qué te refieres cuando dices que estás usando "Hibernate" (¿NHibernate?)

De cualquier manera, generalmente, cuando ve el patrón de reemplazar un parámetro con un ? , sugiere que está trabajando con una consulta parametrizada. Si está utilizando consultas parametrizadas, estará protegido contra la inyección de SQL en su situación.

Si puede aclarar qué tecnología está utilizando, puedo dar una respuesta más clara.

    
respondido por el Abe Miessler 23.07.2015 - 16:38
fuente

Lea otras preguntas en las etiquetas