[Zope] assignment to form records

[Dylan Reinhardt]

At 02:57 AM 3/9/2003, Oliver Bleutgen wrote:
>Could you elaborate this a little bit?
>I can't see any problem with using field names which hold data structure 
>information.

The names themselves aren't a problem... it's the behavior they enable.

If you use them in the way they're intended, you are implicitly trusting 
your clients not to cause any mischief.  That might be fine for an intranet 
message board, but I sure wouldn't recommend it for e-commerce.

>What you shouldn't do is _rely_ on the types (name:int etc.) for anything 
>important,

That's my point.

>but using the names to get the data as a record or list etc. doesn't seem 
>dangerous for me.

Except that you're passing the client some degree of control over how your 
data is managed.

It sounds like we're agreed that using <input type="text" 
name="my_num:int"> doesn't mean you can simply assume that whatever 
conversion the zserver performs must be correct.  You should still verify 
that the value of my_num is an integer... and should do so based on 
*expecting* an integer, not on what the field name contains.

But let's take that one step further to this example: <input type="text" 
name="person.f_name:string:required">

Two things are wrong here... first is, if you use options like required, 
default or ignore_empty you're giving the client even more control over how 
your data validates.  How that can be a good idea is beyond me.

The second -- somewhat more subtle -- issue is using record notation at 
all.  What are the odds that your record naming scheme maps closely to how 
this information is structured in your RDBMS?  How much more vulnerable do 
you make yourself to SQL-based attacks if you used this naming technique on 
anything that passes off data to a SQL query?  Are you looping over 
*everything* you find in given record, or only looking for the attributes 
you're expecting?  I realize that quoting your input with sqlvar takes care 
of the worst insertion attacks, but that's something I'd consider a last 
line of defense rather than a primary means of providing security.

It's easier not to validate, but that's not a habit I'd recommend for 
serious projects.  I'm only raising issues with field naming to the degree 
that it's most likely to be used to reduce validation work.

Dylan