Share via

Considerações de segurança (Entity Framework)

  • Artigo

Este tópico descreve considerações de segurança específicas para desenvolver, implantar e executar aplicativos do Entity Framework. Você também deve seguir as recomendações para criar aplicativos .NET Framework seguros. Para obter mais informações, consulte Visão geral de segurança.

Considerações gerais de segurança

As considerações de segurança a seguir se aplicam a todos os aplicativos que usam o Entity Framework.

Use apenas provedores de fonte de dados confiáveis.

Para se comunicar com a fonte de dados, um provedor deve fazer o seguinte:

  • Receba a cadeia de conexão do Entity Framework.

  • Traduza a árvore de comandos para a linguagem de consulta nativa da fonte de dados.

  • Monte e devolva conjuntos de resultados.

Durante a operação de logon, as informações baseadas na senha do usuário são passadas para o servidor por meio das bibliotecas de rede da fonte de dados subjacente. Um provedor mal-intencionado pode roubar credenciais de usuário, gerar consultas maliciosas ou adulterar o conjunto de resultados.

Criptografe sua conexão para proteger dados confidenciais.

O Entity Framework não lida diretamente com a criptografia de dados. Se os usuários acessarem dados em uma rede pública, seu aplicativo deverá estabelecer uma conexão criptografada com a fonte de dados para aumentar a segurança. Para obter mais informações, consulte a documentação relacionada à segurança da sua fonte de dados. Para obter uma fonte de dados do SQL Server, consulte Criptografando conexões com o SQL Server.

Proteja a cadeia de conexão.

Proteger o acesso à sua fonte de dados é um dos objetivos mais importantes ao proteger um aplicativo. Uma cadeia de conexão apresenta uma vulnerabilidade potencial se não estiver protegida ou se for construída incorretamente. Quando você armazena informações de conexão em texto sem formatação ou as mantém na memória, corre o risco de comprometer todo o sistema. A seguir estão os métodos recomendados para proteger cadeias de conexão:

  • Use a Autenticação do Windows com uma fonte de dados do SQL Server.

    Quando você usa a Autenticação do Windows para se conectar a uma fonte de dados do SQL Server, a cadeia de conexão não contém informações de logon e senha.

  • Criptografe seções do arquivo de configuração usando a configuração protegida.

    ASP.NET fornece um recurso chamado configuração protegida que permite criptografar informações confidenciais em um arquivo de configuração. Embora projetado principalmente para ASP.NET, você também pode usar a configuração protegida para criptografar seções de arquivos de configuração em aplicativos do Windows. Para obter uma descrição detalhada dos novos recursos de configuração protegida, consulte Criptografando informações de configuração usando a configuração protegida.

  • Armazene cadeias de conexão em arquivos de configuração seguros.

    Você nunca deve incorporar cadeias de conexão em seu código-fonte. Você pode armazenar cadeias de conexão em arquivos de configuração, o que elimina a necessidade de incorporá-las no código do seu aplicativo. Por padrão, o Assistente de Modelo de Dados de Entidade armazena cadeias de conexão no arquivo de configuração do aplicativo. Você deve proteger esse arquivo para impedir o acesso não autorizado.

  • Use construtores de cadeias de conexão ao criar conexões dinamicamente.

    Se você precisar construir cadeias de conexão em tempo de execução, use a EntityConnectionStringBuilder classe. Essa classe do construtor de cadeias de caracteres ajuda a evitar ataques de injeção de cadeia de conexão validando e escapando de informações de entrada inválidas. Para obter mais informações, consulte Como criar uma cadeia de conexão EntityConnection. Use também a classe apropriada do construtor de cadeias de caracteres para construir a cadeia de conexão da fonte de dados que faz parte da cadeia de conexão do Entity Framework. Para obter informações sobre construtores de cadeias de conexão para provedores de ADO.NET, consulte Construtores de cadeias de conexão.

Para obter mais informações, consulte Protegendo informações de conexão.

Não exponha um EntityConnection a usuários não confiáveis.

Um EntityConnection objeto expõe a cadeia de conexão da conexão subjacente. Um usuário com acesso a um EntityConnection objeto também pode alterar a ConnectionState conexão subjacente. A EntityConnection classe não é thread safe.

Não passe conexões fora do contexto de segurança.

Depois que uma conexão for estabelecida, você não deve passá-la para fora do contexto de segurança. Por exemplo, um thread com permissão para abrir uma conexão não deve armazenar a conexão em um local global. Se a conexão estiver disponível em um local global, outro thread mal-intencionado poderá usar a conexão aberta sem ter essa permissão explicitamente concedida a ele.

Lembre-se de que as informações de logon e as senhas podem estar visíveis em um despejo de memória.

Quando as informações de logon e senha da fonte de dados são fornecidas na cadeia de conexão, essas informações são mantidas na memória até que a coleta de lixo recupere os recursos. Isso torna impossível determinar quando uma cadeia de caracteres de senha não está mais na memória. Se um aplicativo falhar, um arquivo de despejo de memória pode conter informações de segurança confidenciais, e o usuário que executa o aplicativo e qualquer usuário com acesso administrativo ao computador pode exibir o arquivo de despejo de memória. Use a Autenticação do Windows para conexões com o Microsoft SQL Server.

