Proteção de acesso a dados

Artigo
10/15/2014

A maioria dos aplicativos da Web ASP.NET envolvem Acesso a Dados.Muitos aplicativos coletam dados a serem armazenados em um banco de dados ou arquivo, e os dados a serem armazenados são frequentemente baseados nas informações provenientes de usuários.Porque os dados originais podem vir de fontes não confiáveis, porque as informações são armazenadas em um formato persistente, e você quer ter certeza de que que usuários não autorizados não possam acessar sua fonte de dados diretamente, você precisa prestar atenção especial aos problemas de segurança a cerca do Acesso a Dados.As informações deste tópico descrevem as práticas recomendadas que ajudarão a melhorar a segurança de Acesso a Dados no seu aplicativo ASP.NET.

Enquanto seguir codificação e práticas recomendadas podem melhorar a segurança do seu aplicativo, também é importante que você continuamente mantenha o servidor de web atualizado com as atualizações de segurança mais recentes do Microsoft Windows e Serviços de Informações da Internet (IIS), assim como quaisquer atualizações de segurança para o Microsoft SQL Server ou outros aplicativos de fontes de dados.

Informações mais detalhadas sobre as práticas recomendadas para escrever código seguro e proteger aplicativos pode ser encontrada no catálogo "Writing Secure Code" de Michael Howard e David LeBlanc, ou a orientação fornecida noPadrões e práticas da Microsoft Site da Web.

Protegendo o acesso a uma fonte de dados

As seções a seguir fornecem informações de como proteger diferentes aspectos de Acesso a Dados.

Sequências de conexão

Conectando-se a um banco de dados requer um sequência de conexão.Como sequências de conexão podem conter dados confidenciais, você deve seguir estas diretrizes:

Não armazene sequências de conexão em uma página.Por exemplo, evite configurar sequências de conexão como propriedades declarativas do controle SqlDataSource ou outros controles de fonte de dados.Em vez disso, armazene sequências de conexão no arquivo web.config do site.Para um exemplo, consulte Como: Proteger seqüências de conexão quando usando controles de fontes de dados.
Não armazene sequências de conexão como texto sem-formatação.Para manter a conexão ao seu servidor de dados protegida, é recomendável que você criptografe informações da sequência de conexão no arquivo de configuração usando Configuração Protegida.Para obter mais informações, consulte Criptografando informações de configuração usando configuração protegida.

Conectando-se ao SQL Server usando segurança integrada

Se possível, se conecte a uma instância de SQL Server usando segurança integrada em vez de usar um nome de usuário explícito senha.Isso ajuda a evitar a possibilidade da sequência de conexão ser comprometida e a ID de usuário e senha expostas.

É recomendável que você certifique-se que a identidade do processo que está executando o ASP.NET (por exemplo, o pool de aplicativos) é a conta do processo padrão ou uma conta de usuário restrito.Para obter mais informações, consulte ASP.NET Impersonation.

Em situações onde diferentes sites da Web se conectam a diferentes bancos de dados SQL Server, talvez não seja prático usar segurança integrada.Por exemplo, em sites de hospedagem da Web, a cada cliente é normalmente atribuído um banco de dados SQL Server diferente, mas todos os usuários usam o servidor Web como usuários anônimos.Em tais casos, você precisa usar credenciais explícitas para se conectar a uma instância de SQL Server.Certifique-se de que você armazene as credenciais de uma maneira segura, conforme descrito nesse tópico em sequências de conexão.

Permissões de banco de dados SQL Server

É recomendável que você atribua os privilégios mínimos para o ID do usuário que é usado para conectar aos bancos de dados SQL Server usados no seu aplicativo.

Restringir operações SQL

Os controles ligados a dados podem oferecer uma ampla variedade de operações de dados, incluindo selecionar, inserir, excluir e atualizar registros em tabelas de dados.É recomendável que você configure os controles de dados para executar a funcionalidade mínima que é necessária em uma página ou em seu aplicativo.Por exemplo, se um controle não deve permitir que os usuários excluam dados, não inclua uma consulta de exclusão com um controle de fonte de dados e não habilite a exclusão no controle.

