[thelist] Form Security

[Frank Marion]

On 2010-07-19, at 9:16 AM, Luther, Ron wrote:
> I really enjoyed your post and it's thoroughness.  There were a lot  
> of good points in there and I found it fun and helpful.  But based  
> on a lot of recent experience wrestling with forms that I did not  
> particularly enjoy ... I might have a quibble or two.  ;-)  I  
> certainly agree that, by all means, we should protect the integrity  
> of the database and backend system.  But I think people go too far  
> when they try to do much more than that.

I totally agree with you. The trick is to use it when it's  
appropriate. I often tell my clients these two mantras:

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.

2) You can have it fast, cheap, or well done. Pick two.


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


> There are, for example, very very few situations where you actually  
> need my middle name, so please don't trigger an error when I leave  
> it blank because you are only going to tick me off and force me to  
> fill your 'required' field with my expletive du jure.

Yes. That's where common sense comes in. Remember that that with no  
clients, there's no reason to have a database to protect. An entry  
form is a means of communication with the client. Don't annoy them  
anymore than you have to :)

>
> (2) Try to avoid excessive nosiness.  Okay.  I will grant you that  
> there may be some 'edge' cases for tobacco, alcohol or senior sites  
> where you may need to know whether my age is over 18 or 21 or 55.   
> But by and large you do not ever need to know my exact age. So  
> please don't trigger an error if I react to your mandatory birthday  
> field by entering a year of 1547.  (Hey!  Everyone likes to look  
> younger. Right?)

I totally agree. I was thinking in cases such porn sites, so-called  
"adult" you-tube videos, banking sites or real-time credit card  
validation. In certain instances, they are a legitimate request.  
Legally speaking, it might be important to have plausible deniability,  
and thus checking to see that you're not over 125 years old (a  
reasonable time frame, I'd say) is serving the client who pays you,  
if, at the expense of the client who pays your client.


> There are, of course, worse things some folks do, like requiring  
> fields like SSN or "mother's maiden name" when they don't have a  
> legitimate need for them.  Fortunately, larger companies generally  
> have an 'executive complaint center' where you can point things like  
> that out to them ... and their legal staff.  Questioning the  
> developer's competence and parentage is, of course, optional.  [1]

I totally agree again.

> (3) i18n.  Some of our Canadien and UK members have, in the past  
> anyway, railed on about "validation" on telephone number and zip  
> code fields that actually prevent them from entering correct  
> information.  Ever wonder why folks in Toronto claim a '90210' zip  
> code?  This is why.

Heh! I do the exact same thing. If it weren't for that TV show, I'd  
not know what to enter into the "zip" field. (Canadians don't have zip  
codes, we have postal codes.) But then again, this is one of those  
instances where you look at it and ask how important it is. I have  
case where a store charges different delivery rates based on the  
postal code. it is required, and I check it hard for existence, range,  
and form, but that is as much as is needed to serve the purpose.

> People travel.  Get over it.  If my cell phone is out of London and  
> I want you to ship to my NYC office ... do you want to make the sale  
> - or do you want to argue with me that I'm making a mistake and not  
> filling out your form correctly because the area code and zip code  
> fields don't match the same geography?

Again, I agree. It's about using common sense. The point that I was  
making in this instance of validating the form of your input is that  
the format 011 (519) 222-4356 will fail an sql injection.

Your overall point seems to be: be contextually appropriate. I  
couldn't agree more.


--
Frank Marion
lists [_at_] frankmarion.com