• Artigo

Este artigo foi traduzido por máquina.

Informativos sobre segurança

Segurança do estado de exibição

Bryan Sullivan

Gerenciar com eficiência o estado do usuário em aplicativos da Web pode ser complicado, equilíbrio de segurança, facilidade de manutenção, escalabilidade e desempenho. A consideração de segurança é especialmente evidente quando você estiver gerenciando o estado do usuário armazenado no cliente. Eu tenho um colega que costumava dizer a esse estado distribuição dados para um cliente são parecido com um cone de sorvete de envio para um 5 anos de idade: Você pode recuperá-lo, mas definitivamente não é possível esperar obtê-lo novamente na mesma forma que ele era quando você fez check-out!

Na coluna deste mês, examinaremos algumas implicações de segurança em relação ao gerenciamento de estado do lado do cliente nos aplicativos asp.net; especificamente, vamos examinar a segurança do estado de exibição. (Observação: Este artigo presume que você está familiarizado com o conceito de estado de exibição do asp.net. Se não for, fazer check-out “ do Understanding ASP.NET View State ” por Scott Mitchell).

Se você Don acha que existe em todos os dados armazenados no estado de exibição de seus aplicativos ’ que vale a pena protegendo, pense novamente. Informações confidenciais podem encontrar seu caminho para o estado de exibição sem que você ainda perceber. E mesmo que você esteja vigilante sobre como evitar a perda de informações confidenciais por meio de um estado de exibição, um invasor pode ainda violar que o estado de exibição e causar problemas ainda maiores para você e seus usuários. Felizmente, o asp.net tem algumas defesas internas contra esses ataques. Let’s dê uma olhada em como essas defesas podem ser usadas corretamente.

Ameaça ' não '. 1: Divulgação de informações

Na Microsoft, as equipes de desenvolvimento, use o modelo STRIDE para classificar as ameaças. FVRDNE é um mnemônico significa:

  • Falsificação
  • Violação
  • Repúdio
  • Divulgação de informações
  • Negação de serviço
  • Elevação do privilégio

As duas principais categorias STRIDE preocupação da perspectiva de segurança do modo de exibição de estado são violação e divulgação de informações (apesar de uma violação com êxito o ataque pode levar a uma possível elevação de privilégio; discutiremos que mais detalhadamente mais adiante). Divulgação de informações é mais simples essas ameaças para explicar, portanto, discutiremos esse primeiro.

Um dos erros de concepção mais Infelizmente persistentes ao redor de um estado de exibição é o que é alguma forma ilegível ou criptografados pelo usuário. Afinal, uma seqüência de caracteres do estado de exibição, certamente, não parece estar decomposable:

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

No entanto, essa seqüência de caracteres está simplesmente codificado na base64, não são criptografadas com qualquer tipo de algoritmo criptograficamente forte. Podemos facilmente decodificar e desserializar essa seqüência de caracteres usando a classe de formatador de serialização (LOS) do objeto limitado System.Web.UI.LosFormatter:

LosFormatter formatter = new LosFormatter();
object viewstateObj = formatter.Deserialize("/wEPDwULLTE2MTY2ODcyMjkPFgIeCHBhc3N3b3JkBQlzd29yZGZpc2hkZA==");

Uma olhada rápida no depurador (veja a Figura 1 de ) revela que o objeto de estado de exibição desserializada é na verdade, uma série de objetos de System.Web.UI.Pair terminando com um objeto System.Web.UI.IndexedString com um valor de “ senha ” e um valor de seqüência de caracteres correspondente de “ swordfish ”.

Figure 1 Secret View State Data Revealed by the Debugger

Figura 1 de revelação de dados do estado do modo de exibição de segredo, o depurador

Se você Don quiser ir para o trabalho de escrever seu próprio código para desserializar objetos de estado de exibição, existem vários bons de view state 
decoders disponíveis baixar gratuitamente na Internet, incluindo a ferramenta de decodificador de ViewState de Fritz Onion disponível em alt.pluralsight.com/tools.aspx de .

Criptografar o estado de exibição

Em “ O ciclo de vida do desenvolvimento de segurança: SDL: Um processo de desenvolvimento comprovadamente mais de Secure Software ” (Microsoft Press, 2006), Michael Howard e Steve Lipner discutem tecnologias que podem ser usadas para atenuar as ameaças STRIDE.A Figura 2 mostra os tipos de ameaça e suas técnicas de mitigação associado.

A Figura 2 do técnicas para reduzir ameaças de STRIDE

