[thelist] Form Security

[Frank Marion]

On 2010-07-19, at 4:23 PM, Bill Moseley wrote:
> On Mon, Jul 19, 2010 at 12:02 PM, Frank Marion  
> <lists at frankmarion.com>wrote:
>>
>>> 1) Security and convenience are the opposite ends of a scale.  
>>> You'll have
>> to determine where between the two you want the marker to sit.
>
> I'm not sure I follow that.  Actually, I think when using good coding
> practices (i.e. a good secure framework and centralized validation)
> convenience and security are on the same end of the scale.   But, I  
> suppose
> you mean something else.

Security of any kind, whether digital, household or national is  
specifically the act of making it more difficult for an unwanted  
individual to have access to a determined valuable item. But, this  
difficulty applies to you, a standard human as well. A wall around  
your home makes it more difficult for someone to walk up to your home.  
It is less convenient for you, because you have to scale that wall  
every day. But then you put in a doorway. More convenient, but less  
secure. Then you add a lock, more secure, but less convenient, as you  
need make, have and manage keys, etc...

While having a user name and password is economical, the principle is  
the same: the inconvenience of an extra step for the user, time and  
resources for technologies and coding and so on compared to the  
possibility of having the public, good or ill run rampant though your  
web app admin side and database values, good security is certainly  
very ecnomical, especially if well planned. It does, nonetheless  
require thought, time, effort, resource and extra steps for many  
people involved. Safer, but more work.

>> 2) You can have it fast, cheap, or well done. Pick two.
>
> Seems like the choices are 1) fast and cheap or 2) well done.    I  
> have not
> seen that throwing money at a problem always makes it well done (or  
> fast).

Fast. Cheap. Not well done.
Fast. Not cheap. Well done.
Not fast. Cheap. Well done.

That's a balance to strike with every client's budget, desire for  
quality and risk tolerance.

>
>> (1) I think a lot of forms development folks get overly aggressive  
>> and
>>> hung up on input completeness and validation.  While that may be  
>>> mandated by
>>> management, it [IMVHO] can come across as bloody annoying on the  
>>> user end of
>>> the stick.  There actually IS a difference between a "required"  
>>> field ...
>>> and a field people simply "want" populated.  Please don't confuse  
>>> the two.
>>>
>>
>> Again, total agreement. But even a field such as an optional feedback
>> comments field on, say, an order requires security checking. You do  
>> want to
>> strip out or neutralize anything that is potentially harmful such as
>> sql-injection attacks. The very simplest way to do that is to force  
>> it to a
>> non-evaluate string. Doesn't need to be required, but it should  
>> still be
>> processed for security, and frankly, it's easy. If it's not  
>> required, we
>> still need to check it's type. 1+1 and "1+1" have two different  
>> effects when
>> passed to an SQL statement.
>
>
> What's an "non-evaluate string"?


What I mean by that is a string that the database won't interpret. The  
database will interpret 1+1 as the addition of two integers, but not  
"1+1"--a plain old string. I just wanted to make the point that even  
if your  field isn't required to be filled out or formatted by the  
user in a given manner, that the simplest precaution is making sure  
that the contents can't be misconstrued by the code or database in  
such a way as to do something other than what the coder intended--to  
stuff something harmless into the database.


--
Frank Marion
lists [_at_] frankmarion.com