SQL Server Express Edition.

Quando um processo anexa um banco de dados SQL Server Express Edition (arquivo .mdf), o processo deve ter permissões administrativas.Em geral, isso torna os bancos de dados SQL Server Express Edition impraticáveis para a produção sites porque o processo do ASP.NET não deve ser executado com privilégios administrativos.Portanto, use os bancos de dados SQL Server Express Edition somente nas seguintes circunstâncias:

Usar como um banco de dados de teste ao desenvolver o aplicativo da Web.Quando você estiver pronto para implantar seu aplicativo, você pode transferir o banco de dados do SQL Server Express Edition para uma instância de produção do SQL Server.
Use se você estiver executando um site da Web que pode usar representação e você pode controlar os privilégios do usuário representado.Na prática, essa estratégia é prática somente se o aplicativo é executado em uma rede local (não um site da Web pública).
Armazene o arquivo .mdf na pasta App_Data do site, porque o conteúdo da pasta não será ser retornado para solicitações http diretas.Você também deve mapear a extensão .mdf para ASP.NET no IIS e o HttpForbiddenHandler manipulador no ASP.NET usando o seguinte elemento no arquivo Web.config do site:
```
<httpHandlers>
  <add verb="*" path="*.mdf" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Para obter informações sobre como mapear uma extensão de nome de arquivo para o ASP.NET no IIS, consulte Como: Registrar manipuladores HTTP.

Bancos de dados do Microsoft Access

Os bancos de dados do Microsoft Access (arquivos .mdb) incluem menos recursos de segurança que os bancos de dados SQL Server.Bancos de dados do Access não são recomendados para a produção sites da Web.No entanto, se você tem razão para usar um arquivo .mdb como parte do seu aplicativo da Web, siga estas diretrizes:

Armazene o arquivo .mdb na pasta App_Data do site, porque o conteúdo da pasta não será retornado para solicitações http diretas.Você também deve MAP a extensão .mdb para ASP.NET no IIS e o HttpForbiddenHandler manipulador no ASP.NET usando o seguinte elemento no arquivo Web.config do site:
```
<httpHandlers>
  <add verb="*" path="*.mdb" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Para obter informações sobre como mapear uma extensão de nome de arquivo para o ASP.NET no IIS, consulte Como: Registrar manipuladores HTTP.
Adicione permissões apropriadas para a conta de usuário ou contas que estarão lendo e gravando no arquivo .mdb.Se o site oferece suporte a acesso anônimo, isso é geralmente a conta de usuário ASPNET local ou a conta NETWORK SERVICE.Porque o Access deve criar um arquivo .ldb para oferecer suporte de bloqueio, a conta de usuário deve ter permissões de gravação para a pasta que contém o arquivo .mdb.
Se o banco de dados estiver protegido com uma senha, não use o controle AccessDataSource para estabelecer uma conexão a ela, porque o controle AccessDataSource não oferece suporte à passagem de credenciais.Em vez disso, use o controle SqlDataSource com o provedor ODBC e passe as credenciais na sequência de conexão.Não se esqueça proteger o sequência de conexão conforme descrito nesse tópico em sequências de conexão.

Arquivos XML

Se você estiver armazenando dados em um arquivo XML, coloque o arquivo XML na pasta App_Data do site da Web, porque o conteúdo da pasta não vai ser retornado em resposta para direcionar solicitações http.

Proteção contra entrada de usuários maliciosos

Se o aplicativo aceita entradas de usuários, você precisará certificar-se que a entrada não contém conteúdo mal-intencionado que pode comprometer seu aplicativo.Entradas do usuário mal-intencionado podem ser usados para iniciar os seguintes ataques:

Injeção de script Um ataque de injeção de script tenta enviar script executável para o seu aplicativo com a intenção de fazer outros usuários executarem-no.Um típico ataque de injeção de script envia script para uma página que armazena o script em um banco de dados, para que outro usuário que visualize os dados execute o código inadvertidamente.
Injeção SQL Um ataque de injeção SQL tenta comprometer seu banco de dados (e possivelmente o computador no qual o banco de dados está sendo executado) criando comandos SQL que são executados em vez de, ou adicionadas a, os comandos que você criou no seu aplicativo.