Tipo de ameaça Técnica de atenuação
Falsificação Autenticação
Violação Integridade
Repúdio Serviços não-repúdio
Divulgação de informações Confidencialidade
Negação de serviço Disponibilidade
Elevação do privilégio Autorização

 

Como estamos lidando com uma ameaça de divulgação de informações sobre os dados armazenados no estado de exibição, precisamos aplicar uma técnica de atenuação de confidencialidade; nesse caso, a tecnologia de atenuação mais eficaz confidencialidade é criptografia.

O asp.net versão 2. 0 tem um recurso interno para habilitar a criptografia do estado de exibição — a propriedade ViewStateEncryptionMode, que pode ser ativada por meio de uma diretiva de página ou arquivo de Web. config do aplicativo:

<%@ Page ViewStateEncryptionMode="Always" %>

Ou

<configuration>
   <system.web>
      <pages viewStateEncryptionMode="Always">

Existem três valores possíveis para ViewStateEncryptionMode: Sempre (o estado de exibição é sempre criptografado); nunca (o estado de exibição nunca é criptografado); e auto (o estado de exibição somente será criptografado se um dos controles da página explicitamente solicitá-la). Os valores sempre e nunca são bastante auto-explicativos, mas automática requer um pouco mais de explicação.

Se um controle servidor persistir informações confidenciais em estado de exibição da sua página, o controle pode solicitar que a página criptografar o estado de exibição, chamando o método Page.RegisterRequiresViewStateEncryption (Observe que nesse caso o estado de exibição inteiro é criptografado, não apenas o estado de exibição correspondente ao controle que o solicitou):

public class MyServerControl : WebControl
{
   protected override void OnInit(EventArgs e)
   {
      Page.RegisterRequiresViewStateEncryption();
      base.OnInit(e);
   }
   ...
}

No entanto, há uma advertência. O motivo pelo qual que o método é chamado RegisterRequiresViewStateEncryption e não algo como EnableViewStateEncryption, é porque a página pode optar por ignorar a solicitação. Se ViewStateEncryptionMode da página é definido como auto (sempre), será concedida a solicitação do controle e o estado de exibição será criptografado. Se ViewStateEncryptionMode é definido como nunca, solicitação do controle de será ignorada e o estado de exibição estará desprotegido.

Isso é definitivamente algo para ficar atento se você for um desenvolvedor de controles. Você deve considerar a manter informações potencialmente confidenciais fora do estado de exibição (que é sempre uma boa idéia). Em casos extremos em que isso não é possível, considere a possibilidade de substituir métodos do controle de SaveViewState e LoadViewState para criptografar e descriptografar o estado de exibição lá de manualmente.

Considerações do farm de servidor

Em um ambiente de servidor único, é suficiente apenas ativar ViewStateEncryptionMode, mas em um ambiente de farm de servidor, há algum trabalho adicional para fazer. Algoritmos de criptografia simétrica — como aqueles que o asp.net usa para criptografar o estado de exibição — requer uma chave. Você pode especificar explicitamente uma chave no arquivo Web. config ou o asp.net pode gerar automaticamente uma chave para você. Novamente, em um ambiente de servidor único é excelente permitir que a estrutura de lidar com a geração de chave, mas isso não funcionará para um farm de servidores. Cada servidor irá gerar a chave exclusiva de seu próprio e solicitações obtém 
balanced de carga entre servidores diferentes irão falhar porque as chaves de descriptografia não correspondem.

Você pode definir explicitamente o algoritmo criptográfico e a chave para usar no elemento machineKey do arquivo de Web. config do aplicativo:

<configuration>
   <system.web>
      <machineKey decryption="AES" decryptionKey="143a...">

Para o algoritmo de criptografia, você pode escolher o AES (o valor padrão), DES ou 3DES. Dessas, DES é explicitamente proibidos pelos padrões de criptografia Microsoft SDL e o 3DES é fortemente desencorajado. Eu recomendo que você fique com o AES para segurança máxima.

Depois que você selecionou um algoritmo, você precisa criar uma chave. No entanto, lembre-se de que a força da segurança do sistema, este depende do nível de segurança dessa chave. Don use o nome do seu bicho de estimação, aniversário a outra de significativos ou qualquer outro valor facilmente guessable! Você precisa usar um número aleatório criptograficamente forte. Eis aqui um trecho de código para criar um formato que o elemento machineKey espera (apenas caracteres hexadecimais) usando a classe .net RNGCryptoServiceProvider:

