From: Tim (tim-securitysentinelchicken.org)
Date: Thu Jun 19 2003 - 23:40:07 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]