CryptographicException: el relleno no es válido y no se puede eliminar, y la Validación de viewstate MAC falló

Supervisando mis registros globales de excepciones, este error parece ser imposible de eliminar sin importar lo que haga, pensé que finalmente me deshice de él, pero está de vuelta otra vez. Puedes ver un rastro de error en una publicación similar aquí .

Notas sobre el medio ambiente:

Aplicación ASP.NET de servidor individual IIS 6.0, .NET 3.5 SP1

Pasos ya tomados:

  

En mi página Base 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 de ASP.NET están correctamente en la parte superior de la página.

Antes que nada, 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 cada uno sugiere hacer para evitar este problema. Y tengo una sola máquina, pero 2 piscinas que ejecutan las mismas páginas.

Entonces alguien hace una acción , éter un hombre, éter alguna otra máquina de búsqueda haciendo ‘clic’ en sus páginas, o algún hacker intenta verificar su sistema en busca de problemas …

Tengo problemas similares (raros pero existentes), y finalmente descubrí que las personas intentan hackear mis páginas. (del mismo IP tengo y dos ataques)

Modifico la función LoadPageStateFromPersistenceMedium () que traduce el viewstate, y veo registrando exactamente cuál fue la entrada y de qué IPs … luego comencé a monitorear estos resultados y veo que el estado de la vista se cambió a mano o que estaba totalmente vacío. .

Por error, simplemente lo redirigí a la misma página …

Aquí esta 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 __EVENTVALIDATION.

Este evento de validación se coloca en el último botón, incluso si se encuentra asp.net, y si tiene algunos en muchos lugares de la página o cerca del botón, vaya al final de la página.

Entonces, incluso si ve el viewstate en la parte superior de la página, ¿dónde está la Validación? tal vez este nunca cargado – ¿página corrupta?, usuario demasiado rápido, haga clic en la página?

  

Para evitar este tipo de problema hice un javascript simple que no dejo que presione el botón a menos que esta entrada haya sido cargada.

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

Aquí está mi solución final con jQuery: (tenga en cuenta que verifico en PageLoad si existe lavalidación de eventos). Tengo esto colocado en mis páginas maestras.

  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 cerca del botón de su página un retraso.

 <% 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 hace que todo el carácter en los enlaces esté en minúsculas , incluidos los parámetros, por lo que esta fue una razón más para no obtener la cadena codificada correcta y lanzar un mensaje como Padding no es válido y no se puede eliminar.

Espero que esto te ayude más.

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 una explicación o una solución de problemas explícita …

La existencia de muchas situaciones similares pero diferentes probablemente esté ligada a las muchas architectures diferentes y configuraciones subyacentes que de alguna manera pueden llevar a la incapacidad de la capa de cifrado para afirmar la autenticidad de los MAC (códigos de autenticación de mensajes) en las páginas de solicitud:

  • Configuración de la granja de servidores
  • Cross domain / páginas sindicadas
  • bibliotecas de artilugios de terceros y tal
  • Lógica del progtwig ASP real (por supuesto)

Un “marcador” relativamente frecuente alrededor de estos informes de errores es la mención de las solicitudes de recursos (por ejemplo, WebResource.axd ).
Tenga en cuenta que tales solicitudes a menudo no se registran (a menos que inflen el tamaño de los archivos de registro con un evento de poco interés). Esta ausencia del archivo de registro y el hecho de que a menudo están en la memoria caché (y por lo tanto, la ocurrencia relativa aleatoria y poco frecuente del error) puede explicar cómo este posible origen del error queda “oculto”. Esto también sugiere que al tratar de recrear el error, (mientras rastrea en los registros, en tiempo real, etc.) puede ser útil evitar el almacenamiento en caché del navegador web (o al menos borrarlo inicialmente).

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

  • comience a registrar las solicitudes * .axd
  • intente y correlacione tales solicitudes axd con los eventos de error en el registro de excepciones
  • buscar páginas con referencias de recursos
  • si está en una configuración de conjunto, asegúrese de que todas las instancias usen la misma clave (aparentemente el fragmento provisto en la sugerencia de pregunta en múltiples servidores IIS)
  • Sospeche de páginas con vínculos de terceros (servicios de búsqueda, progtwigs de afiliados …)

Espero que esto ayude 😉

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