Hiya,

Is there a way to customize the page returned by the ISAPI .NET handler when something got wrong and "error occured" is displayed :

We found that its being returned to us as possible XSS issue that we don't know how to resolve if we have no control on the page contents.

Dimitar Hristov

ISAPI .NET Handler? Which is it?

ISAPI had a error pages section [HTML PAGES] in wc.ini where you could specify custom error pages for specific errors.

With the .NET Handler all handler based errors and messages go through a single template in ~/views/_AdminTemplate.html. You can customize that page, but keep in mind this page is used for all error/status messages and the text of the messages are still embedded into this template.

+++ Rick ---

Thanks Rick.

We use the .NET Managed handler indeed but its v5.62 , so I tried to use the web.config section but that had no effect.

The application itself is hit and it returns a different HTML that is being ignored since IIS found that its a dangerous request and that is fine but Burp Scanner call that a reflected XSS issue.

Here is the section in web.config where I try to invoke the custom pages - as you can see I tried to populate the page on few of the keys available.

<webConnectionErrorPages>
    <!-- NOTE: These settings apply only to the Web Connection Managed Module! -->
    <add key="Exception" value="/errorpages/500.html" />
    <add key="OleError" value="/errorpages/500.html" />
    <add key="Timeout" value="" />
    <add key="NoOutput" value="" />
    <add key="Busy" value="" />
    <add key="Maintenance" value="" />
    <add key="InvalidRequestId" value="/errorpages/500.html" />
    <add key="TranmitFileFailure" value="" />
    <add key="PostBufferSize" value="" />
  </webConnectionErrorPages>

Dimitar Hristov

Some errors that occur in IIS (like RequestValidation) will fire IIS errors because they never make it into the Web Connection Handler. IOW, any IIS hard errors (misconfiguration, request validation, authentication etc.) will never reach the Web Connection Handler and thus also not the error handlers and produce stock IIS errors. You can also configure IIS error handler pages.

I'm not sure if those error pages actually work in Web Connection. Those are a hold over from ISAPI, but I can't recall now if those were implemented. They only serve a very limited set of errors basically those that occur during the Web Connection Managed Handler processing. This excludes processing of requests once they reach your Web Connection server which has its own error handling that you can completely control via OnError and ErrorMsg() and StandardPage() handlers in the Process class.

+++ Rick ---

Thanks Rick,

As I mentioned, our app is returning its own page in response but its has been ignored by IIS due to the "dangerous request" being made. Honestly I don't know why it reaches our app at all since the "dangerous" stuff are on the query string and not on the respose payload etc.

But it seems the behaviour is uncontrollable by WWWC framework nor by IIS settings (at least at web app level).

The issue is very annoying since its considered "high risk" for XSS and don't know how to mitigate that. The only possible solution to mitigate the problem is to use

<configuration>
   <system.web>
      <pages validateRequest="false" />
   </system.web>
</configuration>

but then we might become more vulnarable to XSS and may open whole new security hole which we are not aware of.

Given the fact that the message returned is exact copy of what IIS generates as an output (see https://docs.microsoft.com/en-us/aspnet/whitepapers/request-validation ) it seems to me that the managed .NET handler is to be blamed as its not properly encoding the message.

Dimitar Hristov

if you enable ValidateRequest it fires before Web Connection gets control and so you get IIS errors. As said you can create custom IIS error pages - that will trigger on IIS errors that don't make it into Web Connection.

FWIW, ValidateRequest is almost never a good idea as it will trigger on a many totally legit values in form data input from users.

If you're using automated vulnerability testing anything that tests for XSS errors needs to be managed in different ways at the application level by making sure you sanitize output via HtmlEncoding (HtmlEncode() or <%:= %> in templates/scripts). Most automated solutions flag 99% false positives for XSS just because it's not outright returning 500 errors (which is dumb) even though the application (correctly) detects the XSS or properly encodes it.

+++ Rick ---