Re: SQL Injection

["saphyr" <saphyr () infomaniak ch>]

> Here's a little list of regex's that I put together for an article about how
> to build an HTTP Request Validation Engine (see
> http://www.aspectsecurity.com/stinger). If anyone knows of a more complete
> list with some better documentation, I think it could be pretty helpful for
> folks.

Interresting one. I once found that page:
http://www.sklar.com/page/article/owasp-top-ten
which is actually giving advice about a validation engine un php. Anyone heard
of the same in asp ?

> Architecturally, I think there's a strong case for a centralized validation
> engine, as opposed to putting a regex in front of every place you use
> something from the HTTP request.
Of course! The main advantage about using a centralized request validator
is that you may have a continously improving regular expressions base and
maintain them easily without refactoring. My code requires REs only by
their business name and they're all maintained in the validator:

 var = Validator.GetQuery("var", Validator.PASSWORD);
var = Validator.GetPost("var", Validator.EMAIL);
var = Validator.GetSession("var", Validator.HTMLTEXT);
...


> Here's a few quick questions to see if you're really validating well:
>  - Is your validation scheme mandatory (developer doesn't have to remember
> to do it)
Being the only developper in my company, I mainly use self-discipline.
I made myself a checklist of 'find in files' patterns to run with Ultra Edit
and I know exactly what I never must find in the code = )

>  - Do you canonicalize before validating?
Not yet for my part. But I am aware I need to take time on this ASAP.

>  - Are you validating URL params, cookies, and other headers -- or just
> forms?
Everything.

>  - Do you catch extra, missing, and duplicate parameters, headers, etc...?
No. But I check for 'big unusual' things. Like if the user-agent changes during
the session or the ip class changes, I consider it invalidated and force its
destruction.

>  - If you detect a problem, what are your options (ignore, sanitize,
> continue, fatal, log, notify)?
I use to sanitize and log everything (get a good logger, it's worth it!). Using
an error/"fatalisation" system is (from my point of view) already giving to much
information to the potential attacker.

In some cases, I ask for 'confirmation' about entered data. If somone enters
" ' or true or ' " in his new account creation, the result would be:
  "is this login correct ? [ortrueor] "

Psychology helps for that stuff: don't mention it and dont give the attention
the attacker is requesting ; )


>  - Can you detect an attack based on repeated failed input validation?
yes. just get some patterns like quotes where they should never be. activate
a triggered session value and when some threshold is reached, kill it.

>  - Is what you log different than what you show the user?
of course. I show the user:
"there was an error during your request. This must be the developper's entire
fault and he has been automatically warned about that problem. please click
here to return to a stable area."

and in the logs that would usually be:

date{2004-06-10-07-36} sid{2348729384} ip{192.168.100.1} level{wrn}
account {87}project{mywebapp} module{login} file {login.aspx.cs}
call{AuthenticateUser} alert{quotes detected - 1st try - 2 tries left}
cause{login=[' or true or ']}

That makes a little difference, don't you think ? ; )


> Wait -- here are the best ones:
>  - Do your requirements specify all the stuff above?
No. Requirements specify such things:

4. Security
sp4.5:
The application should implement self-defensive mechanisms against
invalid requests and queries
sp4.6:
The application should not give detailed error messages to the user, however,
detailed messages should be delivered to the administration maintainer

>  - Do your requirements or detailed design docs specify all the validation
> rules?
They should, theoretically. = )


> Input validation shouldn't just be left to 'best practice' or whatever
> individual developers want to do.  It takes some real design thinking to get
> it right for an enterprise application.

I not really agree with this. For my own experience, input validation really
is a 'best practice' stuff. It gets improved timer after time as are my regular
expressions...  It there was some 'empiric science' document about it, that
would maybe be worth considering it as a completely design-step oriented
feature.

> --Jeff
Antoine

--
Securité Web (swiss blog about web security)
http://www.nxtg.net/securiteweb