On 01/08/2013 08:39 AM, Karl Lehenbauer wrote:
This talk of new capabilities for a new release of Rivet has had me
revisiting something I've been thinking about for quite a while...
It's really easy for developers to use forms in a way that they
shouldn't, putting stuff in hidden fields, etc, that could easily be
monkeyed with by an attacker. That data needs to be kept server side and
accessed with an opaque, unguessable session ID cookie or equivalent.
Yes, yes… clear, but not simple, and that friction helps to cause the
observed problem.
I wasn't in the team when Session package was designed but I understand
it was shaped with an eye on this issue. Methods 'fetch' and 'store'
take 2 keys and it's quite natural to have the form name as one of the
keys for storing/retrieving data. Maybe the interface could be more
extended to offer some 'form' oriented method.
It's also super common for developers to accept input from forms with
insufficient checks on the validity of the input data, the source of SQL
injection attacks and so forth.
I'm thinking of what you might call a response broker. (This isn't an
original idea -- I've read about stuff like this.)
Rather than doing a load_response, the page handling the response would
explicitly name the fields you expect to get from the form, you invoke a
proc specifying the fields you expect to find, their data types,
optional code to validate them, and an array to stuff the validated
fields into.
I ended up having something like this as a utility for consistently
squeezing data from forms into array to be stored in a table. It's
something much less ambitious
set wantVarList {{username string} {id integer} {uid check_routine
validate_uid} {password check_routine validate_password} {hash base64}
{email email}}
set status [response_broker $wantVarList response]
Since every page using the response broker would need to check for
response broker parse failures it would probably be nice to be able to
specify a general handler routine that would run and then abort the
page, removing the need to check the return.
Now if I run…
response_broker $wantVarList response
…if the page continues then the response array would contain validated
fields found in the form for the variables named in wantVarList and no
others. You might want the presence of unexpected fields to also blow
out, but that would be likely to bite you pretty often when the reasons
are harmless. Maybe log them and include a {field ignore} option that
will inhibit logging for expected-but-ignored fields.
Wouldn't a generalized page abort mechanism be a workable basis for
something like this?
We've done a form package at FlightAware that has a specific look and
feel that allows you to specify both Tcl and Javascript validation code.
Of course you still need the Tcl code on the server but it's nice in the
modern era to also provide Javascript validation on the browser. We
could probably open source if its appearance was genericized or
something, but I mention it mainly to point out the usefulness of such
an approach both for the developer and the users and a likely need to
push Rivet into providing more stuff to support developers making modern
websites.
I reiterate Damon's question: is there something that could be shared in
your tools on which we may start some analysis and development?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
