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.
Usar connection strings 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 sementes de um registro DNS SRV. Sua string de conexão não precisa de atualizações quando os hosts subjacentes mudam.
Aviso
Os drivers confiam nos resultados de pesquisa SRV que compartilham o mesmo domínio pai que o nome de host da semente original. Por exemplo, uma pesquisa para foo.example.com pode retornar node1.foo.example.com. Ela também pode retornar node1.example.com, que compartilha o domínio pai example.com mesmo que não esteja em foo.example.com.
Um servidor DNS mal-intencionado ou comprometido pode tentar redirecionar seu aplicação para um host controlado por um invasor durante a configuração da conexão. A restrição do domínio pai limita esse risco. Verifique se o domínio pai do seu nome de host de semente se resolve apenas para hosts em seu cluster ou para clusters controlados pela mesma entidade confiável.
Para saber mais, consulte Formato de conexão SRV e cadeias de conexão no manual do MongoDB Server .
Validar entrada não confiável 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 um único documento por nome, esse filtro corresponde a todos os documento com um camponame 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 documento digitado:
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 construtor trata user_supplied_name como um valor em vez de como parte de uma string para analisar, o valor não pode alterar a estrutura da query.
Construir queries como documentos BSON em vez de strings evita a tradicional injeção de SQL, pois os invasores não têm query string para manipular. Para saber mais, consulte Perguntas frequentes: Fundamentos do MongoDB no manual do MongoDB Server . Para saber mais sobre os tipos e conversões de Extended JSON, consulte MongoDB Extended JSON no manual do MongoDB Server .
Restringir execução de JavaScript no servidor
O MongoDB oferece suporte a operadores e comandos que executam JavaScript, incluindo $where, $function, $accumulator e mapReduce. Quando seu aplicação cria uma dessas expressões a partir da entrada do usuário, o servidor executa essa entrada como código. Esse comportamento cria a mesma classe de risco que passar uma entrada não confiável para uma função eval no código do aplicação .
Para reduzir esse risco, siga estas recomendações:
Evite a concatenação de strings: Não crie expressões
$where, corpos$functionou funções$accumulatorconcatenando 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.Desative os scripts do lado do servidor: desative os scripts do lado do servidor se o seu aplicação não usar
$where,$function,$accumulatoroumapReduce. Defina a opção de configuraçãosecurity.javascriptEnabledcomofalseou inicie o processomongodoumongose passe a opção--noscripting.
Para saber mais sobre como proteger a execução do JavaScript no servidor,consulte Executar o MongoDB com opções de configuração seguras.
Para saber mais sobre o operador $where, consulte $where no manual do MongoDB Server .
Informações adicionais
Para obter uma lista das melhores práticas sobre a proteção de implementações autogerenciadas, consulte a Lista de verificação de segurança no manual do MongoDB Server .