CryptographicException: Preenchimento é inválido e não pode ser removido e validação do viewstate MAC falhou

StackOverflow https://stackoverflow.com/questions/1821243

Pergunta

Monitoramento minha exceção mundial registra este erro parece ser impossível de remover, não importa o que eu faço, eu pensei que finalmente se livrou dele, mas ele está de volta novamente. Você pode ver um traço Strack do erro em uma post semelhante aqui .

Notas sobre o meio ambiente:

O IIS 6.0, .NET 3.5 SP1 único servidor aplicação ASP.NET

medidas já tomadas: 

  <system.web>
    <machineKey validationKey="big encryption key"
      decryptionKey="big decryption key"
      validation="SHA1" decryption="AES" />

Na minha Base de página para todas as minhas páginas 

  protected override void OnInit(EventArgs e)
  {
    const string viewStateKey = "big key value";

    Page.ViewStateUserKey = viewStateKey;
  }

Também na fonte da página que eu posso ver que todo o ASP.NET gerado campos ocultos são corretamente no topo da página.

Foi útil?

Solução

Primeiro de tudo vamos começar a partir do fato de que este erro de estado de exibição acontece no PostBack .

Também devo dizer que tenho feito todas as coisas que cada um sugerem que fazer para evitar este problema. E eu tenho uma única máquina, mas 2 piscinas que funcionam as mesmas páginas.

Assim alguém fazer uma ação , éter um homem, éter alguma outra máquina pesquisa por 'clique' em suas páginas, ou alguma tentativa hacker para verificar o seu sistema para problemas ...

Eu tenho problemas semelhantes (raras, mas os já existentes), e eu finalmente descobriu que as pessoas tentam cortar-test minhas páginas. (A partir do mesmo IP que tenho e ataques DoS)

I Modificar a função LoadPageStateFromPersistenceMedium () que traduzir o estado de visualização, e ver registrando o que exatamente era a entrada, e pelo que IPs ... então eu comecei monitor de estes resultados e ver que o estado de exibição foi alterado com a mão -. ou foi totalmente vazio

Em caso de erro Eu apenas redirecioná-lo para a mesma página ...

Aqui está o que eu fiz ... 

public abstract class BasePage : System.Web.UI.Page
{
    protected override object LoadPageStateFromPersistenceMedium()
    {
        try
        {
            .. return the base, or make here your decompress, or what ever...
            return base.LoadPageStateFromPersistenceMedium();            
        }
        catch (Exception x)
        {
            string vsString = Request.Form[__VIEWSTATE];
            string cThePage = Request.RawUrl;

            ...log the x.ToString() error...
            ...log the vsString...
            ...log the ip coming from...
            ...log the cThePage...

        // check by your self for local errors
            Debug.Fail("Fail to load view state ! Reason:" + x.ToString());
        }

        // if reach here, then have fail, so I reload the page - maybe here you
        // can place somthing like ?rnd=RandomNumber&ErrorId=1 and show a message
        Responce.Redirect(Request.RawUrl, true);        

        // the return is not used after the redirect
        return string.Empty;
    }    
}

segunda razão

Agora há mais uma razão pela qual isso pode acontecer, ea razão é porque alguns um clique na sua página antes da __EVENTVALIDATION é carregado.

Esta eventValidation é colocada sobre o último botão, mesmo que asp.net encontrado, e se você tem alguns deles em muitos lugar na página, ou perto do botão, então este ir para o final da página.

Assim, mesmo se você ver o estado de visualização no topo da página, onde é a validação ??? talvez isso nunca carregado? - página corrupto, o usuário clicar muito rápido na página 

<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" ... >

Para evitar este tipo de problema eu fiz um javascript simples que eu não deixá-lo, pressione o botão a menos que esta entrada ter sido carregado !!!.

Mais um comentário, o __EVENTVALIDATION não é sempre presentes! por isso é talvez mais seguro não procurar este campo se você fizer uma solução geral, mas para fazer um truque javascript apenas para verificar se a página inteira é carregada, ou qualquer outra coisa que você pensa.

Aqui está a minha solução final com jQuery: (! Nota que eu verifico PageLoad se existir eventvalidation). Tenho este colocado em minhas MasterPages. 

<script language="javascript" type="text/javascript">
    function AllowFormToRun()
    {
        var MyEventValidation = $("#__EVENTVALIDATION");

        if(MyEventValidation.length == 0 || MyEventValidation.val() == ""){
            alert("Please wait for the page to fully loaded.");
            return false;
        }

        return true; 
    }       
</script>

protected void Page_Load(object sender, EventArgs e)
{
    // I do not know if Page can be null - just in case I place it.
    if (Page != null && Page.EnableEventValidation)
    {
        Form.Attributes["onsubmit"] = "return AllowFormToRun();";
    }
}

Você pode testar colocando perto do botão de sua página um atraso. 

<% System.Threading.Thread.Sleep(5000); %>

Atualização

Hoje eu vejo no log esta mensagem novamente para WebResource eo que eu descobri é que um bot recebendo as páginas e fazer tudo o personagem nos links em minúsculas , incluindo os parâmetros, de modo que este foi mais uma razão para não conseguir o string codificada correta, e lançar uma mensagem como Preenchimento é inválido e não pode ser removida.

Espero que isso ajuda-lo mais.

Outras dicas

Uma pesquisa das páginas da web encontrados com várias das palavras-chave da mensagem de erro indicam que este tipo de erro é relativamente comum, geralmente aleatória (pelo menos na aparência) e, infelizmente, raramente inclusive de um explícita de contornar ou explicação ...

A existência de muitas situações semelhantes ainda sem diferentes provavelmente está ligada às muitas arquiteturas diferentes e configurações subjacentes que podem de alguma forma levar à incapacidade da camada de criptografia para afirmar a autenticidade dos (códigos de autenticação de mensagens) MAC no páginas de solicitação:

  • configuração do farm de servidores
  • domínio Cross / páginas sindicalizados
  • bibliotecas de widgets de terceiros e tal
  • Actual lógica do programa ASP (é claro)

Um "marcador" relativamente freqüente em torno desses relatórios de bugs é a menção de solicitações de recursos (por exemplo. WebResource.axd ).
Note-se que tais pedidos são muitas vezes Não autenticado (para que não inflar o tamanho arquivos de log com o evento de interesse pouco relativa). Esta ausência do arquivo de log e o fato de que muitas vezes são armazenados em cache (e, portanto, a ocorrência aleatória e pouco frequente relativa do bug) pode explicar como isso possível origem do bug ir "sob o radar". Isso também sugere que, ao tentar recriar o erro, (enquanto o rastreamento nos logs, em tempo real, etc) pode ser útil para evitar que o navegador web a partir de cache (ou pelo menos para limpá-la armazenar em cache inicialmente).

Em suma, aqui estão algumas idéias e coisas para olhar para:

  • começar a registrar o * .axd solicitações
  • tentar e co-relacionar tais pedidos AXD com os eventos de erro no registo de exceção
  • Procure por páginas com referências de recursos
  • se num Exploração agrícola, garantir que todas as instâncias usam a mesma chave (aparentemente o trecho fornecido na dica questão em múltiplos servidores IIS)
  • Suspeite de páginas com 3rd party tie-ins (serviços de pesquisa, programas afiliados ...)

Espero que isso ajude; -)

Tem certeza que seu problema é criptografia relacionados, e não causado por ViewState de grandes dimensões? Se ViewState é o problema, você pode pedaço ele - alterar o valor de páginas / MaxPageStateFieldLength em web.config

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top