Guardar una identificación en una cookie. ¿Punto de vista de seguridad?

1

Estoy desarrollando un sitio web ASP.NET MVC 5, en el que un usuario puede seleccionar algunos filtros, en función de los rellenos en los que el servidor procesa un resultado, y el usuario puede hacer un pedido y pagarlo.

En mi tabla Order almaceno los filtros (5 columnas), el Id(PK) , y necesito almacenar un OrderId en un cookie para rastrearlo, sé que es una mala práctica exponer y almacene el PK en el lado del cliente, así que creo otra columna llamada OrderId . Este order id también debe ser único, y una lectura amigable (por lo que aquí se descarta un GUID), pensé en obtener el DateTime("yyyyMMddhhmmssffff") y concat con otro filtro para hacer esta identificación, pero creo que es una opción débil porque un atacante Podrías encontrar el patrón fácilmente.

¿Cuál es la opción que tengo para lidiar con esta situación? ¿Puedo hash este OrderID antes de guardar la cookie? ¿Y sobre guardar el código plano en DB? La validación de cookies es de 24 horas.

    
pregunta gog 01.06.2015 - 19:47
fuente

2 respuestas

1

Dependiendo de la sensibilidad de los datos, sugeriría los siguientes elementos, organizados de menos seguros a más seguros.

No hacer nada: según el contenido de su pregunta, probablemente elegiría esta opción. Un filtro de búsqueda no está asociado a un usuario (aparentemente) y probablemente no expone nada particularmente interesante. Incluso podría exponer el PK directamente sin demasiada preocupación, a menos que esos filtros puedan exponer datos confidenciales. Conozco muchos sistemas que utilizan otros medios para proteger los filtros (y todos los demás datos), especialmente al usar una ID de sesión real para que solo los usuarios autorizados a ver el filtro puedan ver el filtro.

Randomize PK: Convierte a PK en un número aleatorio en lugar de auto-number. Esto evita que las personas adivinen PKs contando una y otra vez. Esto hace que sea más difícil encontrar un filtro válido. Yo usaría esto si el filtro no contiene ningún dato sensible en absoluto; haga que no sea trivial para un atacante encontrar un filtro aleatorio. Yo usaría un espacio grande de números aleatorios, como los números de 64, 128 o 256 bits. Use esto si simplemente quiere evitar que las personas "rastreen" su base de datos en busca de valores interesantes.

Firmar PK: Adjunte un nonce o MAC a cada PK, de modo que el nonce y el PK juntos sean necesarios para recuperar el valor. Esto evita la modificación casual de la PK en el cliente. Valide que el MAC o nonce coincida con el valor esperado. Esto debería disuadir a los piratas informáticos ocasionales, especialmente si los datos son particularmente poco interesantes y no contienen información personal.

Encriptar PK: simplemente encripta la cookie antes de enviarla. Esta es la primera recomendación en la lista que sugiere que la PK no se envía directamente al cliente, y solo usaría este método para identificar personalmente la información, o si la exposición del filtro resultaría en un posible fraude. También combinaría este paso con la firma y la aleatorización para una solución robusta.

    
respondido por el phyrfox 01.06.2015 - 21:47
fuente
0

Nunca necesitas usar cookies.

Coloque el ID del pedido en la cadena de consulta (vuelva a escribir los enlaces de la página para incluirlo).

En el lado del servidor, valide la solicitud almacenando la IP del cliente. No permita que las computadoras con diferentes IP accedan al mismo pedido.

    
respondido por el Tyler Durden 02.06.2015 - 05:29
fuente

Lea otras preguntas en las etiquetas