Proteger cadeias de conexão e outras informações de configuração (C#)

por Scott Ltda

Baixar código ou baixar PDF

Um ASP.NET normalmente armazena informações de configuração em um arquivo Web.config dados. Algumas dessas informações são confidenciais e garantem a proteção. Por padrão, esse arquivo não será servido a um visitante do site, mas um administrador ou um hacker pode obter acesso ao sistema de arquivos do servidor Web e exibir o conteúdo do arquivo. Neste tutorial, aprendemos que o ASP.NET 2.0 nos permite proteger informações confidenciais criptografando seções do arquivo Web.config dados.

Introdução

As informações de configuração ASP.NET aplicativos são normalmente armazenadas em um arquivo XML chamado Web.config . Ao longo desses tutoriais, atualizamos Web.config algumas vezes. Ao criar o DataSet digitado no primeiro tutorial, por exemplo, as informações da cadeia de conexão foram adicionadas Northwind Web.config automaticamente a na seção <connectionStrings> . Posteriormente, no tutorial Páginas Mestras e Navegação do Site, atualizamos manualmente , adicionando um elemento que indica que todas as páginas ASP.NET em nosso projeto devem Web.config usar o <pages> DataWebControls Tema.

Como pode conter dados confidenciais, como cadeias de conexão, é importante que o conteúdo de seja mantido seguro e oculto Web.config Web.config de visualizadores não autorizados. Por padrão, qualquer solicitação HTTP para um arquivo com a extensão é manipulada pelo mecanismo ASP.NET, que retorna a mensagem Este tipo de página não é atendida mostrada na .config Figura 1. Isso significa que os visitantes não podem exibir Web.config o conteúdo do arquivo simplesmente inserindo na barra de http://www.YourServer.com/Web.config endereços do navegador.

Visitar Web.config por meio de um navegador retorna uma Mensagem Este tipo de página não é atendida

Figura 1: a visita Web.config por meio de um navegador retorna um tipo de página que não é uma mensagem servida (clique para exibir a imagem em tamanho normal)

Mas e se um invasor conseguir encontrar alguma outra exploração que permita exibir o conteúdo do seu Web.config arquivo? O que um invasor poderia fazer com essas informações e quais etapas podem ser executadas para proteger ainda mais as informações confidenciais no Web.config ? Felizmente, a maioria das seções no Web.config não contém informações confidenciais. Que danos um invasor pode perpetrar se souber o nome do tema padrão usado por suas páginas do ASP.NET?

Algumas Web.config seções, no entanto, contêm informações confidenciais que podem incluir cadeias de conexão, nomes de usuário, senhas, nomes de servidor, chaves de criptografia e assim por diante. Essas informações normalmente são encontradas nas seguintes Web.config seções:

  • <appSettings>
  • <connectionStrings>
  • <identity>
  • <sessionState>

Neste tutorial, veremos as técnicas para proteger essas informações de configuração confidenciais. Como veremos, a versão 2,0 do .NET Framework inclui um sistema de configurações protegida que faz com que a criptografia e descriptografia programaticamente das seções de configuração selecionadas sejam uma Breeze.

Note

Este tutorial conclui com uma visão das recomendações da Microsoft para se conectar a um banco de dados de um aplicativo ASP.NET. Além de criptografar suas cadeias de conexão, você pode ajudar a proteger seu sistema, garantindo que você esteja se conectando ao banco de dados de maneira segura.

Etapa 1: explorando as opções de configuração protegidas do ASP.NET 2,0

O ASP.NET 2,0 inclui um sistema de configuração protegido para criptografar e descriptografar informações de configuração. Isso inclui métodos no .NET Framework que podem ser usados para criptografar ou descriptografar programaticamente informações de configuração. O sistema de configuração protegida usa o modelo de provedor, que permite aos desenvolvedores escolher qual implementação de criptografia é usada.

O .NET Framework é fornecido com dois provedores de configuração protegidos:

Como o sistema de configuração protegida implementa o padrão de design do provedor, é possível criar seu próprio provedor de configuração protegido e plug-lo em seu aplicativo. Consulte Implementando um provedor de configuração protegida para obter mais informações sobre esse processo.

Os provedores RSA e DPAPI usam chaves para suas rotinas de criptografia e descriptografia, e essas chaves podem ser armazenadas no nível do computador ou do usuário. As chaves no nível do computador são ideais para cenários em que o aplicativo Web é executado em seu próprio servidor dedicado ou se há vários aplicativos em um servidor que precisam compartilhar informações criptografadas. As chaves no nível do usuário são uma opção mais segura em ambientes de hospedagem compartilhados em que outros aplicativos no mesmo servidor não devem ser capazes de descriptografar as seções de configuração protegida do aplicativo.

Neste tutorial, nossos exemplos usarão o provedor DPAPI e as chaves no nível do computador. Especificamente, vamos ver como criptografar a seção em , embora o sistema de configuração protegido possa ser usado para <connectionStrings> Web.config criptografar a maioria das Web.config seções. Para obter informações sobre como usar chaves no nível do usuário ou o provedor RSA, consulte os recursos na seção Leituras Adicionais no final deste tutorial.

Note

Os RSAProtectedConfigurationProvider DPAPIProtectedConfigurationProvider provedores e são registrados no arquivo machine.config com os nomes do provedor e , RsaProtectedConfigurationProvider DataProtectionConfigurationProvider respectivamente. Ao criptografar ou descriptografar informações de configuração, será necessário fornecer o nome do provedor apropriado ( ou ) em vez do RsaProtectedConfigurationProvider nome do tipo real ( e DataProtectionConfigurationProvider RSAProtectedConfigurationProvider DPAPIProtectedConfigurationProvider ). Você pode encontrar machine.config o arquivo na pasta $WINDOWS$\Microsoft.NET\Framework\version\CONFIG .

Etapa 2: Criptografar e descriptografar programaticamente seções de configuração

Com algumas linhas de código, podemos criptografar ou descriptografar uma seção de configuração específica usando um provedor especificado. O código, como veremos em breve, simplesmente precisa fazer referência programaticamente à seção de configuração apropriada, chamar seu ProtectSection UnprotectSection método or e, em seguida, chamar o Save método para manter as alterações. Além disso, a .NET Framework inclui um utilitário de linha de comando útil que pode criptografar e descriptografar informações de configuração. Exploraremos esse utilitário de linha de comando na etapa 3.

Para ilustrar programaticamente a proteção das informações de configuração, vamos criar uma página ASP.NET que inclui botões para criptografar e descriptografar a <connectionStrings> seção no Web.config .

Comece abrindo a EncryptingConfigSections.aspx página na AdvancedDAL pasta. Arraste um controle TextBox da caixa de ferramentas para o designer, definindo sua ID propriedade como WebConfigContents , sua TextMode propriedade para MultiLine , e suas Width Propriedades e Rows para 95% e 15, respectivamente. Esse controle TextBox exibirá o conteúdo de Web.config nos permitindo ver rapidamente se o conteúdo está criptografado ou não. É claro que, em um aplicativo real, você nunca gostaria de exibir o conteúdo Web.config .

Abaixo da caixa de texto, adicione dois controles Button chamados EncryptConnStrings e DecryptConnStrings . Defina suas propriedades de texto para criptografar cadeias de conexão e descriptografar cadeias de conexão.

Neste ponto, sua tela deve ser semelhante à figura 2.

Adicionar uma caixa de texto e dois controles de botão da Web à página

Figura 2: adicionar uma caixa de texto e dois controles de botão da Web à página (clique para exibir a imagem em tamanho normal)

Em seguida, precisamos escrever um código que carregue e exiba o conteúdo de Web.config na WebConfigContents caixa de texto quando a página for carregada pela primeira vez. Adicione o seguinte código à classe s code-behind da página. Esse código adiciona um método chamado DisplayWebConfig e o chama do Page_Load manipulador de eventos quando Page.IsPostBack é false :

protected void Page_Load(object sender, EventArgs e)
{
    // On the first page visit, call DisplayWebConfig method
    if (!Page.IsPostBack)
        DisplayWebConfig();
}
private void DisplayWebConfig()
{
    // Reads in the contents of Web.config and displays them in the TextBox
    StreamReader webConfigStream = 
        File.OpenText(Path.Combine(Request.PhysicalApplicationPath, "Web.config"));
    string configContents = webConfigStream.ReadToEnd();
    webConfigStream.Close();
    WebConfigContents.Text = configContents;
}

O DisplayWebConfig método usa a File classe para abrir o arquivo s do aplicativo Web.config , a StreamReader classe para ler seu conteúdo em uma cadeia de caracteres e a Path classe para gerar o caminho físico para o Web.config arquivo. Essas três classes são todas encontradas no System.IO namespace. Consequentemente, você precisará adicionar uma instrução à parte superior da classe using System.IO code-behind ou, como alternativa, prefixar esses nomes de classe com System.IO. .

Em seguida, precisamos adicionar manipuladores de eventos para os dois eventos de controles Button e adicionar o código necessário para criptografar e descriptografar a seção usando uma chave de nível de computador com o provedor Click <connectionStrings> DPAPI. No Designer, clique duas vezes em cada um dos Botões para adicionar um manipulador de eventos na classe code-behind e, em seguida, Click adicione o seguinte código:

protected void EncryptConnStrings_Click(object sender, EventArgs e)
{
    // Get configuration information about Web.config
    Configuration config = 
        WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
    // Let's work with the <connectionStrings> section
    ConfigurationSection connectionStrings = config.GetSection("connectionStrings");
    if (connectionStrings != null)
        // Only encrypt the section if it is not already protected
        if (!connectionStrings.SectionInformation.IsProtected)
        {
            // Encrypt the <connectionStrings> section using the 
            // DataProtectionConfigurationProvider provider
            connectionStrings.SectionInformation.ProtectSection(
                "DataProtectionConfigurationProvider");
            config.Save();
            
            // Refresh the Web.config display
            DisplayWebConfig();
        }
}
protected void DecryptConnStrings_Click(object sender, EventArgs e)
{
    // Get configuration information about Web.config
    Configuration config = 
        WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
    // Let's work with the <connectionStrings> section
    ConfigurationSection connectionStrings = 
        config.GetSection("connectionStrings");
    if (connectionStrings != null)
        // Only decrypt the section if it is protected
        if (connectionStrings.SectionInformation.IsProtected)
        {
            // Decrypt the <connectionStrings> section
            connectionStrings.SectionInformation.UnprotectSection();
            config.Save();
            // Refresh the Web.config display
            DisplayWebConfig();
        }
}

O código usado nos dois manipuladores de eventos é quase idêntico. Ambos começam recebendo informações sobre o arquivo do aplicativo Web.config atual por meio do WebConfigurationManager método da OpenWebConfiguration classe. Esse método retorna o arquivo de configuração da Web para o caminho virtual especificado. Em seguida, Web.config a seção do arquivo é <connectionStrings> acessada por meio Configuration do método GetSection(sectionName) da classe, que retorna um objeto ConfigurationSection .

O ConfigurationSection objeto inclui uma propriedade SectionInformation que fornece informações adicionais e funcionalidades sobre a seção de configuração. Como mostra o código acima, podemos determinar se a seção de configuração é criptografada verificando a SectionInformation propriedade da IsProtected propriedade. Além disso, a seção pode ser criptografada ou descriptografada por meio SectionInformation dos métodos e da ProtectSection(provider) UnprotectSection propriedade.

O método aceita como entrada uma cadeia de caracteres que especifica o nome do provedor de configuração ProtectSection(provider) protegido a ser usado ao criptografar. No manipulador EncryptConnString de eventos do Botão, passamos DataProtectionConfigurationProvider para o método para que o provedor ProtectSection(provider) DPAPI seja usado. O método pode determinar o provedor que foi usado para criptografar a seção de configuração e, portanto, UnprotectSection não requer nenhum parâmetro de entrada.

Depois de chamar ProtectSection(provider) o método ou , você deve chamar o método do UnprotectSection Configuration Save objeto para persistir as alterações. Depois que as informações de configuração forem criptografadas ou descriptografadas e as alterações forem salvas, chamamos DisplayWebConfig para carregar o Web.config conteúdo atualizado no controle TextBox.

Depois de inserir o código acima, teste-o visitando a EncryptingConfigSections.aspx página por meio de um navegador. Inicialmente, você deve ver uma página que lista o conteúdo de Web.config com a <connectionStrings> seção exibida em texto sem formatação (consulte a Figura 3).

Adicionar uma caixa de texto e dois controles de botão da Web à página

Figura 3: adicionar uma caixa de texto e dois controles de botão da Web à página (clique para exibir a imagem em tamanho normal)

Agora, clique no botão criptografar cadeias de conexão. Se a validação da solicitação estiver habilitada, a marcação enviada de volta da WebConfigContents caixa de texto produzirá um HttpRequestValidationException , que exibe a mensagem, um valor potencialmente perigoso Request.Form foi detectado no cliente. A validação de solicitação, que é habilitada por padrão no ASP.NET 2,0, proíbe postbacks que incluem HTML não codificado e é projetada para ajudar a evitar ataques de injeção de script. Essa verificação pode ser desabilitada na página ou no nível do aplicativo. Para desativá-lo para essa página, defina a ValidateRequest configuração como false na @Page diretiva. A @Page diretiva é encontrada na parte superior da marcação declarativa de s da página.

<%@ Page ValidateRequest="False" ... %>

Para obter mais informações sobre a validação de solicitação, sua finalidade, como desabilitá-la na página e no nível de aplicativo, bem como como codificar marcação HTML, consulte solicitar validação-impedindo ataques de script.

Depois de desabilitar a validação de solicitação para a página, tente clicar no botão criptografar cadeias de conexão novamente. No postback, o arquivo de configuração será acessado e sua <connectionStrings> seção criptografada usando o provedor DPAPI. Em seguida, a caixa de texto é atualizada para exibir o novo Web.config conteúdo. Como mostra a Figura 4, as <connectionStrings> informações agora estão criptografadas.

Clicar no botão criptografar cadeias de conexão criptografa a < > seção ConnectionString

Figura 4: clicar no botão criptografar cadeias de conexão criptografa a <connectionString> seção (clique para exibir a imagem em tamanho normal)

A seção criptografada gerada em meu computador segue, embora parte do conteúdo no <connectionStrings> elemento tenha sido removido por <CipherData> brevidade:

<connectionStrings 
    configProtectionProvider="DataProtectionConfigurationProvider">
  <EncryptedData>
    <CipherData>
      <CipherValue>AQAAANCMnd8BFdERjHoAwE/...zChw==</CipherValue>
    </CipherData>
  </EncryptedData>
</connectionStrings>

Note

O <connectionStrings> elemento especifica o provedor usado para executar a criptografia ( DataProtectionConfigurationProvider ). Essas informações são usadas pelo UnprotectSection método quando o botão Descriptografar Cadeias de Conexão é clicado.

Quando as informações da cadeia de conexão são acessadas de – por código que escrevemos, de um controle SqlDataSource ou do código gerado automaticamente dos TableAdapters em nossos Conjuntos de Dados Digitados – ele é Web.config automaticamente descriptografado. Em resumo, não precisamos adicionar nenhum código ou lógica extra para descriptografar a seção <connectionString> criptografada. Para demonstrar isso, visite um dos tutoriais anteriores neste momento, como o tutorial exibição simples da seção Relatório Básico ( ~/BasicReporting/SimpleDisplay.aspx ). Como mostra a Figura 5, o tutorial funciona exatamente como esperado, indicando que as informações da cadeia de conexão criptografada estão sendo descriptografadas automaticamente pela página ASP.NET dados.

A camada de acesso a dados descriptografa automaticamente as informações da cadeia de conexão

Figura 5: a camada de acesso a dados descriptografa automaticamente as informações da cadeia de conexão ( clique para exibir a imagem de tamanho completo)

Para reverter a seção <connectionStrings> de volta para sua representação de texto sem-texto, clique no botão Descriptografar Cadeias de Conexão. No postback, você deverá ver as cadeias de conexão no Web.config em texto sem-texto. Neste ponto, sua tela deve ter a aparência dela ao visitar esta página pela primeira vez (consulte a Figura 3).

Etapa 3: Criptografar seções de configuração usandoaspnet_regiis.exe

O .NET Framework inclui uma variedade de ferramentas de linha de comando na $WINDOWS$\Microsoft.NET\Framework\version\ pasta . No tutorial Usando dependências do Cache SQL, por exemplo, vimos o uso da ferramenta de linha de comando para adicionar a infraestrutura necessária para dependências aspnet_regsql.exe de cache SQL. Outra ferramenta de linha de comando útil nesta pasta é a ASP.NET registro do IIS ( aspnet_regiis.exe ). Como o nome indica, a ferramenta de registro do IIS ASP.NET é usada principalmente para registrar um aplicativo ASP.NET 2,0 com o servidor Web Microsoft s de nível profissional, o IIS. Além de seus recursos relacionados ao IIS, a ferramenta de registro do IIS ASP.NET também pode ser usada para criptografar ou descriptografar seções de configuração especificadas no Web.config .

A instrução a seguir mostra a sintaxe geral usada para criptografar uma seção de configuração com a aspnet_regiis.exe ferramenta de linha de comando:

aspnet_regiis.exe -pef section physical_directory -prov provider

seção é a seção de configuração para criptografar (como connectionStrings), o _ diretório físico é o caminho físico completo para o diretório raiz do aplicativo Web e o provedor é o nome do provedor de configuração protegido a ser usado (como DataProtectionConfigurationProvider). Como alternativa, se o aplicativo Web estiver registrado no IIS, você poderá inserir o caminho virtual em vez do caminho físico usando a seguinte sintaxe:

aspnet_regiis.exe -pe section -app virtual_directory -prov provider

O exemplo a seguir aspnet_regiis.exe criptografa a <connectionStrings> seção usando o provedor DPAPI com uma chave de nível de máquina:

aspnet_regiis.exe -pef
"connectionStrings" "C:\Websites\ASPNET_Data_Tutorial_73_CS"
-prov "DataProtectionConfigurationProvider"

Da mesma forma, a aspnet_regiis.exe ferramenta de linha de comando pode ser usada para descriptografar seções de configuração. Em vez de usar a -pef opção, use -pdf (ou em vez de -pe , use -pd ). Além disso, observe que o nome do provedor não é necessário ao descriptografar.

aspnet_regiis.exe -pdf section physical_directory
  -- or --
aspnet_regiis.exe -pd section -app virtual_directory

Note

Como estamos usando o provedor DPAPI, que usa chaves específicas para o computador, você deve executar aspnet_regiis.exe a partir do mesmo computador do qual as páginas da Web estão sendo servidas. Por exemplo, se você executar esse programa de linha de comando do computador de desenvolvimento local e, em seguida, carregar o arquivo de Web.config criptografado para o servidor de produção, o servidor de produção não poderá descriptografar as informações da cadeia de conexão desde que ela foi criptografada usando chaves específicas para seu computador de desenvolvimento. O provedor RSA não tem essa limitação, pois é possível exportar as chaves RSA para outro computador.

Entendendo opções de autenticação de banco de dados

Antes que qualquer aplicativo possa emitir consultas , , ou para um banco de Microsoft SQL Server, o banco de dados deve primeiro SELECT INSERT identificar o UPDATE DELETE solicitante. Esse processo é conhecido como autenticação e SQL Server fornece dois métodos de autenticação:

  • Autenticação do Windows – o processo no qual o aplicativo está em execução é usado para se comunicar com o banco de dados. Ao executar um ASP.NET por meio do Visual Studio 2005 ASP.NET Development Server, o aplicativo ASP.NET assume a identidade do usuário conectado no momento. Para ASP.NET aplicativos no Microsoft Internet Information Server (IIS), ASP.NET aplicativos geralmente assumem a identidade de ou , embora isso possa domainName``\MachineName domainName``\NETWORK SERVICE ser personalizado.
  • Autenticação do SQL – uma ID de usuário e valores de senha são fornecidos como credenciais para autenticação. Com a autenticação SQL, a ID de usuário e a senha são fornecidas na cadeia de conexão.

autenticação do Windows é preferencial em vez da autenticação do SQL porque ela é mais segura. Com autenticação do Windows a cadeia de conexão é livre de um nome de usuário e senha e se o servidor Web e o servidor de banco de dados residem em dois máquinas diferentes, as credenciais não são enviadas pela rede em texto sem-texto. No entanto, com a autenticação SQL, as credenciais de autenticação são em código na cadeia de conexão e são transmitidas do servidor Web para o servidor de banco de dados em texto sem-texto.

Esses tutoriais usaram autenticação do Windows. Você pode saber qual modo de autenticação está sendo usado inspecionando a cadeia de conexão. A cadeia de conexão Web.config no para nossos tutoriais foi:

Data Source=.\SQLEXPRESS; AttachDbFilename=|DataDirectory|\NORTHWND.MDF; Integrated Security=True; User Instance=True

A Segurança Integrada=True e a falta de um nome de usuário e senha indicam que autenticação do Windows está sendo usado. Em algumas cadeias de conexão, o termo Trusted Connection=Yes ou Integrated Security=SSPI é usado em vez de Segurança Integrada=True, mas todos os três indicam o uso de autenticação do Windows.

O exemplo a seguir mostra uma cadeia de conexão que usa a autenticação SQL. $CREDENTIAL_PLACEHOLDER$ é um espaço reservado para o par chave-valor de senha. Observe que as credenciais são inseridas na cadeia de conexão:

Server=serverName; Database=Northwind; uid=userID; $CREDENTIAL_PLACEHOLDER$

Imagine que um invasor seja capaz de exibir o arquivo s do seu aplicativo Web.config . Se você usar a autenticação do SQL para se conectar a um banco de dados acessível pela Internet, o invasor poderá usar essa cadeia de conexão para se conectar ao banco de dados por meio do SQL Management Studio ou de páginas do ASP.NET em seu próprio site. Para ajudar a mitigar essa ameaça, criptografe as informações da cadeia de conexão em Web.config usando o sistema de configuração protegida.

Note

Para obter mais informações sobre os diferentes tipos de autenticação disponíveis no SQL Server, consulte criando aplicativos seguros do ASP.net: autenticação, autorização e comunicação segura. Para obter mais exemplos de cadeias de conexão que ilustram as diferenças entre a sintaxe de autenticação do Windows e do SQL, consulte connectionStrings.com.

Resumo

Por padrão, os arquivos com uma .config extensão em um aplicativo ASP.net não podem ser acessados por meio de um navegador. Esses tipos de arquivos não são retornados porque podem conter informações confidenciais, como cadeias de conexão de banco de dados, nomes de usuários e senhas e assim por diante. O sistema de configuração protegida no .NET 2,0 ajuda a proteger ainda mais as informações confidenciais, permitindo que as seções de configuração especificadas sejam criptografadas. Há dois provedores de configuração protegidos internos: um que usa o algoritmo RSA e outro que usa a API de proteção de dados do Windows (DPAPI).

Neste tutorial, examinamos como criptografar e descriptografar definições de configuração usando o provedor DPAPI. Isso pode ser feito de forma programática, como vimos na etapa 2, bem como por meio da aspnet_regiis.exe ferramenta de linha de comando, que foi abordada na etapa 3. Para obter mais informações sobre como usar chaves no nível do usuário ou usar o provedor RSA, consulte os recursos na seção leitura adicional.

Boa programação!

Leitura Adicional

Para obter mais informações sobre os tópicos discutidos neste tutorial, consulte os seguintes recursos:

Sobre o autor

Scott Ltd,autor de sete livros DO ASP/ASP.NET e um dos 4GuysFromRolla.com ,trabalha com tecnologias web da Microsoft desde 1998. Scott trabalha como consultor independente, treinador e autor. Seu livro mais recente é Sams Teach Yourself ASP.NET 2.0 em 24 horas. Ele pode ser alcançado em mitchell@4GuysFromRolla.com . ou por meio de seu blog, que pode ser encontrado em http://ScottOnWriting.NET .

Graças especiais a

Esta série de tutoriais foi revisada por muitos revisadores úteis. Os revisadores-chefe deste tutorial foram ª Dra. Interessado em revisar meus próximos artigos do MSDN? Nesse caso, solte uma linha em mitchell@4GuysFromRolla.com .