Mejores prácticas de las Librerías de clientes

Utilice cadenas de conexión SRV

Utilice el formato de cadena de conexión mongodb+srv:// en lugar del formato estándar mongodb:// cuando su implementación lo admita. El formato +srv habilita automáticamente Transport Layer Security (TLS) para la conexión, cifrando el tráfico entre su aplicación y su implementación de MongoDB por defecto. El formato estándar no habilita TLS a menos que lo configure explícitamente.

El formato +srv también resuelve la lista completa de hosts de inicialización de un registro DNS SRV. Su cadena de conexión no necesita actualizaciones cuando cambian los host subyacentes.

Para aprender más, consulta Formato de conexión SRV y cadenas de conexión en el manual de MongoDB Server.

Validar la entrada no confiable antes de convertir JSON a BSON

Muchas Librerías de clientes ofrecen un método práctico que convierte un string JSON en un documento BSON, por ejemplo, mediante JSON extendido. Si su aplicación pasa el documento resultante a una query, actualizar o comando sin validación, un atacante puede cambiar el significado de esa operación.

Considere un endpoint de API que acepta un cuerpo de solicitud JSON y espera un campo name que contenga un valor string. Suponga que el endpoint convierte el cuerpo de la solicitud a BSON y utiliza el resultado en un filtro de query sin validación. Un atacante puede enviar un objeto en lugar del string esperado, como se muestra en el siguiente ejemplo:

{"name": {"$ne": null}}

MongoDB evalúa el campo $ne como un operador del query en lugar de como un valor literal. En lugar de hacer coincidir un único documento por nombre, este filtro hace coincidir cada documento con un campo name no nulo, exponiendo más datos de lo previsto.

Concatenar datos no confiables en una string JSON antes de convertirlos a BSON crea el mismo riesgo. El siguiente ejemplo de C++ crea un filtro de query utilizando la concatenación de string para insertar un valor proporcionado por el usuario en una string JSON:

std::string json_query =
    "{ \"name\": \"" + user_supplied_name + "\" }";
bsoncxx::document::value filter =
    bsoncxx::from_json(json_query);
mongocxx::cursor cursor = collection.find(filter.view());

Si user_supplied_name contiene una comilla double o un operador JSON, el string resultante puede escapar el valor de campo previsto e inyectar sintaxis de query arbitraria.

Este riesgo se aplica siempre que un string JSON se origine de un usuario, una solicitud de API u otra fuente que su aplicación no controle. Para reducir este riesgo, compruebe el tipo y valide la entrada no confiable antes de convertirla a BSON. Muchos de los driver proporcionan una API de documento tipado o un desarrolladores de query que puede usar para compilar query. También puede aplicar un JSON schema o una capa de validación similar dentro de su aplicación antes de aceptar la entrada JSON para la conversión.

El siguiente ejemplo compila el mismo filtro que el ejemplo de concatenación anterior, pero en su lugar utiliza un generador de documentos con tipo:

bsoncxx::builder::basic::document filter_builder;
filter_builder.append(
    bsoncxx::builder::basic::kvp("name", user_supplied_name));
mongocxx::cursor cursor = collection.find(filter_builder.view());

Dado que los desarrolladores tratan user_supplied_name como un valor en lugar de como parte de una string que analizar, el valor no puede alterar la estructura de la query.

La creación de query como documentos BSON en lugar de strings evita la inyección SQL tradicional, ya que los atacantes no tienen un string del query que manipular. Para obtener más información, consulte Preguntas frecuentes: Fundamentos de MongoDB en el manual de MongoDB Server. Para aprender más sobre los tipos y las conversiones de JSON extendido, consulta MongoDB JSON extendido en el manual de MongoDB Server.

Restringir la ejecución de JavaScript del lado del servidor

MongoDB admite operadores y comandos que ejecutan JavaScript, incluidos $where, $function, $accumulator y mapReduce. Cuando su aplicación compila una de estas expresiones a partir de la entrada del usuario, el servidor ejecuta esa entrada como código. Este comportamiento crea la misma clase de riesgo que pasar una entrada no fiable a una función eval en el código de la aplicación.

Para reducir este riesgo, siga estas recomendaciones:

• Evite la concatenación de strings: No compile expresiones $where, cuerpos $function o funciones $accumulator concatenando o interpolando entradas no confiables en un string de JavaScript. Utilice operadores de query estándar en su lugar, ya que MongoDB los evalúa sin ejecutar JavaScript.

• Deshabilitar script del lado del servidor: Deshabilite el script del lado del servidor si su aplicación no utiliza $where, $function, $accumulator o mapReduce. Establezca la opción de configuración security.javascriptEnabled en false, o inicie el proceso mongod o mongos y pase la opción --noscripting.

Para aprender más sobre cómo proteger la ejecución de JavaScript del lado del servidor, consulte Ejecutar MongoDB con opciones de configuración seguras.

Para aprender más sobre el operador $where, consulta $where en el manual del servidor de MongoDB Server.

Información Adicional

Para obtener una lista de las mejores prácticas sobre la seguridad de las implementaciones autogestionadas, consulte la Lista de comprobación de seguridad en el manual de MongoDB Server.