[thelist] Form Security

[Frank Marion]

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