Question

Is there anything wrong with having an asp.net page throw a (custom error) if a a required querystring parameter is missing and having global.asax catch it with Application_Error, then transfer the user to an error page? I have several base classes that perform these checks and I am not sure of the best way to communicate the error to a user.

So, something like this:

int reqParam;
if(!isParamSet("myReqParam", out reqParam))
{
   throw new QuerystringParamMissingException();
}

which is then caught by Application_Error in global.asax.

Also, from a security standpoint how much information should I be providing to the user? Just that it was an error, or that a querystring parameter was missing, or which parameter was missing, or maybe even what that parameter indicates is used for?

Answer 1

It all depends on how serious an error it is and whether the user can easily recover from the error.

One view is that the user shouldn’t be able to make invalid calls – all links that require query strings should be validated client side, so during the normal operation of the site all query stings will be complete and valid. Therefore it would be a serious error if there were parameters missing, so raising an exception is a perfectly valid approach.

It would be useful if you want to stop people modifying the query string to gain access to parts of your system they shouldn’t. They’re likely to miss off a parameter and displaying a custom error page might not give them any clues about what they got wrong.

You should log the error though – so at least you know what when wrong and where.