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

Traduções deste artigo Traduções deste artigo
ID do artigo: 2915218 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

O que é o estado da exibição?

O estado de exibição é a informação retornada entre páginas WebForms (.aspx) em um aplicativo ASP.NET. A marcação HTML para o campo __VIEWSTATE é semelhante ao seguinte:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

Um exemplo de um item que pode ser armazenado no campo __VIEWSTATE é o texto de um controle de botão. Se um usuário clicar no botão, o manipulador de evento Button_Click poderá extrair o texto do botão do campo de estado de exibição. Consulte o tópico Visão geral do estado da exibição ASP.NET no site Microsoft Developer Network (MSDN) para uma visão geral muito mais detalhada do estado de exibição ASP.NET.

Como o campo __VIEWSTATE contém informações importantes usadas para reconstruir a página na postagem, certifique-se de que um invasor não pode adulterar este campo. Se um invasor enviou uma carga de pagamento __VIEWSTATE maliciosa, o invasor pode enganar o aplicativo para realizar uma ação que poderia não ser realizado.

Para evitar este tipo de ataque de falsificação, o campo __VIEWSTATE é protegido por um código de autenticação de mensagem (MAC). O ASP.NET valida o MAC enviado junto com a carga de pagamento __VIEWSTATE quando uma postagem ocorrer. A chave usada para calcular o MAC é especificada no elemento <machineKey> 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 tentar falsificar a carga de pagamento __VIEWSTATE. O ASP.NET irá detectar se um MAC válido não foi fornecido e o ASP.NET irá rejeitar a solicitação maliciosa.

O que causa erros de validação MAC?

um erro de validação MAC será semelhante ao seguinte exemplo:

Erro do servidor no aplicativo '/'.

Falha na validação do MAC do estado de exibição. Se este aplicativo for hospedado por um farm da Web ou cluster, certifique-se de que a configuração <machineKey> especifica o mesmo validationKey e algoritmo de validação. AutoGenerate não pode ser usado em um cluster.

Descrição: Uma exceção não tratada ocorreu 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 foi originado no código.

Detalhes da Exceção: System.Web.HttpException : Falha na validação do MAC do estado de exibição. Se este aplicativo for hospedado por um farm da Web ou cluster, certifique-se de que a configuração <machineKey> especifica o mesmo validationKey e algoritmo de validação. AutoGenerate não pode ser usado em um cluster.

Origem do erro: [Nenhuma linha de origem relevante]

Source File: ... Linha: 0

Rastreamento de pilha:

[ViewStateException: Estado de exibição inválido.
IP cliente: ::1
Porta: 40653
Referência: http://localhost:40643/MyPage.aspx
Caminho: /MyPage.aspx
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
ViewState: ...]

[HttpException (0x80004005): Falha na validação do MAC do estado de exibição. Se este aplicativo for hospedado por um farm da Web ou cluster, certifique-se de que a configuração <machineKey> especifica o mesmo validationKey e 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 inner, String persistedState, String errorPageMessage, Boolean macValidationError) +190
System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) +46
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) +861
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) +51
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) +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(HttpContext context) +48
System.Web.UI.Page.ProcessRequest(HttpContext context) +234
ASP.mypage_aspx.ProcessRequest(HttpContext context) in ...:0
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +1300
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +140

Motivo 1: O aplicativo Web está funcionando em um farm (ambiente de vários servidores)

