¿Cómo implementar la funcionalidad de restablecimiento de contraseña sin ser susceptible a la fuga del referer entre dominios?

Navega tus respuestas
2

Por lo general, he implementado la funcionalidad de restablecimiento de contraseña al enviar un enlace que incluye algo como esto:

http://example.com/pwreset?id=userId&resetToken=superSecretResetToken

En mi página pwreset , normalmente solicitaré algunos recursos de terceros. Por lo que entiendo, ya que tengo información confidencial en mi URL en este punto, podría revelarse a estos terceros en el encabezado referer cuando se realice la solicitud.

Si bien confío en estas partes, preferiría que no vean las URL que les darían la posibilidad de restablecer las contraseñas o que esta información esté registrada en su extremo y disponible en caso de que su sistema esté comprometido.

Algunas preguntas:

  • ¿Es posible implementar una página de restablecimiento de contraseña que incluya recursos de terceros sin revelar el referer ?
  • ¿Dónde más, además del tercero, esta información sería visible (si es que está en cualquier lugar)?
pregunta Abe Miessler 06.10.2014 - 21:14
fuente

2 respuestas

4

Sí. Esto podría resolver su problema:

  1. mysyte.com/?token=xxx configura una cookie y la redirige a mysite.com/changepwd sin devolver ningún marcado
  2. mysite.com/changepwd reconoce al usuario por la cookie y puede Solicite con seguridad recursos de terceros sin perder el token. a través de encabezados de referencia.

Para responder a su segunda pregunta: si el recurso está en http, entonces cualquier nodo de la red entre usted y la tercera parte podrá ver el token. Si es https, solo la tercera parte recibirá el token.

    
respondido por el valentinas 06.10.2014 - 22:06
fuente
2

Haga que el token sea de un solo uso: caduque cuando se solicita la página por primera vez, por lo que ya no será de ninguna utilidad para nadie después de ese punto en caso de que se produzcan fugas.

También puede responder a la solicitud inicial con un redireccionamiento a una URL neutral que no le importa que se filtre (después de haber configurado una cookie / sesión para recordar la autenticación). Sin embargo, esto todavía deja el historial del navegador, los registros del servidor / proxy y las extensiones del lado del cliente como posibles fuentes de fugas.

    
respondido por el bobince 06.10.2014 - 22:06
fuente

Lea otras preguntas en las etiquetas

Configuración de Burp para permitir la conexión SSL ¿Por qué la mayoría de los servidores no usan el encabezado del Servidor HTTP, pero la mayoría de los navegadores usan el agente del Usuario? [cerrado]