Conceda aos usuários apenas as permissões necessárias na fonte de dados.

Um administrador de fonte de dados deve conceder apenas as permissões necessárias aos usuários. Embora o Entity SQL não ofereça suporte a instruções DML que modificam dados, como INSERT, UPDATE ou DELETE, os usuários ainda podem acessar a conexão com a fonte de dados. Um usuário mal-intencionado pode usar essa conexão para executar instruções DML no idioma nativo da fonte de dados.

Execute aplicativos com as permissões mínimas.

Quando você permite que um aplicativo gerenciado seja executado com permissão de confiança total, o .NET Framework não limita o acesso do aplicativo ao seu computador. Isso pode permitir que uma vulnerabilidade de segurança em seu aplicativo comprometa todo o sistema. Para usar a segurança de acesso ao código e outros mecanismos de segurança no .NET Framework, você deve executar aplicativos usando permissões de confiança parcial e com o conjunto mínimo de permissões necessárias para permitir que o aplicativo funcione. As seguintes permissões de acesso ao código são as permissões mínimas de que seu aplicativo Entity Framework precisa:

Para obter mais informações, consulte Segurança de acesso ao código e ADO.NET.

Não instale aplicações não fidedignas.

O Entity Framework não impõe nenhuma permissão de segurança e invocará qualquer código de objeto de dados fornecido pelo usuário em processo, independentemente de ser confiável ou não. Certifique-se de que a autenticação e autorização do cliente é realizada pelo armazenamento de dados e pelo seu aplicativo.

Restrinja o acesso a todos os arquivos de configuração.

Um administrador deve restringir o acesso de gravação a todos os arquivos que especificam a configuração de um aplicativo, incluindo enterprisesec.config, security.config, machine.conf e o arquivo de <configuração do aplicativo application>.exe.config.

O nome invariante do provedor é modificável no app.config. O aplicativo cliente deve assumir a responsabilidade de acessar o provedor subjacente por meio do modelo de fábrica do provedor padrão usando um nome forte.

Restrinja as permissões para os arquivos de modelo e mapeamento.

Um administrador deve restringir o acesso de gravação aos arquivos de modelo e mapeamento (.edmx, .csdl, .ssdl e .msl) apenas aos usuários que modificam o modelo ou mapeamentos. O Entity Framework só requer acesso de leitura a esses arquivos em tempo de execução. Um administrador também deve restringir o acesso à camada de objeto e aos arquivos de código-fonte de exibição pré-compilados gerados pelas ferramentas do Modelo de Dados de Entidade.

Considerações de segurança para consultas

As seguintes considerações de segurança se aplicam ao consultar um modelo conceitual. Essas considerações se aplicam a consultas Entity SQL usando EntityClient e a consultas de objeto usando métodos LINQ, Entity SQL e construtor de consultas.

Previna ataques de injeção de SQL.

Os aplicativos freqüentemente recebem entrada externa (de um usuário ou outro agente externo) e executam ações com base nessa entrada. Qualquer entrada direta ou indiretamente derivada do usuário ou de um agente externo pode ter conteúdo que usa a sintaxe do idioma de destino para executar ações não autorizadas. Quando a linguagem de destino é uma Structured Query Language (SQL), como Transact-SQL, essa manipulação é conhecida como um ataque de injeção de SQL. Um usuário mal-intencionado pode injetar comandos diretamente na consulta e soltar uma tabela de banco de dados, causar uma negação de serviço ou alterar a natureza da operação que está sendo executada.

  • Ataques de injeção de SQL de entidade:

    Os ataques de injeção de SQL podem ser executados no Entity SQL fornecendo entrada mal-intencionada para valores que são usados em um predicado de consulta e em nomes de parâmetros. Para evitar o risco de injeção de SQL, você nunca deve combinar a entrada do usuário com o texto do comando Entity SQL.

    As consultas SQL de entidade aceitam parâmetros em todos os lugares em que literais são aceitos. Você deve usar consultas parametrizadas em vez de injetar literais de um agente externo diretamente na consulta. Você também deve considerar o uso de métodos do construtor de consultas para construir com segurança o Entity SQL.

  • Ataques de injeção LINQ to Entities:

    Embora a composição da consulta seja possível no LINQ to Entities, ela é executada por meio da API do modelo de objeto. Ao contrário das consultas Entity SQL, as consultas LINQ to Entities não são compostas usando manipulação ou concatenação de cadeia de caracteres e não são suscetíveis a ataques tradicionais de injeção de SQL.

Evite conjuntos de resultados muito grandes.