O ASP.NET gera automaticamente uma chave criptografada para cada aplicativo e armazena a chave no núcleo de registro HKCU. Esta chave gerada automaticamente é usada se não há um elemento <machineKey> explícito na configuração do aplicativo. No entanto, como esta chave gerada automaticamente é local para o computador que criou a chave, este cenário causa um problema para aplicativos executados em um farm. Cada servidor no farm irá gerar sua própria chave local e nenhum dos servidores no farm irão concordar sobre qual chave usar. O resultado é que, se um servidor gera uma carga de pagamento __VIEWSTATE que um servidor diferente consume, o consumidor irá enfrentar uma falha de validação MAC.
  • Resolução 1a: Criar um elemento <machineKey> explícito

    Ao adicionar um elemento <machineKey> explícito ao arquivo Web.config do aplicativo, o desenvolvedor diz ao ASP.NET para não usar a chave de criptografia gerada automaticamente. Consulte o Anexo A para obter instruções sobre como gerar um elemento <machineKey>. Após este elemento ser adicionado ao arquivo Web.config, implante novamente o aplicativo para cada servidor no farm.

    Observação Alguns serviços de hospedagem da Web, como sites do Microsoft Azure, realizam etapas para sincronizar cada chave gerada automaticamente do aplicativo entre servidores de back-end. Isto permite que os aplicativos não tenham especificado um elemento <machineKey> explícito para continuar a trabalhar com estes ambientes, mesmo se o aplicativo estiver em funcionamento em um farm. Se seu aplicativo estiver funcionando em um serviço de hospedagem de terceiros, entre em contato com seu provedor de hospedagem para determinar se esta situação é aplicada a você.

  • Resolução 1b: Habilitar afinidade no balanceador de carga

    Se seus sites estão operando por trás de um balanceador de carga, é possível habilitar a afinidade do servidor para resolver temporariamente o problema. Isso ajuda a garantir que qualquer cliente interaja apenas com um servidor físico por trás do balanceador de carga para que todas as cargas de pagamento criptografadas sejam geradas e consumidas pelo mesmo servidor.

    Isto não deve ser considerado uma solução a longo prazo para o problema. Mesmo quando a afinidade do servidor é habilitada, a maioria dos balanceadores de carga irão redirecionar o cliente para um servidor físico diferente se o servidor original no qual os balanceadores de carga são afinizados ficam offline. Isso faz com que o novo servidor rejeite as cargas de pagamento criptografadas (como __VIEWSTATE, bilhetes de autenticação de formulários, tokens anti-falsificação MVCs e outros serviços) que o cliente tem no momento.

    Usar um elemento <machineKey> explícito e reimplantar o aplicativo deve ser preferido ao invés de habilitar a afinidade do servidor.

Motivo 2: O processo do trabalhador usa a identidade do grupo do aplicativo IIS 7.0

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) introduzido naidentidade do pool de aplicativo, a um novo mecanismo de isolamento que ajuda a fornecer maior segurança para servidores que executam aplicativos ASP.NET. No entanto, sites executando sob a identidade do pool de aplicativos não têm acesso ao Registro HKCU. Este é o local onde o tempo de execução ASP.NET armazena suas chaves <machineKey> geradas automaticamente. O resultado é que o ASP.NET não pode persistir na chave gerada automaticamente quando o pool de aplicativos é reiniciado. Portanto, sempre que o w3wp.exe é reiniciado, uma nova chave temporária é gerada.

Observação Este não é um problema no IIS 7.5 (Windows 7, Windows Server 2008 R2) e versões posteriores. Nestas versões de IIS, o ASP.NET pode persistir suas chaves geradas automaticamente em um local diferente que sobrevive à reinicialização do pool de aplicativos.
  • Resolução 2a: Use o utilitário aspnet_regiis

    Instalações do ASP.NET contêm um utilitário, aspnet_regiis.exe. Este utilitário permite que interface ASP.NET com IIS para realizar configurações necessárias para executar um aplicativo gerenciado. Uma destas configurações cria as chaves necessárias no núcleo do Registro para habilitar a persistência de chaves de máquina geradas automaticamente.

    Primeiro, você precisa determinar qual pool de aplicativo seu site está usando. Isso pode ser determinado usando o utilitário inetmgr incluído com o IIS. Selecione seu site na exibição em árvore à esquerda, clique com o botão direito do mouse em Gerenciar site e clique em Configurações Avançadas. A caixa de diálogo exibida mostrará o nome do pool de aplicativos.

    Recolher esta imagemExpandir esta imagem
    Configurações avançadas


    Para scaffold as chaves de Registro adequadas para um pool de aplicativos ASP.NET 4.0, siga estas etapas:
    1. Abra um prompt de comando administrativo.
    2. Localize o diretório adequado, dependendo se seu pool de aplicativos é de 32 bits ou 64 bits:
      • Pool de aplicativos de 32 bits: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • Pool de aplicativos de 64 bits: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. Vá para o diretório, digite o seguinte comando e pressione Enter:

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

    Se o pool de aplicativos é 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 adequado, dependendo se seu pool de aplicativos é de 32 bits ou 64 bits:
      • Pool de aplicativos de 32 bits: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • Pool de aplicativos de 64 bits: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Vá para o diretório, digite o seguinte comando e pressione Enter:

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

    Por exemplo, se seu pool de aplicativos é chamado My App Pool (como na imagem anterior), execute o seguinte comando:
     
    aspnet_regiis -ga "IIS APPPOOL\My App Pool"


    Observação Os serviços do sistema APPHOSTSVC e WAS podem precisar estar executando o utilitário aspnet_regiis para resolver nomes IIS APPPOOL\* adequadamente.

  • Resolução 2b: Criar um elemento <machineKey> explícito

    Ao adicionar um elemento <machineKey> explícito ao arquivo Web.config do aplicativo, o desenvolvedor diz ao ASP.NET para não usar a chave de criptografia gerada automaticamente. Consulte o Anexo A para obter instruções sobre como gerar um elemento <machineKey>.


