CryptographicException: el relleno no es válido y no se puede quitar y la validación del MAC del estado de vista falló

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

Pregunta

Supervisando mis registros de excepciones globales, este error parece ser imposible de eliminar, no importa lo que haga, pensé que finalmente me libré de él, pero volvió de nuevo. Puede ver un rastro del error en un publicación similar aquí .

Notas sobre el medio ambiente:

IIS 6.0, .NET 3.5 SP1 servidor único aplicación ASP.NET

Pasos ya tomados: 

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

En mi base de página para todas mis páginas 

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

    Page.ViewStateUserKey = viewStateKey;
  }

También en la fuente de la página puedo ver que todos los campos ocultos generados por ASP.NET están correctamente en la parte superior de la página.

¿Fue útil?

Solución

En primer lugar, comencemos por el hecho de que este estado de error de vista ocurre en PostBack .

También debo decir que he hecho todas las cosas que todos sugieren para evitar este problema. Y tengo una sola máquina, pero 2 grupos que ejecutan las mismas páginas.

Entonces, alguien realiza una acción , busca a un hombre, busca otra máquina de búsqueda 'haciendo clic' en tus páginas, o algún hacker intenta comprobar si tu sistema tiene problemas ...

Tengo problemas similares (raros pero existentes), y finalmente descubrí que la gente intenta hackear mis páginas. (desde la misma IP que tengo y dos ataques)

Modifico la función LoadPageStateFromPersistenceMedium () que traduce el estado de la vista, y ve al registrar qué fue exactamente la entrada, y desde qué IP ... luego comencé a monitorear estos resultados y ver que el estado de vista fue cambiado a mano - o estaba totalmente vacío.

En caso de error, simplemente lo redirijo a la misma página ...

Esto es lo que hice ... 

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ón

Ahora hay una razón más por la que esto puede suceder, y la razón es porque alguien hace clic en su página antes de que se cargue la __EVENTVALIDATION.

Esta EventValidation se coloca en el último botón, incluso el que encontró asp.net, y si tiene algunos de ellos en muchos lugares de la página, o cerca del botón, esto irá al final de la página.

Entonces, incluso si ve el estado de la vista en la parte superior de la página, ¿dónde está la Validación? tal vez esto nunca se cargó: ¿la página está corrupta ?, ¿un usuario demasiado rápido hace clic en la página? 

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

Para evitar este tipo de problema, hice un javascript simple que no dejo presionar el botón a menos que se haya cargado esta entrada.

¡Un comentario más, la __EVENTVALIDATION no siempre está presente! así que quizás sea más seguro no buscar este campo si hace una solución general, sino hacer un truco de javascript para verificar si la página completa está cargada, o algo más que usted piense.

Aquí está mi solución final con jQuery: (tenga en cuenta que verifico en PageLoad si existe una validación de evento). Tengo esto colocado en mis 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();";
    }
}

Puede probar colocando un retraso cerca del botón de su página. 

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

Actualizar

Hoy veo en el registro este mensaje nuevamente para WebResource y lo que descubro es que un bot obtiene las páginas y crea todos los caracteres en los enlaces en minúsculas , incluidos los parámetros, así que esto fue Una razón más para no obtener la cadena codificada correcta y lanzar un mensaje como El relleno no es válido y no se puede eliminar.

Espero que esto te ayude más.

Otros consejos

Una encuesta de las páginas web encontradas con varias de las palabras clave del mensaje de error indica que este tipo de error es relativamente común, generalmente aleatorio (al menos en apariencia) y desafortunadamente rara vez incluye un solución explícita o explicación ...

La existencia de muchas situaciones similares pero diferentes probablemente esté vinculada a las muchas arquitecturas diferentes y configuraciones subyacentes que de alguna manera pueden conducir a la incapacidad de la capa criptográfica para afirmar la autenticidad de los MAC (Códigos de autenticación de mensajes) en el páginas de solicitud:

  • Configuración de la granja de servidores
  • Dominio cruzado / páginas sindicadas
  • bibliotecas de widgets de terceros y tal
  • Lógica real del programa ASP (por supuesto)

Un marcador relativamente frecuente " en torno a estos informes de errores se menciona la solicitud de recursos (por ejemplo, WebResource.axd ).
Tenga en cuenta que tales solicitudes a menudo no se registran (para que no inflen el tamaño de los archivos de registro con un evento de relativamente poco interés). Esta ausencia del archivo de registro y el hecho de que a menudo se almacenan en caché (y, por lo tanto, la ocurrencia aleatoria e infrecuente relativa del error) puede explicar cómo este posible origen del error pasa desapercibido. Esto también sugiere que al intentar recrear el error, (mientras se rastrea en los registros, en tiempo real, etc.) puede ser útil evitar que el navegador web se almacene en caché (o al menos para borrarlo inicialmente).

En resumen, aquí hay algunas ideas y cosas que debe buscar:

  • comenzar a registrar las solicitudes * .axd
  • intente y correlacione tales solicitudes axd con los eventos de error en el registro de excepciones
  • busque páginas con referencias de recursos
  • si está en una configuración de Granja, asegúrese de que todas las instancias usen la misma clave (aparentemente el fragmento proporcionado en la pregunta en varios servidores IIS)
  • Sospeche de páginas con vínculos de terceros (servicios de búsqueda, programas de afiliación ...)

Espero que esto ayude ;-)

¿Está seguro de que su problema está relacionado con la criptografía y no está causado por ViewState de gran tamaño? Si ViewState es el problema, puede fragmentarlo: cambie el valor de las páginas / MaxPageStateFieldLength en web.config

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top