¿Debería estar ofuscando las ID de las bases de datos de mis usuarios?

Question

Me dicen que no debería estar usando ID de bases de datos directamente en código HTML en aplicaciones web.

Actualmente uso de los identificadores en cosas como identificadores de fila de tabla (TableRow-454, donde 454 es el ID de la fila en la base de datos), en campos ocultos o selecciona en formas o en las direcciones URL. (No me estoy refiriendo a decirles a las personas visualmente en una página que son ####.)

La recomendación que me dieron fue que utilizara algunos cálculos matemáticos para ofuscar la identificación del usuario. Estoy pensando que esto solo complicará las cosas y agregará una complejidad innecesaria. Pero puedo ver algunas buenas razones para que sea más difícil determinar una ID de base de datos del HTML.

¿Olvidaste las ID del usuario? ¿O te importa?

Answer 1

No, solo está haciendo trabajo extra para usted.

Siempre que esté haciendo suficientes pruebas de que cambiar una identificación aquí o allá no le dará acceso a los usuarios a algo que no deberían, entonces está bien tener las identificaciones visibles.

En algunas situaciones, puede ser beneficioso ocultarlas o tener números no secuenciales, o quizás no comenzar a contar desde cero. Por ejemplo, si alguien obtuvo el número de orden 3 podría comenzar a hacer preguntas ...

Answer 2

Sí, probablemente deberías.

Si un usuario modifica dichos ID maliciosamente, ¿su código se asegura de que los datos que están solicitando siguen siendo datos que pueden ver?

Es más fácil ocultar la ID que realizar la validación manualmente en todo el lugar.

Editar, con claridad este tiempo:

Si se visualiza en la pantalla una lista con de 1 a 20, que es muy fácil de validar que la respuesta fue de entre 1 y 20 ID. Si muestra las identificaciones reales a la pantalla, o bien necesita gastar memoria almacenando en caché los ID, o necesita hacer otra llamada a la base de datos/una consulta más larga para asegurarse de que no le den datos incorrectos.

Si utiliza ID sustitutos, esto se vuelve más fácil, creo.

Answer 3

No me gusta exponer a los usuarios nada que hable sobre el funcionamiento interno de los datos, sin embargo, siempre va a suceder especialmente cuando se trata para crear listas desplegables basadas en un origen de datos. Mi solución a esto es tener diferentes especificaciones de identidad en las tablas para eliminar los ataques incrementales y, cuando sea posible, encriptar los valores de la cadena de consulta. Esto no siempre es posible, dados los patrones de URL de MVC muy populares en .NET, así que tiendo a usar un nombre de columna único y luego lo normalizo para la URL. Luego busco ese valor en la base de datos. Sin embargo, no hay una manera fácil de evitarlo por completo.

Answer 4

Yo diría que si esa ID tiene algún tipo de significado para el usuario, y usted está tratando con una aplicación sensible a los datos, debe ocultar el valor de la ID. Lo que es más importante, le recomiendo que verifique si el usuario actual tiene acceso a los datos que están solicitando a través de la URL. Por ejemplo, si tiene una URL como mysite.com/account/view/12, ¿el usuario actual tiene acceso a la ID de esa cuenta (es decir, 12)?

Si la información es pública y no es delicada, diría que no es necesario ocultar los valores de ID.

Answer 5

Usted debe ocultar los identificadores de base de datos de usuarios

¿Por qué? Es un detalle de implementación del que ellos (el usuario) no deben preocuparse. Soy ID 123311122? ¡A quien le importa! (A menos, tal vez estoy en ICQ). Vea cómo SO minimiza (pero no elimina) la exposición, por ejemplo.

En una nota secundaria, el uso de ID predecibles es también otro vector de ataque, la seguridad por oscuridad, pero sigue siendo otra herramienta válida. Sin embargo, nunca he trabajado en software donde esto haya sido una preocupación.

Dicho esto, si su marco de trabajo no proporciona los medios para manejar "ocultar ID" o proporcionar un mapeo limpio, puede que simplemente no valga la pena cambiarlo.

Answer 6

Yo diría que en general está bien, pero hay también algunas precauciones:

• Si los números son secuenciales se abren a 'juegos de adivinanzas' (por ejemplo, el usuario cambia los detalles de id = 4511? a detalles? id = 4512 para ver los detalles de otra persona). Para contrarrestar esto, primero necesita seguridad adecuada. Sin embargo, en algunos casos esto no será suficiente, porque revelar que la información existe podría ser un problema en sí mismo. Tome Youtube, por ejemplo, usan identificaciones más dispersas para evitar el raspado de la pantalla del robot.

• Si hace suposiciones acerca de la naturaleza de los identificadores, podría tener problemas (es decir, si manipula los identificadores directamente en la GUI u ordena los elementos según los identificadores). Esto podría ser una sorpresa desagradable una vez que necesite equilibrar la carga de su base de datos y terminar con rangos de identificación separados.

• ID de reutilización. Por ejemplo, el motor InnoDB de MySql restablece las secuencias al reiniciar (al último valor máximo). Esto puede morderte mucho si lo eliminas.

Pero todas estas trampas se aplican a Identificación del encargo: s así, pero son probablemente donde estas personas están viniendo. La solución más flexible en mi opinión son los GUID: s, porque puede generarlos en cualquier lugar y no se topa con ninguno de los problemas mencionados anteriormente. Sin embargo, son más difíciles de leer para los humanos, por lo que es una compensación.

Answer 7

Le recomiendo que use nombres amistosos. Es más moderno y más semántico. Además, se ve mucho mejor cuando crea un enlace.

Por ejemplo, considere mysite/products.aspx? Id = 25 vs mysite/products/ferrari. Este último es más limpio, más fácil de recordar (para los usuarios), y así sucesivamente.

Si actualmente está utilizando ID en campos ocultos, intente usar session para almacenar esos valores. Si los usa solo en los identificadores de fila de la tabla que mencionó, no creo que valga la pena el tiempo para ocultarlos.

Answer 8

IMO: No, no debe ofuscar las identificaciones. Si la seguridad es una preocupación para su aplicación, de todos modos necesita otras medidas de seguridad. La seguridad por oscuridad no es suficiente, solo te da una falsa sensación de seguridad.

Por cierto, si solo hace un poco de matemática, es probable que otras identificaciones, también oscurecidas, sigan siendo predecibles. En muchos casos, el malo no le importa qué cuenta se rompe en, con tal de que no es su propia ;-)

