Exponer ID de bases de datos: ¿riesgo de seguridad?

Escuché que exponer las ID de la base de datos (en URL, por ejemplo) es un riesgo de seguridad, pero tengo problemas para entender por qué.

¿Alguna opinión o enlace sobre por qué es un riesgo o por qué no lo es?

EDITAR: por supuesto, el acceso tiene un alcance, por ejemplo, si no puede ver el recurso foo?id=123, obtendrá una página de error. De lo contrario, la URL en sí misma debería ser secreta.

EDITAR: si la URL es secreta, probablemente contendrá un token generado que tiene una vida útil limitada, por ejemplo, válido por 1 hora y solo se puede usar una vez.

EDITAR (meses después): mi práctica preferida actual para esto es usar UUIDS para ID y exponerlos. Si estoy usando números secuenciales (generalmente para el rendimiento en algunas bases de datos) como ID, me gusta generar un token UUID para cada entrada como una clave alternativa, y exponer eso.

Dadas las condiciones adecuadas, exponer identificadores no es un riesgo de seguridad. Y, en la práctica, sería extremadamente oneroso diseñar una aplicación web sin exponer identificadores.

Aquí hay algunas buenas reglas a seguir:

1. Utilice la seguridad basada en roles para controlar el acceso a una operación. La forma en que se hace esto depende de la plataforma y el marco que haya elegido, pero muchos admiten un modelo de seguridad declarativo que redirigirá automáticamente los navegadores a un paso de autenticación cuando una acción requiera cierta autoridad.
2. Utilice la seguridad programática para controlar el acceso a un objeto. Esto es más difícil de hacer a nivel de marco. Más a menudo, es algo que debe escribir en su código y, por lo tanto, es más propenso a errores. Esta verificación va más allá de la verificación basada en roles al garantizar no solo que el usuario tiene autoridad para la operación, sino que también tiene los derechos necesarios sobre el objeto específico que se está modificando. En un sistema basado en roles, es fácil verificar que solo los gerentes pueden dar aumentos, pero más allá de eso, debe asegurarse de que el empleado pertenezca al departamento del gerente en particular.
3. Para la mayoría de los registros de la base de datos, las condiciones 1 y 2 son suficientes. Pero agregar identificaciones impredecibles puede considerarse como un pequeño seguro adicional, o "seguridad en profundidad", si acepta esa noción. Sin embargo, un lugar donde los identificadores impredecibles son una necesidad es en las ID de sesión u otros tokens de autenticación, donde la ID misma autentica una solicitud. Estos deben ser generados por un RNG criptográfico.

Si bien no es un riesgo de seguridad de datos, este es absolutamente un riesgo de seguridad de inteligencia empresarial, ya que expone tanto el tamaño como la velocidad de los datos. He visto cómo las empresas se ven perjudicadas por esto y he escrito sobre este antipatrón en profundidad. A menos que solo estés construyendo un experimento y no un negocio, te recomiendo que mantengas tus identificadores privados fuera del ojo público. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

Depende de lo que representen los ID.

Considere un sitio que, por razones competitivas, no quiere hacer públicos cuántos miembros tienen, pero al usar ID secuenciales lo revela de todos modos en la URL: http://some.domain.name/user?id=3933

Por otro lado, si utilizaron el nombre de usuario del usuario en su lugar: http://some.domain.name/user?id=some, no han revelado nada que el usuario aún no sabía.

El pensamiento general sigue estas líneas: "Revele a cualquier persona tan poca información sobre el funcionamiento interno de su aplicación".

Exponer la ID de la base de datos cuenta como revelar cierta información.

Las razones de esto es que los piratas informáticos pueden usar cualquier información sobre el funcionamiento interno de sus aplicaciones para atacarlo, o un usuario puede cambiar la URL para ingresar a una base de datos que no debe ver.

Usamos GUID para identificadores de bases de datos. Filtrarlos es mucho menos peligroso.

Si está utilizando ID enteros en su base de datos, puede facilitar que los usuarios vean datos que no deberían cambiar las variables qs.

Por ejemplo, un usuario podría cambiar fácilmente el parámetro id en este qs y ver / modificar datos que no deberían http: // someurl? Id = 1

Cuando envía identificadores de bases de datos a su cliente, se ve obligado a verificar la seguridad en ambos casos. Si mantiene las identificaciones en su sesión web, puede elegir si desea / necesita hacerlo, lo que significa potencialmente menos procesamiento.

Intenta constantemente delegar cosas a su control de acceso;) Esto puede ser el caso en su aplicación, pero nunca he visto un sistema de fondo tan consistente en toda mi carrera. La mayoría de ellos tienen modelos de seguridad que fueron diseñados para uso no web y algunos han agregado roles adicionales a título póstumo, y algunos de ellos se han incluido fuera del modelo de seguridad central (porque el rol se agregó en un contexto operativo diferente, por ejemplo). antes de la web).

Por lo tanto, utilizamos identificadores locales de sesión sintética porque oculta tanto como podemos escapar.

También está el problema de los campos de clave no enteros, que pueden ser el caso de valores enumerados y similares. Puede intentar desinfectar esos datos, pero es probable que termine como pequeñas tablas de bobby drop .