Diretrizes gerais

Para todas as entradas de usuário, siga estas diretrizes:

Use controles de validação sempre que possível para limitar as entradas dos usuários para valores aceitáveis.
Sempre certifique que o valor da propriedade IsValid seja true antes de executar o código do servidor.Um valor de false significa que um ou mais controles de validação falharam uma verificação de validação.
Sempre execute validação do lado do servidor, mesmo se o navegador também esteja executando validação do lado do cliente, para se proteger contra usuários que ignorem validação do lado do cliente.Isso é especialmente verdadeiro para controles CustomValidator; não usam apenas lógica da validação do lado do cliente.
Sempre revalide a entrada do usuário na camada de negócios do aplicativo.Não confie no processo de chamada para fornecer dados seguros.Por exemplo, se você estiver usando o controle ObjectDataSource, adicione validação e codificação redundante para o objeto que executa as atualizações de dados.

Injeção de Script

Para evitar ataques de injeção de código de script, siga estas diretrizes:

Codifique a entrada do usuário com o método HtmlEncode, que transforma HTML em sua representação de texto (por exemplo, <b> torna-se &ltb>), e ajuda a impedir que a marcação seja executada em um navegador.
Ao usar objetos de parâmetro para passar entrada do usuário para uma consulta, adicione manipuladores para os eventos de pré-consulta do controle da fonte de dados e realize a codificação nesses eventos.Por exemplo, manipule o evento Inserting do controle SqlDataSource e no evento, codifique o valor do parâmetro antes da execução da consulta.
Se você estiver usando o controle GridView com campos acoplados, defina a propriedade HtmlEncode do objeto BoundField para true.Isso faz com que o controle GridView codifique as entradas do usuário quando a linha estiver em modo de edição.
Para controles que podem ser colocados em modo de edição, é recomendável que você use os modelos.Por exemplo, os controles GridView, DetailsView, FormView, DataList e Login podem exibir caixas de texto editável.No entanto, exceto para o controle GridView (consulte o ponto anterior), os controles não validam ou codificam HTML de entrada do usuário automaticamente.Portanto, é recomendável que você crie modelos para esses controles e no modelo, inclua um controle de entrada como um controle TextBox e adicione um controle de validação.Além disso, ao extrair o valor do controle, você deve codificá-lo.

Injeção SQL

Para evitar ataques de injeção SQL, siga estas diretrizes:

Não crie comandos SQL por concatenar sequências juntas, especialmente as sequências de caracteres que incluam a entrada de usuários.Em vez disso, use consultas parametrizadas ou procedimentos armazenados.
Se você estiver criando uma consulta parametrizada, use objetos de parâmetro para estabelecer os valores para os parâmetros.Para obter detalhes, consulte Usando parâmetros com o controle SqlDataSource e Usando parâmetros com controles de fonte de dados.

Criptografando dados de estado de exibição

Controles ligados a dados, como o controle GridView, às vezes precisam manter as informações que são consideradas confidenciais.Por exemplo, o controle GridView pode manter uma lista de teclas na propriedade DataKeys, mesmo que essa informação não esteja exibida.Entre idas, o controle armazena as informações em estado de exibição.

Informações de estado de exibição são codificadas e armazenadas com o conteúdo da página podem ser decodificado e expostos a uma fonte não desejada.Se você deve armazenar informações sigilosas em estado de exibição, você pode solicitar que a página criptografe dados do estado de exibição.Para criptografar os dados, defina a propriedade ViewStateEncryptionMode da página para true.

O cache

É recomendável que você evite armazenar informações sigilosas no objeto Cache quando a representação do cliente está ativada e os resultados de fonte de dados são recuperados com base na identidade do cliente.Se o cache estiver ativado, dados em cache para um único usuário podem ser exibidas por todos os usuários e informações confidenciais poderiam ser expostas a uma fonte indesejada.A representação do cliente é ativada quando o atributo impersonate do elemento de configuração identidade é definido como true e a identificação anônima está desativada para o aplicativo no servidor Web.

Partilhar via