RNGCryptoServiceProvider csp = new RNGCryptoServiceProvider();
byte[] data = new byte[24];
csp.GetBytes(data);
string value = String.Join("", BitConverter.ToString(data).Split('-'));

No mínimo, você deve gerar valores de 16 bytes aleatórios para suas chaves; esse é o valor mínimo permitido pelos padrões de criptografia do SDL. O comprimento máximo com suporte para chaves AES é 24 bytes (48 caracteres hexadecimais) no Microsoft .NET Framework 3. 5 e versões anterior e 32 bytes (64 caracteres hexadecimais) no .NET Framework 4. DES oferece suporte a um comprimento de chave máximo de apenas 8 bytes e 3DES máximo, 24 bytes, independentemente da versão do framework. Novamente, eu recomendo que você evite a esses algoritmos e usa o AES.

Ameaça ' não '. 2: Violação

Violação é a ameaça significativa. Você pode achar mesmo defesa de criptografia que mantém os invasores contra olhares em estado de exibição também impediria que eles alterem, mas isso está errado. Criptografia não fornece defesa contra violação: Mesmo com os dados criptografados, ainda é possível para que um invasor Inverter bits de dados criptografados.

Examine outra do Figura 2. Para atenuar a ameaça de violação, precisamos usar uma tecnologia de integridade de dados. A melhor opção ainda é uma forma de criptografia e ele ainda está embutido no asp.net, mas em vez de usar um algoritmo simétrico para criptografar os dados, vamos usar um algoritmo de hash para criar um message authentication code (MAC) para os dados.

O recurso do asp.net para aplicar um MAC é chamado de EnableViewStateMac e como ViewStateEncryptionMode, você poderá aplicá-lo por meio de uma diretiva de página ou por meio de um arquivo de Web. config do aplicativo:

<%@ Page EnableViewStateMac="true" %>

Ou

<configuration>
   <system.web>
      <pages enableViewStateMac="true">

Para entender o que EnableViewStateMac realmente está fazendo nos bastidores, let’s primeiro vejamos alto nível como o modo de exibição de estado é gravado para a página quando o estado de exibição MAC é não ativado:

  1. Estado de exibição para a página e todos os controles de participantes é reunido em um objeto de gráfico de estado.
  2. O gráfico de estado é serializado em um formato binário.
  3. A matriz de bytes serializado está codificada em uma seqüência base-64.
  4. A seqüência de caracteres base-64 é gravada para o valor _ _ VIEWSTATE do formulário na página.

Quando o estado de exibição MAC estiver habilitado, há três etapas adicionais que ocorrem entre as etapas anteriores 2 e 3:

  1. Estado de exibição para a página e todos os controles de participantes é reunido em um objeto de gráfico de estado.
  2. O gráfico de estado é serializado em um formato binário.
    a. um valor de chave secreto é acrescentado à matriz de bytes serializado.
    b. um hash criptográfico é calculado para a nova matriz de bytes de serializado.
    c. o hash é acrescentado ao final da matriz de bytes serializado.
  3. A matriz de bytes serializado está codificada em uma seqüência base-64.
  4. A seqüência de caracteres base-64 é gravada para o valor _ _ VIEWSTATE do formulário na página.

Sempre que esta página é remetida de volta para o servidor, o código de página valida a entrada _ _ VIEWSTATE, tirando a entrada dados gráficos (desserializados a partir do valor de _ _ VIEWSTATE), adicionando o mesmo valor de chave secreto e recomputing o valor de hash de estado. Se o novo valor de hash recomputed coincidir com o valor de hash fornecido no final da entrada _ _ VIEWSTATE, o estado de exibição é considerado válido e o processamento continua (consulte do Figura 3). Caso contrário, o estado de exibição é considerado tenha sido violado e uma exceção é lançada.

A Figura 3 aplicando um Message Authentication Code (MAC)

A segurança deste sistema reside no sigilo do valor da chave secreto. Esse valor é sempre armazenado no servidor, seja na memória ou em uma configuração de arquivo (mais adiante) — jamais é gravada para a página. Sem saber a chave, não haveria nenhuma maneira para que um invasor computar um hash do estado de exibição válido.

