[Zope] assignment to form records
Sun, 09 Mar 2003 09:37:52 -0800
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
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
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"
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.