[thelist] Form Security

[Frank Marion]

On 2010-07-19, at 9:37 AM, Ken Schaefer wrote:
>>
>> 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)

Scenarios (Some more hypothetical than others, for discussion's sake):

  * I'm sick of the spam, can you block X country
  * A certain part of the network is known to be compromised
  * A specific IP or range is known to be troublesome (hacker, ex- 
employee, annoying kid)
  * Did the query string address the action page and ONLY the action  
page?
  * Did the query string get pushed by an page that's not on your site?

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

What is OP?

Think automated spambots and kiddy scripts.


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

For the exclusive purpose of starting to funnel your data along a  
corridor that YOU will accept. The average Joe can type in  "   x' AND  
userid IS NULL; --   " into a browser's url bar (GET scope). It's a  
touch harder for most to send it as a POST. Of course it can be done,  
but the point is to reduce the paths of data entry where possible. 10  
imperfect micromeasures might be enough to discourage an attack. Not  
all attackers are hard-core dedicated and highly educated. My  
philosophy is that if it can help, and it doesn't hurt, and it doesn't  
take up too much time, why not? Cost benefit ratio.

Can you think of to start narrowing the source of data input? Default- 
Deny as a policy is, IMO, is far, far more powerful than Default- 
Accept Then Deal With It. Each option has it's benefits and costs.  
Consider that Default-Accept is built into TCP, SMTP, etc into the  
structure of the internet. The builders were trusting acamedicians  
where once all SMPT servers were open. Today, spam is, something like  
60-70% of all internet mail traffic.

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

See above.


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

Consider that a bot looks for form pages, scans for field inputs,  
stores them, then simply goes straight to an action page and automates  
a query string that goes exclusively to it, rather than at the very  
least populate the form and send it. I've run into this a couple times  
where send_comment.cfm had no referrer, but the field values were  
looped over with random strings and the comment field had spam urls.

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



How can they? It's just a string, and a perfectly legitimate one.  
Further, I don't feel comfortable in delegating the security of my  
apps to a third party company whose job it is to produce a great  
database rather than to secure my app. It's a matter of the scope of  
responsibility. I consider it to be my job, not theirs. A very handy  
bit of Coldfusion code I use is the open source Portcullis, found on  
RIA forge. http://www.riaforge.org/

Security [*]---------------------------[*] Convenience

Development cost, energy and effort, I would say could legitimately  
included under "convenience". We all have to choose as to where we  
want to sit on this scale.

--
Frank Marion
lists [_at_] frankmarion.com