WebApp Sec mailing list archives

Input validation


From: "Kooper, Larry" <Larry.Kooper () metmuseum org>
Date: Thu, 19 Jun 2003 13:38:40 -0400

I am a newbie to this list - apologies if this question is often asked.  (I
don't know if the list has a FAQ).  

When securing a web site against attacks such as SQL injection and XSS, what
approach do you recommend following to validate user input?  

1) Attempt to massage data so that it becomes valid
2) Reject input that is known to be bad
3) Accept only input that is known to be good

(The three categories are taken from a paper here-
http://www.nextgenss.com/papers/advanced_sql_injection.pdf ,p22)

The problem with solutions 1 and 2 is that you may miss some forms of bad
input.  Another subtle problem with solution 1 and 2 is that sometimes bad
input can be embedded in good input.  For example, if someone searches for
"director's selections" the string "select" would be rejected (as a SQL
command), resulting in "director's ions." 

Solution 3 seems like the most secure but also the most expensive to
implement.  And the problem seems more difficult when validating free-format
fields such as a name or an address.  One could reject non-alphanumeric
characters, but then things like # (for apartment number) or - (hyphen)
would be kicked out. Any thoughts?

Thanks,

Larry Kooper
Manager, Internet Technologies 
The Metropolitan Museum of Art 


Current thread: