En mi aplicación Angular, uso el ID de MongoDB en las URL. ¿Hay algún riesgo de seguridad para esto?
¿Debería usar un contador en su lugar, y luego en mi base de datos tengo algún tipo de colección que vincula este contador a la ID real? Entonces, en lugar de mysite.com/story/56ede7fsdfdsfdsfs2a7283 , usaría mysite.com/story/32 ?
No se me ocurre ningún riesgo real de seguridad al exponer la identificación de mongoDB (en comparación con otra identificación del contador), aparte de exponer el tiempo de creación según el servidor a los usuarios. Tener la clave principal de mongo frente a otra clave única (como un contador) no debería hacer una diferencia en términos de exposición.
Por supuesto, debes tener en cuenta que el mongo _id consiste en:
- un valor de 4 bytes que representa los segundos desde la época de Unix,
- un identificador de máquina de 3 bytes,
- un ID de proceso de 2 bytes, y
- un contador de 3 bytes, que comienza con un valor aleatorio.
y posiblemente no desee exponer parte de esta información a sus usuarios (como el tiempo de creación).
Entonces, cuando tienes el id 56ede7f0dfdsfdsfs2a7283 (que tiene un dígito no hexadecimal allí s y parece faltar un dígito hexadecimal al final, debe ser de 12 bytes o 24 hex (0-9a) -f) dígitos, por lo que he reemplazado la 's' con '0'), puedo decir desde 56ede7f0 que se creó en 2016-03-19T23:59:44.000Z . (Consulte, por ejemplo, enlace o pruebe: ObjectId("56ede7f0dfd0fd0f20a72830").getTimestamp() en el shell).
La OWASP menciona que simplemente tener cualquier tipo de identificador directo puede ser malo, como se explica en 10 principales referencias directas de objetos inseguros de 2007 y Entradas principales 10 Referencias de objeto directo 2010-A4-Insecure . Un atacante que pueda descubrir cómo explotar una referencia tan directa tendrá mucho más poder del que debería.
El OWASP realmente recomienda usar un valor de índice, como ha preguntado aquí, pero estos pueden venir con sus propios problemas. Darles a los atacantes una forma fácil y fácil de acceder a todos sus datos de forma secuencial puede permitirles leer, actualizar o incluso eliminar su base de datos completa si encuentran una vulnerabilidad de autenticación o escalada de privilegios.
En el mundo real, estas ocurrencias han ocurrido antes. Al igual que varios volcados de direcciones de correo electrónico obtenidos de los servicios que utilizan una clave principal simple en una página de restablecimiento de contraseña. O sistémicamente tener todos sus mensajes eliminados del servicio. La lista puede continuar, pero el punto es, si decide utilizar un campo de incremento automático como clave principal, asegúrese de que todas las páginas que usan esa ID validen la solicitud para asegurarse de que ( a) el usuario tiene permiso suficiente, y (b) la solicitud no se ha falsificado, probablemente a través de la inclusión de tokens de falsificación de solicitud en el sitio, valores esencialmente únicos que verifican que la solicitud es legítima.
Esto expone la metainformación en el ID de MongoDB como se indica en la respuesta de dr jimbob , que es un problema de seguridad en algunos aspectos.
Otra forma de publicar esta pregunta es
¿Cuál es la mejor práctica para no exponer metainformación sobre las entradas en mi base de datos en enlaces y URI?
La respuesta a esa pregunta es simple: Use un campo de identificador único para la entrada que no esté vinculada a ninguna metainformación. Estos pueden generarse fácilmente, verificarse contra otras entradas, y si se encuentra una colisión, genere otra. Luego, puede almacenar esto en un hash / índice / cualquier sistema que MongoDB use para encontrar estos documentos más rápido.
Sin embargo, esto no se aplica a las personas que las comparten en las redes sociales, así que asegúrate de que tu modelo de seguridad tenga eso en cuenta y evita que las personas vean cosas que no deberían.
Regalar información en la URL
Una URL puede ser accesible incluso para una persona que se supone que no debe tener acceso a la página real a la que conduce. Después de que todas las URL puedan aparecer en enlaces en toda la web o filtrarse a través de los encabezados de los remitentes. Por lo tanto, no debe haber información confidencial en la URL.
El ID de Mongo contiene información sobre la hora en que se creó el objeto (desde la primera parte). El contador solo contiene información sobre en qué orden se crearon los objetos.
El contador también proporciona información sobre cuántos objetos hay en total (consulte el problema del tanque alemán ). Pero también lo hace la identificación de Mongo, ya que la última parte es un contador global. Comienza desde un número aleatorio, por lo que transmite menos información, pero un atacante con muchas URL aún puede estimar el número total de documentos.
Ataques de enumeración
Si las URL son secuenciales, es fácil para un atacante obtener una lista de todos los recursos. Esto se llama un ataque de enumeración.
Para el contador esto es obviamente fácil de hacer. Para el ID de Mongo es más difícil, ya que hay que adivinar qué objetos de milisegundos se crearon. Si tiene una vaga idea sobre la hora en que se crean los objetos, aún podría hacerlo con fuerza bruta.
Conclusión
Si le preocupa entregar información sobre sus documentos en las URL o permitir que los usuarios enumeren todos los documentos, ambos enfoques son bastante malos. Si no lo eres, ambos enfoques están bien.
Una tercera solución
Si los problemas anteriores le preocupan, puede usar un ID aleatorio en su lugar. Use un espacio grande para disminuir la probabilidad de colisiones, y maneje algunos errores para que las cosas no se rompan si tiene mala suerte.
La ID podría almacenarse como _id (puede anular el valor predeterminado) o en un campo llamado url_id o algo así. Ponga un índice de hash único en él para hacer búsquedas rápidas.
Lea otras preguntas en las etiquetas web-application mongodb