Teoricamente, com bastante poder de computação o invasor poderá reverter a engenharia a chave: Ele tem conhecimento de um valor de hash computado e o conhecimento de que o texto não criptografado correspondente, e não existem muitas opções disponíveis para o algoritmo de hash. Ele teria apenas percorrer todos os possíveis valores de chaves, recalcule o hash para o texto sem formatação conhecido, além da chave atual e compará-lo com o hash conhecido. Depois que os valores coincidirem, ele sabe que ele encontrou o ataque de agora chave e pode correto do sistema à vontade. O único problema com este é o enorme número de valores possíveis: O tamanho da chave padrão é 512 bits, o que significa que há 2 à potência de 512 diferentes possibilidades, que é tão grande que um ataque de força bruta é completamente unfeasible de um número.

Explorando a menor MAC View State.

O valor padrão de EnableViewStateMac é verdadeiro, portanto, proteger seus aplicativos é tão simples quanto não defini-la como false. Infelizmente, há alguma documentação enganosa sobre o impacto de desempenho de EnableViewStateMac e alguns sites da Web está incentivando a desenvolvedores para desativar o estado de exibição MAC para melhorar o desempenho de seus aplicativos. Até mesmo a documentação online do MSDN para PagesSection.EnableViewStateMacProperty é culpada deste, informando: “ Não defina EnableViewStateMac como verdadeiro se o desempenho é uma consideração de chave. ” Não siga esse conselho! (Felizmente, no momento em que você está lendo este artigo, a documentação irá ter sido alterada para refletir melhor as considerações de segurança.)

Qualquer página que tem seu estado de exibição desabilitado MAC é potencialmente vulnerável a ataques de script entre sites contra o parâmetro _ _ ViewState. O primeiro à prova de conceito desse ataque foi desenvolvido por David Byrne de Trustwave e demonstrado pelo Byrne e seu colega Rohini Sulatycki na conferência Black Hat DC em fevereiro de 2010. Para executar esse ataque, os invasor de artesanatos um gráfico de estado de exibição onde ele deseja executar o código de script mal-intencionado é definido como persistente valor da propriedade innerHtml do elemento de formulário da página. No formulário XML, este gráfico de estado de exibição seria algo como do Figura 4.

Figura 4 do código XML para o ataque de MAC do estado de exibição

<viewstate>
  <Pair>
    <Pair>
      <String>...</String>
      <Pair>
        <ArrayList>
          <Int32>0</Int32>
          <Pair>
            <ArrayList>
              <Int32>1</Int32>
              <Pair>
                <ArrayList>
                  <IndexedString>innerhtml</IndexedString>
                  <String>...malicious script goes here...</String>
                </ArrayList>
              </Pair>
            </ArrayList>
          </Pair>
        </ArrayList>
      </Pair>
    </Pair>
  </Pair>
</viewstate>

Em seguida, o invasor base 64 codifica o estado de exibição mal-intencionado e o acrescenta a essa seqüência de caracteres como o valor de um parâmetro de seqüência de caracteres de consulta de _ _ VIEWSTATE para a página vulnerável. Por exemplo, se a página home.aspx em www.contoso.com o site era conhecido para que o estado de exibição MAC desativado, o URI de ataque seria https://www.contoso.com/home.aspx?\_\_VIEWSTATE=/w143a...

Tudo o que resta é enganar a vítima potencial para seguir este link. Em seguida, o código da página irá desserializar o estado de exibição do parâmetro de seqüência de caracteres de consulta _ _ VIEWSTATE entrada e gravar o script mal-intencionado como o innerHtml do formulário. Quando a vítima obtém a página, script do invasor será imediatamente executado no navegador da vítima, com as credenciais da vítima.

Esse ataque é especialmente perigoso porque ignora completamente todas as usuais defesas cross-site scripts (XSS). O filtro de XSS no Internet Explorer 8 não irá bloqueá-lo. O recurso de ValidateRequest do asp.net bloqueará vários vetores comuns de ataques XSS, mas não desserializar e analisar o estado de exibição de entrada, portanto, é também não há Ajuda nessa situação. A biblioteca Microsoft Anti-Cross Site Scripting (Anti-XSS) (agora incluída como parte da biblioteca de proteção do Microsoft Web) é ainda mais efetiva contra o XSS que ValidateRequest; no entanto, nem a biblioteca de Anti-XSS entrada a limpeza de recursos nem sua codificação recursos protegerá contra esse ataque ou de saída. A defesa apenas real é garantir esse estado de exibição que Mac consistentemente é aplicada a todas as páginas.

Obter mais considerações de farm de servidor

