Asistencia en la estructura de la URL para aceptar / rechazar enlaces

Question

Estoy en el proceso de creación de una aplicación en la que un cliente puede añadir direcciones de correo electrónico a un evento. Esto significa que cada dirección de correo electrónico se envía por correo electrónico las URL 2 cuando se añade a la lista, 1 url para aceptar y el otro a declinar. La url se compone de un número de parmatters de consulta, de identificación, etc.

El problema que tengo es que yo quiero evitar que el escenario en el que alguien pudiera "adivinar" otra personas url - tales como invitados la combinación de parametters etc. Si bien esto es muy poco probable, todavía quiero prevenir tales.

he visto varios escenarios para ayudar a prevenir esto, es decir. añadir un valor hash, cifrar la URL etc. Sin embargo Busco a la práctica el enfoque más seguro y mejor para esto y quisiera cualquier información posible.

En un aparte estoy de codificación en C #, pero yo no creo que la solución a esto es específico del lenguaje.

Gracias de antemano.

Answer 1

Estoy de acuerdo que esto no es un lenguaje específico. Yo tenía una situación muy similar a este en los últimos años. Tenía que ser extremadamente seguro debido a los niños y padres que reciben las comunicaciones. La solución más rápida era algo como lo siguiente:

1. Primera almacenar la información en que se usan en la URL como parámetros en algún lugar de una base de datos. Esto debería ser relativamente sencillo y rápido.
2. Crear dos GUID.
3. asociar el primer GUID con los datos en la base de datos que se habrían utilizado para procesar una "aceptación".
4. Asociar el segundo GUID para un registro "disminución" en la base de datos.
5. Crear los dos URL de la única de parámetros como el GUID.
6. Si se hace clic en la URL de aceptación, utilizar los datos de bases de datos asociados a ella para procesar la aceptación.
7. Si se hace clic en la decadencia, borrar los datos de la base de datos o archivarla, o lo que sea.
8. Después de un período de tiempo, es hacer clic en ningún URL, eliminar o archivar los datos asociados con los GUID de modo que ya no se pueden utilizar.

El GUID son extremadamente difíciles de adivinar, y la probabilidad de adivinar que es realmente útil sería tan improbable que es casi imposible.

Answer 2

supongo que está guardando estas direcciones de correo electrónico en alguna parte. Así que es muy fácil hacer un identificador seguro para cada entrada que tiene. Ya sea que es un hash o alguna técnica de cifrado, en realidad no importa. Pero supongo que un hash es más fácil de implementar y de hecho significaba para este trabajo.

Así que por ejemplo, el hash de EMAILADDRESS, el valor de PK del expediente, con la marca de tiempo cuando se añadió, y algunos realmente imposible adivinar sal. Sólo concatenar los diversos campos juntos y hash de ellos.

Al final, no envía nada, pero la clave hash al servidor. Así que cuando usted envía estos dos enlaces, podrían tener el siguiente aspecto:

http://www.url.com/newsletter/acceptsubscription.aspx?id=x1r15ff2svosdf4r2s0f1
http://www.url.com/newsletter/cancelsubscription.aspx?id=x1r15ff2svosdf4r2s0f1

Cuando el usuario hace clic en un vínculo tal, su apariencia de servidor en la base de datos para el registro que contiene la llave suministrada. Fácil de implementar y muy seguro si el derecho de hacer. De ninguna manera alguien puede adivinar otra tecla personas. Sólo tener en cuenta las cosas normales cuando se hace algo con el hash. Tales como:

• No se olvide de añadir la sal.
• Elija una muy lento, y realmente segura, algoritmo de hash.
• Sólo asegúrese de que nadie puede averiguar su propio hachís, a partir de información que pueden poseer.
• Si está realmente asustado de la gente que hace cosas malas, asegúrese de fuerza bruta parada mediante la adición de acelerador en la página web. Sólo permitir que X número de solicitudes por minuto, por ejemplo. O alguna forma de prohibición de una dirección IP.

No soy un experto en estas cosas, por lo que puede haber margen de mejora. Sin embargo creo que esto se debe apuntar en la dirección correcta.

editar : Tengo que añadir; la solución proporcionada por Tim C también es bueno. de GUID son de hecho muy útil para situaciones como estas, y el trabajo efectivamente el mismo que mi solución hash anteriormente.