[thelist] Form Security

[Ken Schaefer]

-----Original Message-----
From: thelist-bounces at lists.evolt.org [mailto:thelist-bounces at lists.evolt.org] On Behalf Of Frank Marion
Sent: Monday, 19 July 2010 8:47 AM
To: thelist at lists.evolt.org
Subject: Re: [thelist] Form Security

> First, where did it come from? Geographically? From where on the network? From which page? Did the user even tap the data entry form?

What is the significance of this? You say this is security related, but how does it impact security? (I'm not disagreeing with you, but you are not clear on what OP should do with this information)

> Second: How fast is it coming?

Again, what is the relevance here? What does OP do about this? How does OP put this into a decision tree?

> Third: What kind is it?

Ditto.

> Some "meta strategies".
>
>  1) Restrict how data is able to be passed to your application, thence to the database. As one example, consider rejecting all data that is not in the POST scope, rather than the GET scope.

Why?

>  2) When possible, use pre-set data rather that text input fields.  
>  Dates, counties, regions, pre-determined answers in a select or radio 
> button will be inherently more secure than a black field. And they're usually easier to use, too.

Completely useless as a security measure, as anyone can sent whatever arbitrary data they want to your receiving page, without worrying about what actual widgets you put on the screen.

<snip>

> 4) Before doing an insert or update query, consider that it might be a good idea to ensure that a session validation exists. 
> No going straight to the form action page. Perhaps insist that they have tapped at least the home page before they can 
> access the form page. This is at your discretion.

What type of threat does this mitigate?

> The Actual Form processing

Whilst I agree with most of the below, looking for strings like "SELECT", "DROP" etc. is a losing proposition. Rely on your database vendor (via their provider/driver) to take care of that for you.

Cheers
Ken