MongoDB: ¿es seguro usar la identificación del documento "en público"?

Question

Me gustan mucho los ID de MongoDB generados automáticamente. Ellos son realmente útiles.

Sin embargo, ¿es posible utilizarlos públicamente?

Digamos que hay una colección de publicaciones, y la página/posts que toma el parámetro id (algo así como/posts/4d901acd8df94c1fe600009b) y muestra información al respecto.

De esta manera el usuario/pirata informático conocerá el identificador de objeto real del documento. ¿Está bien o no es seguro?

Gracias

Answer 1

Sez here, los ID generados automáticamente incluyen una ID de máquina de 3 bytes (presumiblemente un hash de la dirección MAC). No es inconcebible que alguien pueda descifrar cosas sobre su red interna comparando esos tres bytes en varios identificadores, pero a menos que esté trabajando para el Pentágono no parece que valga la pena preocuparse (es mucho más probable que sea vulnerable a algo más aburrido como un Apache mal configurado).

Aparte de eso, Epcylon tiene razón; no hay nada intrínsecamente inseguro sobre la exposición de los identificadores a través de las URL. Si es feo es otro asunto, por supuesto. Puedes basarlos64 para hacerlos más cortos (he estado pensando en esto yo mismo), pero luego está el hecho extraño de que son casi la mitad de lo mismo ...

Answer 2

no tengo experiencia con MongoDB en un entorno de producción, por lo que no toman mi respuesta como la verdad, pero no puedo imaginar por qué no debería ser seguro.

Comparar con una columna de tipo Auto-ID en un RDBMS. Expones a los que están fuera todo el tiempo, no sé de ninguna razón para no hacer lo mismo con los ID de MongoDB.

Como siempre, la seguridad debe ser en la validación de su entrada y no dejar a nadie cerca de su base de datos sin la protección adecuada. Hágalo correctamente y no debería importar si saben cómo elegir un objeto en particular en su base de datos, ya que todavía no pueden hacer nada con él.

Answer 3

No es más inseguro que usando el valor de la identificación de incremento automático de MySql. No es una violación de seguridad de ninguna manera.

Answer 4

Quizás piense en esto más como privacidad que security issue.

Estoy enfrentando exactamente el mismo problema. Al almacenar el contenido contribuido por el usuario en directorios a los que se puede acceder desde la web según el ID generado por Mongo, existe el riesgo de que esos ID sean predecibles de que un usuario pueda acceder al contenido de otro usuario.

Creo que el consejo de los demás es la ruta correcta: conocer la URL del contenido privado específico del usuario no debería ser suficiente para acceder a él. Un intento de acceso debe verificar que el usuario coincidente realiza la solicitud.

tengo la intención de hacerlo en Symfony2 almacenando el contenido del usuario fuera de la raíz de la web, a continuación, permitir el acceso a la misma a través de una nueva ruta/controlador que antes de pasar a la respuesta validará alguna información de identificación sobre el usuario.

Answer 5

Pensé que mongodb _id se basaba en una fecha y una dirección de corte y otras cosas que preferiría mantener en privado.

Si le preocupa, podría valer la pena encriptar mongoids y usar el resultado como un identificador del lado del cliente (y luego des-encriptar cuando vuelvan las solicitudes).

Si la clave de cifrado se basa parcialmente en algún atributo único del usuario o sesión en cuestión, eso dificulta que los usuarios accedan al contenido cuando no deberían hacerlo.

¡Obviamente sigue siendo importante validar al usuario por otros medios!

Answer 6

1. If id da un enlace al contenido "no listado" que solo requiere enlace, es un problema de privacidad.

2. Si id da un enlace al contenido que está bajo el inicio de sesión de usuario, no hay problema.

No importa si se trata de MongoDb, SQL o cualquier otra identificación. Id es la clave de los datos. Si esta clave es lo único que necesita para ver el contenido que no debería, eso es un problema. Para tal situación, genera id.