¿Tiene sentido hacer un hash de un ID de sesión antes de pasarlo a un socio publicitario?

Question

¿Tiene sentido hacer un hash de un ID de sesión antes de pasarlo a un socio publicitario?

#1 de Adi (10 votos)
#2 de IDisposable (0 votos)

16

Mi empresa tiene una tienda web. Trabajamos con un socio que otorga cupones de descuento a nuestros clientes después de que compran (los cupones se pueden usar en otras tiendas en línea) y también entregan cupones para nuestra tienda a clientes de otras tiendas. Para este propósito, el socio nos solicita que les enviemos algunos datos sobre nuestros clientes y sus respectivos pedidos en nuestra página de pago completo. Quieren que hagamos esto configurando algunas variables de javascript e incluyendo un javascript de su servidor, que también mostrará un anuncio publicitario en nuestra página de pago completo.

Ya aprendí que incluir anuncios publicitarios conlleva cierto riesgo . Parece que nuestra empresa ya tomó la decisión de aceptar este riesgo para este socio.

Ahora estoy preocupado por un punto en particular. Los datos que el socio quiere que enviemos también incluyen la identificación de la sesión de nuestro cliente, para "reconocer solicitudes dobles", según el socio. Creo que no deberíamos enviar el ID de sesión real al socio, porque con esta información el socio podría falsificar la identidad del cliente en nuestro sitio. Por lo tanto, me gustaría enviar un hash de la ID de sesión en su lugar. Con esto, el socio aún debería poder reconocer solicitudes dobles sin poder falsificar la identidad del cliente.

¿Esto tiene sentido? ¿O el socio, por el hecho de que incluimos un javascript de su servidor, ya tiene formas de hacer más daño de lo que podría hacer al conocer el ID de sesión? Almacenamos la identificación de la sesión en una cookie HttpOnly (para la conexión entre nuestro servidor y nuestro cliente).

Si tiene sentido el hash del identificador de sesión, ¿qué función de hash sería una buena opción?

web-application attacks session-management javascript

pregunta user26315 23.05.2013 - 10:27

fuente

2 respuestas

0

Puede generar fácilmente un "token de sesión" diferente para que lo sirva el anunciante y colocar ese token de anuncio en su tienda de sesión estándar. En .Net, algo tan simple como:

void Session_Start(object sender, EventArgs e) 
{
   // assign a random GUID for the ad partner
   Session["AdToken"] = Guid.NewGuid().ToString();
}

Más adelante, puede obtener el valor para servir con <%=(string)Session["AdToken"]%> (para páginas ASPX).

respondido por el IDisposable 30.05.2013 - 20:18

fuente

Lea otras preguntas en las etiquetas web-application attacks session-management javascript

Supervisar las actividades del administrador de dominio de Active Directory Lista de correo cifrada con GPG y otros enfoques para una comunicación segura

score 10 · Accepted Answer

Sí, lo que dices tiene sentido.

Al configurar su cookie como una cookie HttpOnly , está mitigando el riesgo de que el JavaScript de su socio tenga acceso. al ID de sesión del usuario. Dado que su socio insiste en obtener un identificador único para sus clientes, no veo nada malo en enviarles una versión de hash segura del hash.

El punto clave aquí es que usted no usa la versión de hash del ID de sesión como un identificador, por lo que su socio no podrá usarla para hacerse pasar por sus clientes, pero en Al mismo tiempo, la versión con hash es lo suficientemente exclusiva para que su socio reconozca a sus clientes.

En cuanto a qué usar para el hashing, no importa qué algoritmo de hashing use, siempre que su longitud de salida sea igual o mayor que su ID de sesión. En este caso, por supuesto, necesita usar un sal fijo (un pimiento) todo el tiempo porque desea que el mismo ID de sesión produzca el mismo hash.