Melhores práticas para bibliotecas cliente

Esta página descreve as melhores práticas para desenvolver seu aplicativo ao usar bibliotecas cliente MongoDB. Siga estas recomendações para reduzir o risco de ataques de injeção e outros problemas de segurança que podem surgir quando seu aplicativo lida com entrada não confiável.

Use strings de conexão SRV

Utilize o formato de string de conexão mongodb+srv:// em vez do formato padrão mongodb:// quando sua implantação o suportar. O formato +srv habilita automaticamente a Segurança da Camada de Transporte (TLS) para a conexão, criptografando o tráfego entre seu aplicativo e sua implantação do MongoDB por padrão. O formato padrão não habilita o TLS a menos que você o defina explicitamente.

O formato +srv também resolve a lista completa de hosts de semente a partir de um registro DNS SRV. Sua string de conexão não precisa de atualizações quando os hosts subjacentes mudam.

Aviso

Os driver confiam nos resultados da pesquisa SRV que compartilham o mesmo domínio pai que o nome de host de semente original. Por exemplo, uma pesquisa por foo.example.com pode retornar node1.foo.example.com. Também pode retornar node1.example.com, que compartilha o domínio pai example.com, embora não esteja em foo.example.com.

Um servidor DNS mal-intencionado ou comprometido pode tentar redirecionar seu aplicativo para um hospedar controlado por um invasor durante o configurar da conexão. A restrição do domínio pai limita esse risco. Verifique se o domínio pai do seu nome de hospedar inicial se resolve apenas para hospedar em seu cluster, ou para clusters controlados pela mesma entidade confiável.

To learn more, see SRV Connection Format and Connection Strings in the MongoDB Server manual.

Valide entradas não confiáveis antes de converter JSON em BSON

Muitas bibliotecas cliente oferecem um método de conveniência que converte uma string JSON em um documento BSON, por exemplo, por meio do Extended JSON. Se seu aplicativo passar o documento resultante para uma query, atualizar ou comando sem validação, um invasor poderá alterar o significado dessa operação.

Considere um ponto de extremidade de API que aceita um corpo de solicitação JSON e espera um campo name contendo um valor de string. Suponha que o ponto de extremidade converta o corpo da solicitação em BSON e use o resultado em um filtro de queries sem validação. Um invasor pode enviar um objeto em vez da string esperada, conforme mostrado no exemplo a seguir:

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

O MongoDB avalia o campo $ne como um operador de query em vez de um valor literal. Em vez de corresponder a um único documento por nome, este filtro corresponde a todos os documentos com um campo name não nulo, expondo mais dados do que o pretendido.

Concatenar entrada não confiável em uma string JSON antes de convertê-la em BSON cria o mesmo risco. O exemplo de C++ a seguir cria um filtro de queries usando concatenação de strings para inserir um valor fornecido pelo usuário em uma 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());

Se user_supplied_name contiver aspas double ou um operador JSON, a string resultante poderá escapar do valor de campo pretendido e injetar sintaxe de query arbitrária.

Esse risco se aplica sempre que uma string JSON se origina de um usuário, uma solicitação de API ou outra fonte que seu aplicativo não controla. Para reduzir esse risco, verifique o tipo e valide a entrada não confiável antes de convertê-la em BSON. Muitos dos drivers fornecem uma API de documento tipado ou um construtor de query que você pode usar para criar query. Você também pode aplicar um JSON schema ou uma camada de validação semelhante dentro do seu aplicativo antes de aceitar a entrada JSON para conversão.

O exemplo a seguir cria o mesmo filtro que o exemplo de concatenação anterior, mas usa um construtor de documentos tipados em vez disso:

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());

Como o construtores trata user_supplied_name como um valor em vez de parte de uma string a ser analisada, o valor não pode alterar a estrutura da query.

Building queries as BSON documents instead of strings avoids traditional SQL injection, since attackers have no query string to manipulate. To learn more, see FAQ: MongoDB Fundamentals in the MongoDB Server manual. To learn more about Extended JSON types and conversions, see MongoDB Extended JSON in the MongoDB Server manual.

Restringir a execução de JavaScript no servidor

MongoDB supports operators and commands that execute JavaScript, including $where, $function, $accumulator, and mapReduce. When your application builds one of these expressions from user input, the server executes that input as code. This behavior creates the same class of risk as passing untrusted input to an eval function in application code.

Para reduzir esse risco, siga estas recomendações:

Evite a concatenação de strings: Não crie expressões $where, corpos $function ou funções $accumulator concatenando ou interpolando entradas não confiáveis em uma string JavaScript. Em vez disso, use operadores de query padrão, já que o MongoDB os avalia sem executar JavaScript.
Disable server-side scripting: Disable server-side scripting if your application doesn't use $where, $function, $accumulator, or mapReduce. Set the security.javascriptEnabled configuration option to false, or start the mongod or mongos process and pass the --noscripting option.

To learn more about securing server-side JavaScript execution, see Run MongoDB with Secure Configuration Options.

To learn more about the $where operator, see $where in the MongoDB Server manual.

Informações adicionais

For a list of best practices on securing self-managed deployments, see the Security Checklist in the MongoDB Server manual.