Answer 9

ID:s in URI:s are a part of a good UI si desea que los usuarios sean capaces de caminar ese camino.Todos los URI: s son públicos de todos modos, corresponde a la página de respuesta manejar la solicitud y basar el renderizado en algún tipo de autenticación.

Transacciones y material de otra manera se les podría ocultarse fácilmente con una cadena salada + hash y se almacenan en otra columna en su base de datos si se quería, pero si todavía no estás validar la entrada del usuario (que en la programación web con claridad podría estar "navegando a través del URI") te estás perdiendo el punto.

Como Greg answered, un número de orden probablemente no debería ser baja, pero la responsabilidad de ese tipo de tratamiento de la información no debe estar dentro de la página web, pero dentro de/los valores establecidos de la organización (es decir, a pesar de ello no esté imprimiendo a cabo la número de orden en un recibo escrito así que ¿por qué ocultarlo en primer lugar?)

Con la red siendo tan transparente como lo es hoy, es difícil encontrar otro uso además de la forma en que se usa acorta URI: s, es decir, las páginas de videos de Youtube y los innumerables servicios de acortamiento de URI.

Answer 10

Como un ejemplo de "publicación" de una identificación al público, mira la url para esta publicación.

Intenté https://stackoverflow.com/questions/1, pero parece que se eliminó. Tienes que ir al While applying opacity to a form should we use a decimal or double value? para encontrar la "primera" pregunta ordinal;)

... no hay daño hecho, solo una referencia a otra publicación.

Answer 11

"Me han dicho que no debería estar usando ID de bases de datos directamente en código HTML en aplicaciones web. ... ¿Ocultas las ID del usuario?"

Los usuarios esperan enfrentarse a datos que pueden vincular al mundo real con el que trabajan en sus trabajos.

Los "ID de la base de datos" deben formar parte de la interfaz del usuario solo en la medida en que dichos ID sean también parte de la situación real de trabajo del usuario. Si no lo es, entonces la aplicación debería proteger al usuario completamente de tales campos.

Hacer ese blindaje de hecho equivale a "más trabajo", pero eso es completamente irrelevante. No hacer ese blindaje significa darle al usuario una aplicación que le resultará más difícil de manejar, lo que eventualmente dará como resultado que el "usuario haga más trabajo" todos los días, una y otra vez.

Answer 12

Si decide identificar las filas a prueba de manipulaciones en campos ocultos, puede consultar el libro asp.net mvc de Steve Sanderson en la página 415 donde presenta una clase de utilidad HMAC (Código de autenticación hash Message) para este propósito. Es .NET, por supuesto, pero puedes hacerte una idea. Puedes verlo en Google Books, (Sanderson ha escrito sobre el mejor libro de programación que he leído).

Cuando coloco identificadores de fila en html y el modelo comercial indica que un usuario debe tener acceso a un determinado conjunto de filas, como las que ha insertado, podría diseñar una tabla db para incluir una columna de identificación de usuario e incluirlo en cualquier operación de db (pseudocódigo: donde @rowID = table.rowID AND @userID = table.userID). De esta forma, si otro usuario usuario piratea los ID de fila en campos ocultos, la operación de base de datos no les permitirá ver los datos de otro usuario porque los ID de usuario no coincidirán. Por supuesto, este enfoque asume que estás usando autenticación de algún tipo y que no ha sido pirateada también.