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