Da mesma forma que ViewStateEncryptionMode, há considerações especiais com EnableViewStateMac durante a implantação de aplicativos em um ambiente de server farm. O valor secreto utilizado para o hash do estado de exibição deve ser constante em todas as máquinas do farm ou falha da validação do estado de exibição.

Você pode especificar a chave de validação e o algoritmo HMAC para usar no mesmo local em que você especificar o algoritmo e a chave de criptografia do estado de exibição — o elemento machineKey do arquivo Web. config:

<configuration>
   <system.web>
      <machineKey validation="AES" validationKey="143a...">

Se seu aplicativo é compilado no .NET Framework 3. 5 ou anterior, você pode escolher o SHA1 (o valor padrão), AES, MD5 ou 3DES como algoritmo de MAC. Se você estiver executando o .NET Framework 4, você também pode escolher o MACs da família SHA-2: HMACSHA256 HMACSHA384 ou HMACSHA512. Uma dessas opções, explicitamente, MD5 é proibido pelos padrões de criptografia do SDL e o 3DES é fortemente desencorajado. Também não que o SHA1 é recomendado, mas para o .NET Framework 3. 5 e anteriores de aplicativos é a melhor opção. Aplicativos do .NET framework 4 definitivamente devem ser configurados com HMACSHA512 ou HMACSHA256 como algoritmo de validação.

Depois de escolher um algoritmo de MAC, também será necessário especificar manualmente a chave de validação. Lembre-se de usar números aleatórios criptograficamente fortes: Se necessário, você pode referir-se ao código de geração de chave especificado anteriormente. Você deve usar a validação de pelo menos 128 bytes chaves para HMACSHA384 ou HMACSHA512 e chaves de pelo menos 64 bytes para qualquer outro algoritmo.

Não é possível ocultar o estado de exibição vulnerável

Ao contrário de um comando de banco de dados pode estar ocultos profunda no código do lado do servidor ou da permissão de arquivo vulnerável, o estado de exibição vulnerável é fácil encontrar apenas olhando para ele. Se quiser que um invasor testar uma página para ver se o seu estado de exibição foi protegido, ele poderia simplesmente fazer uma solicitação para essa página em si e extrair o valor de estado do modo de exibição de codificação base 64 do valor do formulário de _ _ ViewState. Se a classe LosFormatter com êxito pode desserializar esse valor, ele não foram criptografado. É um pouco mais complicado, mas não muito — para determinar se o MAC do estado de exibição tiver sido aplicado.

O MAC sempre será aplicado até o final do valor de estado de exibição e como os tamanhos de hash são constantes para qualquer algoritmo de hash determinado, é relativamente fácil de determinar se um MAC está presente. Se HMACSHA512 tiver sido usado, o MAC poderá ser 64 bytes; se HMACSHA384 tiver sido usado, será 48 bytes e se qualquer outro algoritmo tenha sido usado é 32 bytes. Se você tirar 48 32 ou 64 bytes de final de base 64 decodificada o valor de estado de exibição e qualquer um desses desserializar o LosFormatter no mesmo objeto, como antes, em seguida, tiver sido aplicada MAC do estado de exibição. Se nenhum deles aparada modo de exibição de matrizes de bytes do estado com êxito serão desserializar, então não tenha sido aplicada MAC do estado de exibição e a página é vulnerável.

Casaba Security torna uma ferramenta gratuita para os desenvolvedores chamados Watcher pode ajudar a automatizar esse teste. O Inspetor é um plug-in para ferramenta de proxy depuração da Web o Fiddler de Eric Lawrence e funciona analisando passivamente o tráfego HTTP que flui através do proxy. Ele irá sinalizar todos os recursos possivelmente vulneráveis que passam por — por exemplo, uma página. aspx com um _ _ VIEWSTATE faltando um Mac. Se você ainda não estiver usando o Fiddler e o Gerenciador da como parte do processo de teste, eu recomendo que dá a eles um bloco try.

Resumindo

Segurança do estado de exibição é que nada para subestime, especialmente considerando o novo estado de modo de exibição de violação de ataques que tenham sido demonstrados recentemente. Eu recomendo que você se beneficie dos mecanismos de segurança ViewStateEncryptionMode e EnableViewStateMac incorporado no asp.net.

Bryan Sullivan   é gerente de programa de segurança da equipe do Microsoft Security Development Lifecycle, onde ele é especialista em problemas de segurança de aplicativos da Web. Ele é autor do “ Ajax Security ” (Addison-Wesley, 2007).

Meus agradecimentos aos seguinte especialista técnico para revisar este artigo:   Michael Howard