Esta página descreve as melhores práticas para desenvolver seu aplicação ao usar bibliotecas de cliente do 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 aplicação lida com entradas não confiáveis.
Usar connection strings SRV
Use o formato de string de conexão mongodb+srv:// em vez do formato mongodb:// padrão quando seu sistema permitir isso. O formato +srv habilita automaticamente o TLS (Transport Layer Security) para a conexão, criptografando o tráfego entre seu aplicação e o sistema 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 de cliente oferecem um método de conveniência que converte uma string JSON em um documento BSON , por exemplo, por meio de JSON estendido. Se seu aplicação passar o documento resultante para uma query, atualização ou comando sem validação, um invasor poderá alterar o significado dessa operação.
Considere um endpoint de API que aceita um corpo de solicitação JSON e espera um campo name contendo um valor de string. Suponha que o endpoint converta o corpo da solicitação em BSON e use o resultado em um filtro de query sem validação. Um invasor pode enviar um objeto no lugar 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 C++ a seguir cria um filtro de consulta usando a concatenação de cadeia de caracteres para inserir um valor fornecido pelo usuário em uma cadeia de caracteres 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 uma aspa dupla ou um operador JSON, a string resultante poderá escapar do valor de campo pretendido e injetar sintaxe de consulta arbitrária.
Esse risco se aplica sempre que uma string JSON se origina de um usuário, de uma solicitação de API ou de outra fonte que seu aplicação não controla. Para reduzir esse risco, verifique e valide a entrada não confiável antes de convertê-la em BSON. Muitos dos drivers fornecem uma API de documento digitado ou um construtor de query que você pode usar para criar queries. Você também pode aplicar um JSON schema ou camada de validação semelhante dentro de seu aplicação 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, pois 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 .