Um conjunto de resultados muito grande pode fazer com que o sistema cliente seja desligado se o cliente estiver executando operações que consomem recursos proporcionais ao tamanho do conjunto de resultados. Conjuntos de resultados inesperadamente grandes podem ocorrer nas seguintes condições:

  • Em consultas em um banco de dados grande que não incluem condições de filtro apropriadas.

  • Em consultas que criam junções cartesianas no servidor.

  • Em consultas SQL de entidade aninhadas.

Ao aceitar a entrada do usuário, você deve certificar-se de que a entrada não pode fazer com que os conjuntos de resultados se tornem maiores do que o sistema pode manipular. Você também pode usar o Take método em LINQ to Entities ou o operador LIMIT em Entity SQL para limitar o tamanho do conjunto de resultados.

Evite retornar resultados IQueryable ao expor métodos a chamadores potencialmente não confiáveis.

Evite retornar IQueryable<T> tipos de métodos expostos a chamadores potencialmente não confiáveis pelos seguintes motivos:

  • Um consumidor de uma consulta que expõe um IQueryable<T> tipo pode chamar métodos no resultado que expõem dados seguros ou aumentam o tamanho do conjunto de resultados. Por exemplo, considere a seguinte assinatura de método:

    public IQueryable<Customer> GetCustomer(int customerId)

    Um consumidor dessa consulta poderia chamar .Include("Orders") o retornado IQueryable<Customer> para recuperar dados que a consulta não pretendia expor. Isso pode ser evitado alterando o tipo de retorno do método para IEnumerable<T> e chamando um método (como .ToList()) que materializa os resultados.

  • Como IQueryable<T> as consultas são executadas quando os resultados são iterados, um consumidor de uma consulta que expõe um IQueryable<T> tipo pode capturar exceções lançadas. As exceções podem conter informações não destinadas ao consumidor.

Considerações de segurança para entidades

As seguintes considerações de segurança se aplicam ao gerar e trabalhar com tipos de entidade.

Não compartilhe um ObjectContext entre domínios de aplicativo.

Compartilhar um ObjectContext com mais de um domínio de aplicativo pode expor informações na cadeia de conexão. Em vez disso, você deve transferir objetos serializados ou gráficos de objeto para o outro domínio de aplicativo e, em seguida, anexar esses objetos a um ObjectContext nesse domínio de aplicativo. Para obter mais informações, consulte Serializando objetos.

Evite violações de segurança de tipo.

Se a segurança do tipo for violada, o Entity Framework não pode garantir a integridade dos dados nos objetos. Violações de segurança de tipo podem ocorrer se você permitir que aplicativos não confiáveis sejam executados com segurança de acesso a código de confiança total.

Lidar com exceções.

Acesse métodos e propriedades de um ObjectContext dentro de um bloco try-catch. A captura de exceções impede que exceções não tratadas exponham entradas nas informações do ObjectStateManager modelo ou (como nomes de tabela) aos usuários do seu aplicativo.

Considerações de segurança para aplicativos ASP.NET

Você deve considerar o seguinte ao trabalhar com caminhos em aplicativos ASP.NET.

Verifique se o host executa verificações de caminho.

Quando a |DataDirectory| cadeia de caracteres de substituição (incluída em símbolos de pipe) é usada, ADO.NET verifica se o caminho resolvido é suportado. Por exemplo, ".." não é permitido atrás de DataDirectory. Essa mesma verificação para resolver o operador raiz do aplicativo Web (~) é executada pelo processo que hospeda ASP.NET. O IIS executa essa verificação; no entanto, hosts diferentes do IIS podem não verificar se o caminho resolvido é suportado. Você deve saber o comportamento do host no qual você implanta um aplicativo do Entity Framework.

Não faça suposições sobre nomes de caminhos resolvidos.

Embora os valores para os quais o operador raiz (~) e a DataDirectory cadeia de caracteres de substituição resolvam devam permanecer constantes durante o tempo de execução do aplicativo, o Entity Framework não restringe o host de modificar esses valores.

Verifique o comprimento do caminho antes da implantação.

Antes de implantar um aplicativo do Entity Framework, você deve garantir que os valores do operador raiz (~) e DataDirectory da cadeia de caracteres de substituição não excedam os limites do comprimento do caminho no sistema operacional. ADO.NET provedores de dados não garantem que o comprimento do caminho esteja dentro de limites válidos.

Considerações de segurança para metadados ADO.NET

As seguintes considerações de segurança se aplicam ao gerar e trabalhar com arquivos de modelo e mapeamento.

Não exponha informações confidenciais através do registo.

ADO.NET componentes do serviço de metadados não registram nenhuma informação privada. Se houver resultados que não podem ser retornados devido a restrições de acesso, os sistemas de gerenciamento de banco de dados e sistemas de arquivos devem retornar zero resultados em vez de gerar uma exceção que possa conter informações confidenciais.

Não aceite objetos MetadataWorkspace de fontes não confiáveis.

Os aplicativos não devem aceitar instâncias da MetadataWorkspace classe de fontes não confiáveis. Em vez disso, você deve construir e preencher explicitamente um espaço de trabalho a partir dessa fonte.

Consulte também