[thelist] Form Security

[Bill Moseley]

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




>  Sure, every extra bit of security is probably good, but my argument is
>> that
>> filtering to remove things like "DROP TABLE", rm -rf, "<strong>", etc. is
>> misguided and, in my experience, is an indicator that the programmer
>> doesn't
>> understand the real security issues.
>>
>
> So what are some options that you do to protect against injection that
> don't involve reserved word filtering or neutralizing?


Oh. See above.



>
> 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.


-- 
Bill Moseley
moseley at hank.org