Motivo 3: O pool de aplicativos é configurado usando LoadUserProfile=false

Se o pool de aplicativos estiver funcionando com uma identidade personalizada, o IIS pode não ter carregado o perfil de usuário para a identidade. Isto tem um efeito colateral ao tornar o Registro HKCU indisponível para o ASP.NET para persistir a <machineKey> gerada automaticamente. Portanto, uma nova chave gerada automaticamente será criada sempre que o aplicativo reiniciar. Consulte a seção Perfil do Usuário no site da Microsoft para obter mais informações.
  • Resolução 3a: Use o utilitário aspnet_regiis

    As instruções para isto são as mesmas da Resolução 2a. Consulte essa seção para obter mais informações.

  • Resolução 3b: Use um <machineKey> explícito

    Ao adicionar um elemento <machineKey> explícito ao arquivo Web.config do aplicativo, o desenvolvedor diz ao ASP.NET para não usar a chave de criptografia gerada automaticamente. Consulte o Anexo A para obter instruções sobre como gerar um elemento <machineKey>.

  • Resolução 3c: Provisão das chaves de Registro HKCU necessárias manualmente

    Se não for possível executar o utilitário aspnet_regiis, é possível usar um script Windows PowerShell para provisionar as chaves de Registro adequadas no HKCU. Consulte o Anexo B para obter mias informações.

  • Resolução 3d: Definir LoadUserProfile=true para este pool de aplicativo

    Também é possível habilitar o carregamento do perfil do usuário dentro deste pool de aplicativos. Isto torna o núcleo de registro HKCU, a pasta temporária e outros locais de armazenamento específicos do usuário disponível no aplicativo. No entanto, isso pode causar aumento de uso de disco ou memória para o processo do trabalhador. Consulte o elemento <processModel> para obter mais informações sobre como habilitar esta configuração.

Motivo 4: A propriedade Page.ViewStateUserKey tem um valor incorreto

Os desenvolvedores de software podem decidir usar a propriedade Page.ViewStateUserKey para adicionar proteção contra falsificação de solicitação entre sites ao campo __VIEWSTATE. Se você usar a propriedade Page.ViewStateUserKey, está geralmente definida para um valor como o nome do 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 amostras que usam esta propriedade. Consulte o tópico Propriedade Page.ViewStateUserKey no site do Microsoft Developer Network (MSDN) para obter mais informações.

Se a propriedade ViewStateUserKey for especificada, seu valor é gravado no __VIEWSTATE no momento da geração. Quando o campo __VIEWSTATE é consumido, o servidor verifica a propriedade ViewStateUserKey da página atual e valida contra o valor usado para gerar o campo __VIEWSTATE. Se os valores não correspondem, a solicitação é rejeitada como possivelmente maliciosa.

Um exemplo de uma falha relacionada ao ViewStateUserKey seria um cliente com duas guias abertas no navegador. O cliente é armazenado como o 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 sai e entra novamente como um 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 diz o cookie de autenticação do cliente). No entanto, o campo __VIEWSTATE que o cliente enviou contém o "Usuário A". Esta falta de correspondência causa a falha.
  • Resolução 4a: Verifique se o ViewStateUserKey está definido corretamente

    Se seu aplicativo usa a propriedade ViewStateUserKey, verifique se o valor da propriedade é a mesma quando o estado de exibição for gerado e quando for consumido. Se você estiver usando o nome de usuário conectado atualmente, certifique-se de que o usuário esteja conectado e que a identidade do usuário não tenha sido alterada no momento da postagem. Se você estiver usando o identificador da sessão do usuário atual, certifique-se de que a sessão não tenha esgotado o tempo.

    Se você estiver executando em um ambiente do farm, certifique-se de que os elementos <machineKey> correspondem. Consulte o Anexo A para obter instruções sobre como gerar esses elementos.

Anexo A: Como gerar um elemento <machineKey>

Aviso de segurança

Há vários sites que irão gerar um elemento <machineKey> para você com o clique de um botão. Nunca use um elemento <machineKey> obtido de um destes sites . É impossível saber se estas chaves foram criadas com segurança ou se estão sendo gravadas em um banco de dados secreto. Você nunca deve usar os elementos de configuração <machineKey> que criou sozinho.


