Resolvendo erros de código de autenticação de mensagem de estado de exibição (MAC)

O que é o estado de exibição?

Estado de exibição é informações que é round-tropeçado entre páginas WebForms (. aspx) em um aplicativo ASP.NET. A marcação HTML para o campo ' _ VIEWSTATE ' semelhante à seguinte:

< tipo de entrada = "oculto" nome = "_" ViewState "ID =" _ "ViewState" value = "..."/>Um exemplo de um item que pode ser armazenado no campo ' _ VIEWSTATE ' é o texto de um controle Button. Se um usuário clica no botão, o Button_Click manipulador de eventos será capaz de extrair o texto do botão do campo de estado de exibição. Consulte o tópico visão geral do estado de exibição do ASP.net no site da Microsoft Developer Network (MSDN) para obter uma visão geral muito mais detalhada do estado de exibição ASP.net. Uma vez que o campo ' _ VIEWSTATE ' contém informações importantes que são utilizadas para reconstruir a página no postback, certifique-se de que um intruso não é possível adulterar este campo. Se um invasor tiver enviado uma carga maliciosa _ \ ViewState, o invasor poderia potencialmente enganar o aplicativo para executar uma ação que, caso contrário, não teria sido executada. Para evitar esse tipo de ataque de adulteração, o campo ' _ VIEWSTATE ' é protegido por um código de autenticação de mensagem (MAC). ASP.NET valida o MAC que é enviado em conjunto com a carga de ' _ VIEWSTATE quando ocorre um postback. A chave que é usada para calcular o MAC é especificada no elemento do aplicativo no arquivo Web. config. Como o invasor não pode adivinhar o conteúdo do elemento < machineKey >, o invasor não pode fornecer um MAC válido se o invasor tentar adulteração com a carga de ' _ VIEWSTATE. ASP.NET detectará que um MAC válido não foi fornecido, e ASP.NET rejeitará a solicitação maliciosa.

O que causa erros de validação do MAC?

Um erro de validação do MAC será semelhante ao exemplo a seguir:

