AspxErrorPath en la página de error personalizado

Actualmente tenemos una página que se utiliza para mostrar un mensaje de error genérico cuando se producen errores en nuestro sitio web. No tiene otra funcionalidad que mostrar una etiqueta que menciona que hubo un error.AspxErrorPath en la página de error personalizado

Este es mi problema, nuestro cliente ha realizado una revisión de seguridad y nos dice que nuestra página de error contiene phishing debido a la URL en la cadena de consulta, ahora no lo considero un problema, sino para poner fin al pregunta, me gustaría eliminar la cadena de consulta.

Mi entrada web.config es la siguiente:?

<customErrors mode="On" defaultRedirect="~/DefaultErrorPage.aspx"> 
</customErrors>

Cuando se produce un error, se va a DefaultErrorPage.aspx aspxerrorpath =/WebSite1/LastPage.aspx

¿Cómo puedo evitar que esto ? Sin embargo, podría simplemente redireccionar a la página si contiene la consulta, pero estoy buscando una manera de evitar la cadena de consulta en lugar de una redirección adicional.

Fuente

2011-01-18 jaekie

se puede coger/manejar todos los errores en el archivo global.asax lugar y hacer la redirección no

protected void Application_Error(object sender, EventArgs e) 
    { 
     //Exception ex = Server.GetLastError(); 

     Server.Transfer("~/DefaultErrorPage.aspx"); 
    }

Fuente

2011-01-18 16:28:56 jumpdart

Esto funcionará ... hasta que Microsoft agregue un =) – jaekie

Lamentablemente, esto no funciona si el error está en Application_Start. "La solicitud no está disponible en este contexto" –

@ noah1989 Por "no funciona", ¿quiere decir que todavía permite a los auditores de seguridad pensar que existe algún tipo de vulnerabilidad de scripts entre sitios? ¿O simplemente necesita usar un mecanismo diferente para diagnosticar errores en ese caso? –

Usted va a tener que tomar el control del proceso de gestión de errores usted mismo. Un método es deshacerse de la redirección de error personalizado y utilizar el método Application_Error en global. A continuación, puede dirigir a la persona, según sea necesario, sin ningún argumento de cadena de consulta.

Otra opción es ELMAH, que está diseñado para evitar la pantalla amarilla de errores de muerte en ASP.NET. A continuación, puede adaptar un error amigable y no preocuparse por escribir el código de manejo de errores, per se.

Un tercer método es educar al equipo de seguridad sobre cómo funciona ASP.NET y ver si la "preocupación de seguridad" es legítima (puede ser) o no. Esto no significa que no harán que hagas una de las opciones anteriores de todos modos, por supuesto.

Fuente

2011-01-18 16:29:15

Me encantaría usar ELMAH, lo uso en mis proyectos hogareños, pero mis clientes restringen el 99% de nuestros terceros y el 100% de los terceros de código abierto. – jaekie

Como una solución rápida, he encontrado que se agrega "?" al final de la configuración de defaultRedirect funcionó para mí al eliminar aspxerrorpath.

Además, yo estaba recibiendo el mismo problema con la configuración customErrors en system.web, y la misma solución trabajado:

<customErrors mode="On" defaultRedirect="~/SystemError.aspx"> 
    <error statusCode="403" redirect="~/Home.aspx?"/> 
    <error statusCode="404" redirect="~/Home.aspx?"/> 
</customErrors>

Alternativamente, hacer lo mismo en la configuración system.webServer:

<httpErrors errorMode="Custom"> 
    <remove statusCode="403" subStatusCode="-1" /> 
    <error statusCode="403" path="/Home.aspx?" responseMode="Redirect" /> 
    <remove statusCode="404" subStatusCode="-1" /> 
    <error statusCode="404" path="/Home.aspx?" responseMode="Redirect" /> 
</httpErrors>

Fuente

2014-01-15 11:59:21

AspxErrorPath en la página de error personalizado

Respuesta

Cuestiones relacionadas