Diga que quería evitar exponer una clave primaria de base de datos en una URL; de alguna manera debo cifrar la clave, de modo que la url solo exponga elementos de un espacio de cifrado no enumerable. ¿Qué tipo de cifrado debo usar?
N.B. Soy consciente de que esto no es todo un proceso seguro. Por supuesto, tendría que validar el intento de acceso a dicha URL. Me pregunto cómo podría usar el cifrado para agregar una capa de ofuscación que impida la enumeración de objetos.
La Referencia de objetos directa es un nombre realmente malo para: falta de controles de autorización . Saber la identificación no es realmente el problema. El problema es que cada registro en la base de datos debe tener información de propiedad, y usted debe hacer cumplir esta propiedad manteniendo la información sobre el usuario en una sesión.
Los mejores criptógrafos saben cuándo no se necesita criptografía, y se puede usar un sistema más fuerte en su lugar.
La criptografía en el ID de registro no tiene nada de significativo. Todavía podrían volver a reproducir el ID a menos que también estuviera vinculado a una clave de sesión. Sin embargo, la pregunta más importante es ¿por qué se pasa una clave principal en una URL? Si está rastreando el estado de la sesión, debería ser posible trabajar con el lado del servidor de datos sin tener que pasarlo de un lado a otro. También puede usar elementos como POST para evitar tener que ponerlo en la URL, incluso si se tiene que pasar algún identificador al cliente.
Si la ID es confidencial, configure una asignación de uso único en la base de datos para que pueda pasar un token en lugar de una ID significativa. De esa manera, no se puede romper y solo puede ser resuelto por el servidor por el período de tiempo que elija, por el usuario que elija.
Hay dos medios generales para evitar las referencias a objetos directos no seguros.
Como dice @Rook, la mejor manera es verificar la autorización en todas las solicitudes :), ese es el lugar correcto para resolver el problema.
Si, por alguna razón, no puede hacer eso o quiere una capa adicional de protecciones, podría considerar crear un mapa de acceso, de modo que la referencia presentada a los usuarios no sea directa y no se pueda cambiar. para dar acceso a los datos de otros usuarios.
Para ilustrar este concepto. Supongamos que tenemos una ID de base de datos que va A1..A10000 que son registros para varios usuarios. Cuando el usuario inicia sesión o accede a la página que muestra estos datos, hacemos una consulta de base de datos que devuelve todos los registros a los que deberían tener acceso. Luego, en el servidor creamos una tabla de mapeo
por ejemplo
1 - > A1000
2 --- > A1005
etc
Luego, cuando le damos el ID al usuario, le damos el ID asignado (por ejemplo, 1, 2) y no el ID directo (por ejemplo, A1000, A1005).
Por lo tanto, cuando un usuario realiza una solicitud a la aplicación, solo puede solicitar los ID a los que tiene acceso y no a la pertenencia de otros usuarios (ya que la referencia directa del objeto no está expuesta).
Si bien el control de acceso a datos es la mejor manera de abordar esto, puede que no siempre sea posible. En tales situaciones (y además del control de acceso a datos), puede implementar la ofuscación usando un mapa de acceso en la base de datos (lo que puede ocupar bastante espacio, dependiendo de lo que esté ofuscando). O puede usar un cifrado simétrico para generar la referencia Indirecta.
Le sugeriría que use AES y no DES o tripleDES. AES es más rápido que tripleDES. DES es obsoleto. Si está utilizando .net, verifique esto para una implementación: enlace
Lea otras preguntas en las etiquetas web-application encryption