HTTP Module intercept requests and breaks custom errors configuration

Question

I have an ASP.NET MVC 5 web application which runs locally on IIS 8.5 and after deployment, on Azure Websites - on both cases, the behavior that will be later described is the same.

I configured in the web.config the following custom errors page management (it covers all my cases of custom errors and it has been tested and it's working great):

<system.webServer>
  <httpErrors errorMode="Custom" existingResponse="Replace">
    <clear />
    <error statusCode="400" responseMode="ExecuteURL" path="/App/Error"/>
    <error statusCode="403" responseMode="ExecuteURL" path="/App/Error/Forbidden" />
    <error statusCode="404" responseMode="ExecuteURL" path="/App/Error/NotFound" />
    <error statusCode="500" responseMode="ExecuteURL" path="/App/Error" />
  </httpErrors>
</system.webServer>

Also, I have an HTTP Module configured in the same web.config like this:

<system.webServer>
<modules>
  <add name="ImageProcessorModule" type="ImageProcessor.Web.HttpModules.ImageProcessingModule, ImageProcessor.Web" />
 </modules>
</system.webServer>

The issue that I have is like this: if I'm making a request to a strange URL like .../c<, the application executes the 500 custom error path as instructed in the web.config file. But, if I'm making a request to a stranger URL (to simulate an html tag) like .../<c, though the resulted error is 500, the custom error is not executed anymore, because accordingly to the detailed error, the HTTP Module intercept the call and "decides" to just show a YSOD...

The message that I get is:

A potentially dangerous Request.RawUrl value was detected from the client (="/App/

And is easy to see that this is caused by the webmodule because of the stacktrace:

[HttpRequestValidationException (0x80004005): A potentially dangerous Request.RawUrl value was detected from the client (="/App/d__10.MoveNext() +201 System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84 System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar) +98 System.Web.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +434 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +288

If I'm commenting out the Image Processor Module from the web.config, everything runs as expected.

Why in this case, the custom error path doesn't get executed?

Thank you for your time and answers.

Infirm

Tangentially related:- #28430094 – Bodycheck

can't get it to work... – Imp

Answer 1

I very strongly suspect this is a bug in Image Processor.

The exact same issue was reported in Client Dependency (a module for Umbraco) which, while completely unrelated, is similar in that it was accessing Context.Request.RawUrl at the same stage of the request pipeline.

You have two options:-

1. Find a way to set runAllManagedModulesForAllRequests="false" without impacting the behaviour of your http modules

2. See if you can submit a patch to https://github.com/JimBobSquarePants/ImageProcessor/blob/f4080c3217107eb7a571eb69e54cc5e69e1c892c/src/ImageProcessor.Web/HttpModules/ImageProcessingModule.cs to use Request.Unverified.RawUrl instead of Request.RawUrl

Bodycheck

Thank you very much. I will check both possibilities to see how which one is best. To be honest, I will try to do #2. Thank you again for your time. LE: I will come back to see which one worked in this situation. – Infirm

Good catch. Option 2 is definitely the best since ImageProcessor doesn't depend on runAllManagedModulesForAllRequests being true but other modules might. – Stagecraft

Yeap - you were right! I've done a local clone of the ImageProcessor.Web project and changed what you suggested and the I took the compiled DLLs and put them into my project and it's working... So you we were right... Now, I have to see if my changes will be accepted because I don't know which are the implication of my change from the security point of view; I changed only two places this: request.RawUrl into request.Unvalidated.RawUrl. – Infirm

I don't think it should be an issue. I'll double check but it should be fine. – Stagecraft