WebApp Sec mailing list archives
Re: Input validation
From: Tim <tim-security () sentinelchicken org>
Date: Thu, 19 Jun 2003 21:40:07 -0700
Hello, When I write apps I find that I do sanity checking for the application-specific formats required, and use proper quoting for security issues. When a user gives you a date on a web page, make sure you receive something that looks like a date. It only makes sense in the context of the application. So in this way, you are doing #3. However, from the application's perspective, certain characters are often perfectly valid, and the end user has a right to be able to give them to you. If a user really wants to put a single quote in that textarea, you should let him. This is when quoting comes in. And this is where all of your security lies. Whenever you send any piece of data off to another medium, quote it. Whenever a variable that any outside source controls leaves your web app, escape. When you send user input to your db, use the quoting function that your db provides. When you re-display it on the web page, turn the special characters into entities. When you write a filename to the filesystem, escape the dangerous characters. I know this might seem somewhat backward from what you normally hear about "sanitizing your input". But typically in web apps, we aren't concerned with overflows, we are concerned with funky syntax. A string is a string, and it won't break anything until you try to use it in a way that it wasn't meant to be used. Anywhere you send this data that is outside of your web app will probably have its own syntax for things. Syntaxes come with special characters. There are typically tools available to quote/escape these characters in each syntax. If they aren't escaped, your program is buggy. If it is buggy, it might be (or probably is) insecure. good luck, tim On Thu, Jun 19, 2003 at 01:38:40PM -0400, Kooper, Larry wrote:
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:
- Input validation Kooper, Larry (Jun 19)
- Re: Input validation Jeremiah Grossman (Jun 19)
- Re: Input validation Tim (Jun 20)
- Re: Input validation Alla Bezroutchko (Jun 20)
- Re: Input validation Peter Conrad (Jun 23)
- <Possible follow-ups>
- RE: Input validation Dawes, Rogan (ZA - Johannesburg) (Jun 20)