When people want to start incorporating e-commerce activities in their site, they must be PCI compliant to do so. There are many different companies/organizations out there that can help you determine if your web site is PCI compliant.
Many criteria must be met to be PCI compliant. One of those criteria is to setup a custom error page. Custom error pages are important because it hides the true error your application may display. The true error messages can be used to dissect and infer the back end design and structure of your web application. Information that can be used to find weaknesses and exploit your web application.
In IIS, there are two types of custom error handling that you can and will need to set on your site. One is the traditional IIS custom error that is normally processed on the IIS level. The other is the ASP.Net custom error handling that is processed on the ASP.Net application level. ASP.Net custom error handling is a bit tricky due to how it is processed through the handlers and depending on where it bombs out, can ultimately determine whether your ASP.Net custom error triggers.
In most cases setting up your ASP.Net custom error handling is straightforward. To achieve this, you simply add the “customErrors” element to your application’s web.config file. The main attribute you will need to ensure is the “mode” attribute within the “customErrors” element. You have three distinct choices. They are “On”, “Off”, or “RemotelyOnly”. You want to set it either for “On” or “RemoteOnly”.
Now here’s a caveat to being PCI compliant, some services will scan your site and test specific conditions to determine whether you have custom error handling enabled. And one of the conditions they may throw at your application is passing a value/URL to your site that is similar to :
https://www.domain.com/[fakefile]?aspxerrorpath=/
which will not display your custom error page. However if you call a file that you know does not exist in your site:
https://www.domain.com/[fakefile]
you will find that your custom error page is displayed.
Confusing? Take a short breather and let me quickly explain.
Your ASP.Net custom error handling does work and the reaction your site invokes when someone calls on your site with the condition of “/[fakefile]?aspxerrorpath=/” is actually by design from Microsoft. This condition in the URL request will stop the process from reaching the custom error handler thus bombing out before it can display your custom error page.
So what’s the solution? The only work around that we can find is to setup a RequestFiltering rule to filter out the string “/[fakefile]?aspxerrorpath=/” from the URL string being called to your site.
In your web.config file input this code in your RequestFiltering element.
<requestFiltering> <denyQueryStringSequences> <add pre="" sequence="<span class=" hiddenspellerror="">aspxerrorpath=" /> </denyQueryStringSequences> </requestFiltering>
Another way to implement this rule is through the IIS 7 or IIS 8 Manager using the RequestFiltering module and setup the rule under the Query Strings tab with the query string “aspxerrorpath= “ set to Deny.
This will block the URL string “/[fakefile]?aspxerrorpath=/” whereby forcing it to call upon the file directly.