Para gerar um elemento <machineKey> sozinho, é possível usar o seguinte script Windows PowerShell:

# Gera um elemento <machineKey> que pode ser copiado e colado em um arquivo Web.config.
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)
  }
}

For ASP.NET 4.0 applications, you can just call Generate-MachineKey without parameters to generate a <machineKey> element as follows:

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

ASP.NET 2.0 and 3.5 applications do not support HMACSHA256. Instead, you can specify SHA1 to generate a compatible <machineKey> element as follows:

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

As soon as you have a <machineKey> element, you can put it in the Web.config file. The <machineKey> element is only valid in the Web.config file at the root of your application and is not valid at the subfolder level.

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

Para obter uma lista completa de algoritmos suportados, execute help Generate-MachineKey no prompt do Windows PowerShell.

Anexo B: Provisionar o Registro para persistir chaves geradas automaticamente

Por padrão, como as chaves geradas automaticamente ASP.NETs são persistidas no registro HKCU, essas chaves podem ser perdidas se o perfil do usuário não tiver sido carregado no processo do trabalhador IIS e o pool de aplicativos reciclar. Este cenário pode afetar os provedores de hospedagem compartilhados executando pools de aplicativo como contas de usuário do Windows padrão.

Para resolver essa situação, o ASP.NET habilita a persistência das chaves geradas automaticamente no Registro HKLM em vez do Registro HKCU. Isso é geralmente realizado usando o utilitário aspnet_regiis (consulte as instruções na seção "Resolução 2a: Use o utilitário aspnet_regiis"). No entanto, para administradores que não desejam executar este utilitário, o seguinte script Windows PowerShell pode ser usado:

# Provisione o Registro HKLM para que a conta de usuário especificada possa persistir chaves de máquina geradas automaticamente.
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 {
    # Exigimos permissões administrativas para continuar.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "Este cmdlet exige permissões de administrador."
        return
    }
    # Abra o HKLM com uma exibição adequada no Registro
    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 seguinte exemplo mostra como provisionar as entradas de Registro HKLM adequadas para um pool de aplicativos que funciona como o usuário, example@contoso.com (este é o UPN da conta de usuário do Windows). Este pool de aplicativos é um pool de aplicativos 32 bits executando o CLR v2.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 for de 64 bits executando o CLR v4.0 (ASP.NET 4.0 ou 4.5), o comando é o seguinte:

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

Mesmo se as chaves geradas automaticamente sejam armazenadas no HKLM, a subchave do Registro que mantém o material criptografado do segredo da conta do usuário é adicionada a uma lista de controle de acesso (ACL) para que o material criptografado não possa ser lido por outras contas do usuário.

Anexo C: Criptografar o elemento <machineKey> nos arquivos de configuração

Administradores do servidor podem não solicitar informação privada como o material principal <machineKey> para ser formulário plaintext nos arquivos de configuração. Se este for o caso, os administradores podem decidir tirar vantagem de um recurso .NET Framework conhecido como "configuração protegida". Este recurso permite criptografar determinadas seções dos arquivos .config. Se o conteúdo destes arquivos de configuração nunca forem divulgados, os conteúdos das seções permanecerão secretos.

Você pode encontrar uma breve visão geral da configuração protegida no site MSDN. Também contém um tutorial sobre como proteger os elementos <connectionStrings> e <machineKey> do arquivo Web.config.
Observação: este é um artigo de ?PUBLICAÇÃO RÁPIDA? criado diretamente pela organização de suporte da Microsoft. As informações aqui contidas são fornecidas no presente estado, em resposta a questões emergentes. Como resultado da velocidade de disponibilização, os materiais podem incluir erros tipográficos e poderão ser revisados a qualquer momento, sem aviso prévio. Consulte os Termos de Uso para ver outras informações.

Propriedades

ID do artigo: 2915218 - Última revisão: sexta-feira, 20 de junho de 2014 - Revisão: 2.0
A informação contida neste artigo aplica-se a:
  • Microsoft .NET Framework 4.5.1 Release Candidate
  • Microsoft .NET Framework 4.5.1
  • Microsoft .NET Framework 4.5
  • Microsoft .NET Framework 4.0
  • Microsoft .NET Framework 3.5.1
  • Microsoft .NET Framework 3.5
  • Microsoft .NET Framework 2.0 Service Pack 2
  • Microsoft .NET Framework 1.1 Service Pack 1
Palavras-chave: 
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com