AspxErrorPath in Custom Error Page

We currently has a page that is used to display a generic error message when errors occur on our website. It has no functionality at all other than displaying a label that mentions there was an error.

Here is my issue, our 开发者_高级运维client has ran a security review and tells us our error page contains phishing due to the URL in the query string, now I don't consider this a problem, but to put an end to the question, I'd like to remove the query string.

My web.config entry is this:

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

When an error occurs, it goes to DefaultErrorPage.aspx?aspxerrorpath=/Website1/LastPage.aspx

How can I prevent this? However, I could just redirect to the page if it contains the query, but I'm more looking for a way to prevent the query string instead of an extra redirection.

you could catch/handle all errors in your global.asax file instead and do the redirect there

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

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

As a quick-fix, I've found that appending "?" onto the end of the defaultRedirect setting worked for me in removing the aspxerrorpath.

Also, I was getting the same issue with the customErrors settings in system.web, and the same solution worked:

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

Alternatively, do the same on system.webServer settings:

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

You are going to have to take control of the error handling process yourself. One method is get rid of the custom error redirect and use the Application_Error method in global. You can then direct the person, as needed without any query string argument.

Another option is ELMAH, which is designed to avoid the yellow screen of death errors in ASP.NET. You can then tailor a friendly error and not worry about writing error handling code, per se.

A third method is to educate the security team on how ASP.NET works and see if the "security concern" is legitimate (it may be) or not. This does not mean they won't make you do one of the above options anyway, of course.