You've addressed the issue of someone submitting a form with altered fields to attack the server, and pointed out some more advantages, but I don't think you've addressed the issue of protecting the "hidden" cleartext data from others on the client side. I guess that's a matter of how paranoid you think you need to be, and how confidential is the data you're storing. Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once.
Looks like it might worth be taking another look at this approach next time I start a new project. Wes [EMAIL PROTECTED] on 02/20/2002 11:48:28 AM Please respond to [EMAIL PROTECTED] To: mod_perl Mailing List <[EMAIL PROTECTED]> cc: Subject: Re: [OT-ish] Session refresh philosophy > The usual objection I've heard to using form fields is the security > risk of people changing hidden fields in ways unforseen before submitting > the form back, or of other people finding confidential data hidden in form > fields if the user walks away and leaves their browser open, or the web > page info gets hijacked somehow. Does your module address this, or is this > yet another tradeoff between security and functionality/convenience? No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. Both page types may have form input validation code on the server side, but in the first case this is just convenience for the user (warn early and don't say "woops" after 9 pages and 10 minutes of typing). The latter MUST have validation for security to hold (even if this means validating twice). This way, changing hidden fields gains an attacker nothing, since he will be blocked at the final submit anyway. Doing things this way also has other advantages e.g. interfacing: one can write automatisms with "wget" or LWP::UserAgent to trigger actions in the database without any further programming needed on the server side. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
