Question

Consider the following scenario:
http://www.yourdomain.com/Default.aspx?p=2

Now we ofcourse want to check if the querystring parameter p doesnt contain errors.
I now have this setup:

1) Check if p exists

2) Filter out html from p’s value

3) htmlencode p’s value

4) check if p is integer

5) check if p’s integer exists in db

This is how I usual do it, though step 5 is ofcourse a performance hit.

Kind regards,
Mark

Answer 1

Quite simple. For most data types (integers, decimals, doubles, dates and booleans) there is a very strict format. If the value does not parse under the strict format, it’s an error.

Strings sometimes have a strict format, like an email address or a phone number. Those can be validated with a simple regexp. If it conforms, use it, otherwise it’s an error.

Most of the time however strings will simply need to be persisted to the DB and later displayed again. In that case no processing is needed, aside from escaping when inserting into DB (unnecessary as well if you used parametrized queries)k, and HTML-encoding when rendering to the display.

This way any and all data is validated, and there is no risk of any injections whatsoever.

The rare exception of a loose format for a string is, well… rare. I can’t think of any right now. For that you can afford some more extensive parsing and processing.

Added: Oh, yes, checking whether IDs (or other values) are valid in respect to a DB. You’re doing it right, but think if you always need it. Quite often you can put the check into some other query that you have to do anyway. Like when you select data based on the ID, you don’t need to explicitly check that it exists – just be ready that your query can return no data.

Sometimes you don’t need to use the value at all, then you can simply ignore it.

But, of course, there are other times, like when inserting/updating data, that you indeed need to explicitly check whether the data exists and is valid in the current context.