Erro de servidor no aplicativo '/'. Falha na validação do ViewState MAC. Se este aplicativo é hospedado por um Web farm ou cluster, certifique-se de que < machineKey > configuração especifica o mesmo validationKey e o algoritmo de validação. AutoGenerate não pode ser usado em um cluster. Descrição: ocorreu uma excepção não processada durante a execução da solicitação da Web atual. Examine o rastreamento de pilha para obter mais informações sobre o erro e onde ele se originou no código. Detalhes da exceção: System. Web. HttpException: validação do ViewState MAC falhou. Se este aplicativo é hospedado por um Web farm ou cluster, certifique-se de que < machineKey > configuração especifica o mesmo validationKey e o algoritmo de validação. AutoGenerate não pode ser usado em um cluster. Erro de origem: [sem linhas de origem relevantes] Arquivo de origem:... Linha: 0 Rastreamento de pilha: [ViewStateException: ViewState inválido. IP do cliente::: 1 Porto: 40653 Referer: http://localhost:40643/MyPage.aspx Caminho:/MyPage.aspx User-Agent: Mozilla/5.0 (compatível; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) ViewState:...] [HttpException (0x80004005): validação do ViewState MAC falhou. Se este aplicativo é hospedado por um Web farm ou cluster, certifique-se de que < machineKey > configuração especifica o mesmo validationKey e o algoritmo de validação. AutoGenerate não pode ser usado em um cluster. Consulte http://go.microsoft.com/fwlink/?LinkID=314055 para obter mais informações.] System. Web. UI. ViewStateException. ThrowError (Exception interno, String persistedState, String errorPageMessage, Boolean macValidationError) + 190 System. Web. UI. ViewStateException. ThrowMacValidationError (exceção inner, String persistedState) + 46 System. Web. UI. ObjectStateFormatter. Deserialize (String inputString, finalidade Purpose) + 861 System. Web. UI. ObjectStateFormatter. System. Web. UI. IStateFormatter2. Deserialize (String serializedState, finalidade finalidade) + 51 System. Web. UI. util. DeserializeWithAssert (IStateFormatter2 Formatter, String serializedState, finalidade) + 67 System. Web. UI. HiddenFieldPageStatePersister. Load () + 444 System. Web. UI. Page. LoadPageStateFromPersistenceMedium () + 368 System. Web. UI. Page. LoadAllState () + 109 System. Web. UI. Page. ProcessRequestMain (Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) + 7959 System. Web. UI. Page. ProcessRequest (Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) + 429 System. Web. UI. Page. ProcessRequest () + 125 System. Web. UI. Page. ProcessRequestWithNoAssert (contexto HttpContext) + 48 System. Web. UI. Page. ProcessRequest (contexto HttpContext) + 234 ASP. mypage_aspx. ProcessRequest (contexto HttpContext) em...: 0 System. Web. CallHandlerExecutionStep. System. Web. HttpApplication. IExecutionStep. Execute () + 1300 System. Web. HttpApplication. ExecuteStep (IExecutionStep etapa, Boolean & completedSynchronously) + 140

Causa 1: o aplicativo Web está sendo executado em um farm (ambiente de vários servidores)

ASP.NET gera automaticamente uma chave criptográfica para cada aplicativo e armazena a chave no hive do registro HKUC. Essa chave gerada automaticamente é usada se não houver nenhum elemento explícito < machineKey > na configuração do aplicativo. No entanto, uma vez que esta chave gerada automaticamente é local para o computador que criou a chave, este cenário provoca um problema para aplicações que são executadas num farm. Cada servidor no farm gerará sua própria chave local e nenhum dos servidores do farm concordará com a chave a ser usada. O resultado é que, se um servidor gera uma carga de \ _ VIEWSTATE que consome um servidor diferente, o consumidor experimentará uma falha de validação do MAC.

Resolução 1a: criar um elemento explícito < machineKey > Adicionando um explícito < machineKey > elemento para o arquivo Web. config do aplicativo, o desenvolvedor informa ASP.NET não usar a chave criptográfica gerada automaticamente. Consulte o Apêndice a para obter instruções sobre como gerar um elemento < machinekey >. Depois que esse elemento é adicionado ao arquivo Web. config, reimplante o aplicativo para cada servidor no farm. Nota Alguns serviços de hospedagem na Web, como sites do Microsoft Azure, tomam medidas para sincronizar a chave gerada automaticamente de cada aplicativo em seus servidores back-end. Isso permite que os aplicativos que não especificou um explícito < machineKey > elemento para continuar trabalhando nesses ambientes, mesmo se o aplicativo está sendo executado em um farm. Se seu aplicativo estiver sendo executado em um serviço de Hospedagem de terceiros, entre em contato com seu provedor de hospedagem para determinar se essa situação se aplica a você.
Resolução 1b: ativar afinidade no balanceador de carga Se seus sites estiverem operando por trás de um balanceador de carga, você poderá habilitar a afinidade de servidor para solucionar temporariamente o problema. Isso ajuda a garantir que qualquer cliente determinado apenas interage com um servidor físico por trás do balanceador de carga para que todas as cargas criptográficas sejam geradas por e consumidas pelo mesmo servidor. Isso não deve ser considerado uma solução de longo prazo para o problema. Mesmo quando a afinidade de servidor está habilitada, a maioria dos balanceadores de carga redirecionará o cliente para um servidor físico diferente se o servidor original ao qual os balanceadores de carga foram affinitized ficar offline. Isso faz com que o novo servidor rejeite as cargas criptográficas (como, por exemplo, _ VIEWSTATE, tickets de autenticação de formulários, tokens antifalsificação de MVCs e outros serviços) que o cliente tem atualmente. Usando um explícito < machineKey > elemento e reimplantando o aplicativo deve ser preferencial sobre a habilitação de afinidade de servidor.

Causa 2: o processo de trabalho usa a identidade do pool de aplicativos do IIS 7,0

Os serviços de informações da Internet (IIS) 7,0 (Windows Vista, Windows Server 2008) introduziram a identidade do pool de aplicativos, um novo mecanismo de isolamento que ajuda a fornecer maior segurança para servidores que executam aplicativos ASP.net. No entanto, os sites que estão sendo executados a identidade do pool de aplicativos não têm acesso ao registro HKUC. Isso é onde o tempo de execução ASP.NET armazena suas chaves < machineKey > geradas automaticamente. O resultado é que ASP.NET não pode persistir a chave gerada automaticamente quando o pool de aplicativos é redefinido. Portanto, toda vez que w3wp. exe é redefinido, uma nova chave temporária é gerada. Nota Isso não é um problema no IIS 7,5 (Windows 7, Windows Server 2008 R2) e versões posteriores. Nessas versões do IIS, ASP.NET pode persistir suas chaves geradas automaticamente em um local diferente que sobrevive ao pool de aplicativos redefine.

Resolução 2a: Use o utilitário Aspnet_regiis ASP.NET instalações contêm um utilitário, Aspnet_regiis. exe. Esse utilitário permite que ASP.NET interface com o IIS para executar as configurações que são necessárias para executar um aplicativo gerenciado. Uma dessas configurações cria as chaves necessárias no hive do registro para habilitar a persistência de chaves de máquina geradas automaticamente. Primeiro, você precisa determinar qual pool de aplicativos seu site está usando. Isso pode ser determinado usando o utilitário inetmgr que está incluído no IIS. Selecione seu site na exibição em árvore à esquerda, clique com o botão direito do mouse em gerenciar website, em seguida, clique em Configurações avançadas. A caixa de diálogo que aparece mostrará o nome do pool de aplicativos. Para andaime as chaves de registro apropriadas para um pool de aplicativos ASP.NET 4,0, execute estas etapas:
1. Abra um prompt de comando administrativo.
2. Localize o diretório apropriado, dependendo se o pool de aplicativos é 32 bits ou 64 bits:
  - 32-bit pool de aplicativos: CD/d%windir%\Microsoft.NET\Framework\v4.0.30319
  - 64-bit pool de aplicativos: CD/d%windir%\Microsoft.NET\Framework64\v4.0.30319
3. Mova para o diretório, digite o seguinte comando e, em seguida, pressione ENTER:
  
  Aspnet_regiis-GA "IIS APPPOOL\app-pool-name"
Se o pool de aplicativos for um pool de aplicativos ASP.NET 2,0 ou 3,5, siga estas etapas:
1. Abra um prompt de comando administrativo.
2. Localize o diretório apropriado, dependendo se o pool de aplicativos é 32 bits ou 64 bits:
  - 32-bit pool de aplicativos: CD/d%windir%\Microsoft.NET\Framework\v2.0.50727
  - 64-bit pool de aplicativos: CD/d%windir%\Microsoft.NET\Framework64\v2.0.50727
3. Mova para o diretório, digite o seguinte comando e, em seguida, pressione ENTER:
  
  Aspnet_regiis-GA "IIS APPPOOL\app-pool-name"
Por exemplo, se o pool de aplicativos for denominado meu pool de aplicativo (como na imagem anterior), execute o seguinte comando:

Aspnet_regiis-GA "IIS Apppool\meu pool de aplicativos" Nota Os serviços do sistema APPHOSTSVC e WAS podem ter que estar em execução para o utilitário Aspnet_regiis para resolver o IIS APPPOOL \ * nomes apropriadamente.
Resolução 2B: criar um elemento explícito < machineKey > Adicionando um explícito < machineKey > elemento para o arquivo Web. config do aplicativo, o desenvolvedor informa ASP.NET não usar a chave criptográfica gerada automaticamente. Consulte o Apêndice a para obter instruções sobre como gerar um elemento < machinekey >.

Causa 3: o pool de aplicativos é configurado usando LoadUserProfile = false

Se o pool de aplicativos estiver sendo executado com uma identidade personalizada, o IIS pode não ter carregado o perfil de usuário para a identidade. Isso tem o efeito colateral de tornar o registro HKUC indisponível para ASP.NET persistir o < machineKey gerado automaticamente >. Portanto, uma nova chave gerada automaticamente será criada toda vez que o aplicativo for reiniciado. Consulte a seção perfil de usuário no site da Microsoft para obter mais informações.

Resolução 3A: Use o utilitário Aspnet_regiis As instruções para isso são as mesmas que a resolução 2a. Consulte essa seção para obter mais informações.
Resolução 3B: Use um explícito < machineKey > Adicionando um explícito < machineKey > elemento para o arquivo Web. config do aplicativo, o desenvolvedor informa ASP.NET não usar a chave criptográfica gerada automaticamente. Consulte o Apêndice a para obter instruções sobre como gerar um elemento < machinekey >.
Resolução 3C: provisione as chaves de registro hkuc necessárias manualmente Se você não pode executar o utilitário Aspnet_regiis, você pode usar um script do Windows PowerShell para provisionar as chaves de registro apropriadas em HKUC. Consulte o Apêndice B para obter mais informações.
Resolução 3D: conjunto LoadUserProfile = true para este pool de aplicativos Você também pode habilitar o carregamento do perfil de usuário dentro desse pool de aplicativos. Isso torna o hive do registro HKUC, pasta temporária e outros locais de armazenamento específicos do usuário disponíveis para o aplicativo. No entanto, isso pode causar maior uso de disco ou memória para o processo de trabalho. Consulte o elemento para obter mais informações sobre como habilitar essa configuração.

Causa 4: a propriedade Page. ViewStateUserKey tem um valor incorreto

Os desenvolvedores de software podem decidir usar a propriedade Page. ViewStateUserKey para adicionar proteção de falsificação de solicitação entre sites para o campo _ VIEWSTATE. Se você usar a propriedade Page. ViewStateUserKey , normalmente é definida como um valor como o nome de usuário atual ou o identificador de sessão do usuário. Os modelos de projeto para aplicativos WebForms no Microsoft Visual Studio 2012 e versões posteriores contêm exemplos que usam essa propriedade. Consulte a Propriedade Page. ViewStateUserKey tópico no site da Microsoft Developer Network (MSDN) para obter mais informações. Se o ViewStateUserKey propriedade for especificada, seu valor é gravado em _ \ ViewState no momento da geração. Quando o ' _ VIEWSTATE campo é consumido, o servidor verifica o atual Page ViewStateUserKey Propriedade e valida-lo em relação ao valor que foi usado para gerar o _ VIEWSTATE campo. Se os valores não corresponderem, a solicitação será rejeitada como potencialmente maliciosa. Um exemplo de uma falha de ViewStateUserKey-Related seria um cliente que tem duas abas abertas no navegador. O cliente está conectado como usuário A e, na primeira guia, uma página é renderizada com um _ \ ViewState cuja propriedade ViewStateUserKey contém "usuário a". Na segunda guia, o cliente faz logoff e, em seguida, faz logon novamente como usuário B. O cliente volta para a primeira guia e envia o formulário. A propriedade ViewStateUserKey pode conter "usuário B" (porque isso é o que o cookie de autenticação do cliente diz). No entanto, o campo \ _ VIEWSTATE que o cliente enviado contém "usuário A". Essa incompatibilidade causa a falha.

Resolução 4a: Verifique se ViewStateUserKey está definido corretamente Se seu aplicativo usa o ViewStateUserKey Propriedade, verifique se que o valor da propriedade é o mesmo quando o estado de exibição é gerado e quando ele é consumido. Se você estiver usando o nome do usuário conectado atual, certifique-se de que o usuário ainda está conectado e que a identidade do usuário não foi alterada no momento do postback. Se você estiver usando o identificador de sessão do usuário atual, certifique-se de que a sessão não atingiu o tempo limite. Se você estiver executando em um ambiente de farm, certifique-se de que o < machineKey > elementos correspondem. Consulte o Apêndice a para obter instruções sobre como gerar esses elementos.

Apêndice A: como gerar um elemento < machineKey >

Aviso de segurança Há muitos Web sites que irá gerar um elemento < machineKey > para você com o clique de um botão. Nunca use um elemento < machineKey > que você obteve de um desses sites. É impossível saber se essas chaves foram criadas com segurança ou se elas estão sendo gravadas em um banco de dados secreto. Você só deve usar < machineKey > elementos de configuração que você mesmo criou.

Para gerar um elemento < machineKey > você mesmo, você pode usar o seguinte script do Windows PowerShell :

# Generates a <machineKey> element that can be copied + pasted into a Web.config file.
function Generate-MachineKey {
  [CmdletBinding()]
  param (
    [ValidateSet("AES", "DES", "3DES")]
    [string]$decryptionAlgorithm = 'AES',
    [ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
    [string]$validationAlgorithm = 'HMACSHA256'
  )
  process {
    function BinaryToHex {
        [CmdLetBinding()]
        param($bytes)
        process {
            $builder = new-object System.Text.StringBuilder
            foreach ($b in $bytes) {
              $builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
            $builder
        }
    }
    switch ($decryptionAlgorithm) {
      "AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
      "DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
      "3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
    $decryptionObject.GenerateKey()
    $decryptionKey = BinaryToHex($decryptionObject.Key)
    $decryptionObject.Dispose()
    switch ($validationAlgorithm) {
      "MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
      "SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
      "HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
      "HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
      "HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
    $validationKey = BinaryToHex($validationObject.Key)
    $validationObject.Dispose()
    [string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
      "<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
      $decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
      $validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
}

Para ASP.NET 4,0 aplicativos, você pode simplesmente chamar Generate-machineKey sem parâmetros para gerar um < machinekey > elemento da seguinte maneira:

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..." />

ASP.NET 2,0 e 3,5 aplicativos não oferecem suporte a HMACSHA256. Em vez disso, você pode especificar SHA1 para gerar um compatível < machineKey > elemento da seguinte maneira:

PS> Generate-MachineKey -validation sha1
<machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..." />

Assim que você tiver um elemento < machineKey >, você pode colocá-lo no arquivo Web. config. O < machineKey > elemento só é válido no arquivo Web. config na raiz do seu aplicativo e não é válido no nível da subpasta.

<configuration>
  <system.web>
    <machineKey ... />
  </system.web>
</configuration>

Para obter uma lista completa de algoritmos com suporte, execute Help Generate-MachineKey no prompt do Windows PowerShell.

Apêndice B: provisionamento do registro para persistir chaves geradas automaticamente

Por padrão, porque as chaves geradas automaticamente ASP. NETs são mantidas no registro HKUC, essas chaves podem ser perdidas se o perfil de usuário não foi carregado no processo de trabalho do IIS e, em seguida, o pool de aplicativos reciclo. Esse cenário pode afetar provedores de hospedagem compartilhados que executam pools de aplicativos como contas de usuário padrão do Windows. Para contornar esta situação, ASP.net activa persistindo as chaves geradas automaticamente no registo HKLM em vez do registo hkuc. Isso normalmente é executado usando o utilitário Aspnet_regiis (consulte as instruções na seção "resolução 2a: usar o utilitário Aspnet_regiis"). No entanto, para administradores que não desejam executar esse utilitário, o seguinte script do Windows PowerShell pode ser usado em vez disso:

# Provisions the HKLM registry so that the specified user account can persist auto-generated machine keys.
function Provision-AutoGenKeys {
  [CmdletBinding()]
  param (
    [ValidateSet("2.0", "4.0")]
    [Parameter(Mandatory = $True)]
    [string] $frameworkVersion,
    [ValidateSet("32", "64")]
    [Parameter(Mandatory = $True)]
    [string] $architecture,
    [Parameter(Mandatory = $True)]
    [string] $upn
  )
  process {
    # We require administrative permissions to continue.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "This cmdlet requires Administrator permissions."
        return
    }
    # Open HKLM with an appropriate view into the registry
    if ($architecture -eq "32") {
        $regView = [Microsoft.Win32.RegistryView]::Registry32;
    } else {
        $regView = [Microsoft.Win32.RegistryView]::Registry64;
    }
    $baseRegKey = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $regView)
    # Open ASP.NET base key
    if ($frameworkVersion -eq "2.0") {
        $expandedVersion = "2.0.50727.0"
    } else {
        $expandedVersion = "4.0.30319.0"
    }
    $aspNetBaseKey = $baseRegKey.OpenSubKey("SOFTWARE\Microsoft\ASP.NET\$expandedVersion", $True)
    # Create AutoGenKeys subkey if it doesn't already exist
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Get the SID for the user in question, which will allow us to get his AutoGenKeys subkey
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORS, and the target SID get full access
    $regSec = New-Object System.Security.AccessControl.RegistrySecurity
    $regSec.SetSecurityDescriptorSddlForm("D:P(A;OICI;GA;;;SY)(A;OICI;GA;;;BA)(A;OICI;GA;;;$sid)")
    $userAutoGenKey = $autoGenBaseKey.OpenSubKey($sid, $True)
    if ($userAutoGenKey -eq $null) {
        # Subkey didn't exist; create and ACL appropriately
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Subkey existed; make sure ACLs are correct
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

O exemplo a seguir mostra como provisionar as entradas de registro HKLM apropriadas para um pool de aplicativos que é executado como o usuário, example@contoso.com (este é o UPN da conta de usuário do Windows). Esse pool de aplicativos é um pool de aplicativos de 32 bits que está executando o CLR v 2.0 (ASP.NET 2,0 ou 3,5).

PS> Provision-AutoGenKeys -FrameworkVersion 2.0 -Architecture 32 -UPN "example@contoso.com"

Se o pool de aplicativos em vez disso for um pool de aplicativos de 64 bits que esteja executando o CLR v 4.0 (ASP.NET 4,0 ou 4,5), o comando será o seguinte:

PS> Provision-AutoGenKeys -FrameworkVersion 4.0 -Architecture 64 -UPN "example@contoso.com"

Mesmo que as chaves geradas automaticamente são armazenadas no HKLM, a subchave do registro que contém o material criptográfico secreto de cada conta de usuário é adicionada a uma lista de controle de acesso (ACL) para que o material criptográfico não pode ser lido por outras contas de usuário.

Apêndice C: criptografando o elemento < machineKey > nos arquivos de configuração

Os administradores de servidor podem não querer informações altamente confidenciais, como o material de chave < machineKey > para o formulário de texto simples em arquivos de configuração. Se for esse o caso, os administradores podem decidir tirar proveito de um recurso do .NET Framework conhecido como "configuração protegida". Esse recurso permite criptografar determinadas seções dos arquivos. config. Se o conteúdo desses arquivos de configuração for sempre divulgado, o conteúdo dessas seções ainda permanecerá secreto. Você pode encontrar uma breve visão geral da configuração protegida no site do MSDN. Ele também contém um tutorial sobre como proteger o < connectionStrings > e < machineKey > elementos do arquivo Web. config.