[thelist] Form Security
Frank Marion
lists at frankmarion.com
Mon Jul 19 17:16:36 CDT 2010
On 2010-07-19, at 4:45 PM, Bill Moseley wrote:
> On Mon, Jul 19, 2010 at 1:12 PM, Frank Marion
> <lists at frankmarion.com> wrote:
>
>> On 2010-07-19, at 2:32 PM, Bill Moseley wrote:
>>
>>>
>>> But, my comment is if you are stripping things like "DROP TABLE"
>>> or "rm
>>> -rf"
>>> from user input then you have bigger problems. If you are worried
>>> about
>>> "rm
>>> -rf" in user data that means you are not 100% sure that user-
>>> supplied data
>>> is NEVER used in a way that might be dangerous. That is, you are
>>> allowing
>>> user data to pass though the shell or have a SQL injection problem.
>>>
>>
>> Can we ever be sure of it? My default position is that the
>> microsecond my
>> form is out there, evil CIA hackers are immediately going to pounce
>> on it
>> just to ruin my day.
>
>
> Sure of it? That's the point of using bind parameters provided by
> database
> interfaces. They separate the data from the statement so that SQL
> injection
> is avoided. Kind of a problem if you can't use works like "drop
> update
> alter insert" in normal text fields, no?
>
> http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements
Right, OK. This is what I meant by creating a "non-evaluating string"
in a previous post. In coldfusion talk, you'd be recommending the use
of <cfqueryparam ...>. I agree with you. I will sometimes, for plain
old unimportant contact or comment forms use just that for an optional
field. I don't always know the fancy names :)
>> So what are some options that you do to protect against injection
>> that
>> don't involve reserved word filtering or neutralizing?
>
>
> Oh. See above.
Gotcha.
>> I had never thought of explicitly converting to to UTF-8. Good idea.
>
>
> HTTP is octets, not characters. If I send you a set of octets how
> can you
> display it as text (or filter or compare it for that mater) w/o
> knowing the
> encoding? How can you insert it into a database text column without
> having
> it encoded into what the database expects? You really should decode
> the
> request data. And encode on output.
Excellent point, and I think, my next little area of study.
--
Frank Marion
lists [_at_] frankmarion.com
More information about the thelist
mailing list