Re: F5 problem
- Couple of comments:
cookies != sessions. There are URL based sessions that work great when
cookies are turned off in the browser.
The way you describe approaching your new application sounds good. I find
that I like to store simple data like flags and checkpoints in a generic
session store during the intermediate steps of the application.
For storing larger stuff, especially stuff that I want to remain even if
the user's session times out or is lost (say a computer reboot or
browser / OS lockup) saving out to a DB table (as you describe) is
preferable (for me at least). That way the user can start a new session,
but continue the state where she left off.
On Wed, 16 Apr 2003, Andrew Hurst wrote:
> Well, implicit (though I should have mentioned it) in the method I described
> earlier was the assumption that the formkey would be stored in the database
> somewhere, and on form submit the formkey they provided would need to exist
> in the database.
> This would be most handy for simple things like anonymous comment submitting
> to stories on sites like slashdot or kuro5hin.org. You don't want to assign
> the user a session, because they might be ignoring cookies. Also they might
> just want to submit one comment. So on the comment submit page creation you
> create a formkey and store it. Then when they submit the comment, it sees that
> the formkey exists and deletes it from the db. If they reload and submit the
> form again it should take them to the comment preview page because the formkey
> that their form had wouldn't exist in the database anymore. Useful to prevent
> double comment posting, and not much more.
> Granted, for multi-step applications, there should be a stronger method. The
> way I'm thinking of handling this in an application we're going to write here
> soon, is as follows:
> Every time the user completes a step, then mark it as completed in some table.
> When they get to step 4 (from the example below), don't let them submit unless
> all of the previous steps have been completed. If they want to hit back and
> change some options in a previous step, fine. They will be able to navigate
> back to the final step and submit the form as before.
> This will work for our application because each step is mostly independent.
> If the steps were more intertwined, I would make the user not able to do step
> N until step N-1 was complete, and store the last step completed in the
> If they try to craft the url's by hand to skip steps, the application will
> that they're going to a step that they shouldn't have access to yet, and will
> just show them the previous step.
> Of course the users' progress through the steps will be tracked via a session,
> not just formkeys.
> At 01:14 PM 4/16/2003 -0400, C. Jon Larsen wrote:
> >On Wed, 16 Apr 2003 wsheldah@... wrote:
> > > If you have hidden form fields that need to stay static, what about storing
> > > the md5sum or other hash of the field values you want to remain the same,
> > > with the session data on the server? when the form is submitted, you
> > > compare the hash of the hidden field values with the hash you stored when
> > > you sent the form to the browser. An attacker would have to come up with
> > > another combination of values that produce the same hash. This can even
> > > help prevent them from spoofing their session id or formkey value.
> >Sure, thats another idea/approach for doing the same thing - trusting the
> >server side state not the client. Assuming you already have some kind of
> >server session it seems to me to be easier and faster to just store the
> >things in a server side session (especially one that emulates a hash
> >or is an object where its easy to fetch and set attributes) that you don't
> >want to be changed, rather than packing them up as hidden fields and
> >running checksums across them on every round trip.
> >But either way is valid as long as you trust the server side state, for
> >simple applications. But ....
> >You also need to think about multi-step transactions and the value of
> >sessions. The browser's back button can be thought of as a client side
> >rewind button. The user can rewind the steps in a multi-step process
> >(think series of forms) by pressing back, but the server is in the dark.
> >If you are not tracking the state carefully in the session, you may find
> >yourself getting inconsistent results in your application. Suppose there
> >are 5 steps in your application seqeunce, and step 4 involves saving or
> >deleting or changing some kind of data in a database. Suppose a user
> >clicks through to step 4, and then back buttons and does something
> >different in step 2. Is your application smart enough to detect this and
> >act/react accordingly to protect the integrity of the data and the session
> >? Or can it at least print an intelligent error messaage, and guide the
> >user back to step 4 automatically or let them formally cancel out the
> >operation rather than just back buttoning ?
> >For most applications this is probably not an issue, but for complex
> >applications I think a session API and a programming style that makes use
> >of that API is important if you want secure apps.
> >What is everyone else doing to handle these types of issues ?
> > >
> > > Wes Sheldahl
> > >
> > >
> > >
> > > "C. Jon Larsen" <jlarsen@...> on 04/16/2003 12:33:23 PM
> > >
> > > To: Andrew Hurst <hurst9@...>
> > > cc: JMcNamaraIRL@..., <modperl@...>
> > > Subject: Re: F5 problem
> > >
> > >
> > >
> > > > I don't think its beneficial to try to catch this client side. What
> > > would
> > > > probably be better is to catch it on the server side, using something
> > > like
> > > > formkeys. i.e. generate a unique key for each webpage (like LA983401KAB
> > > or
> > > > something) and put it in the forms as a hidden variable. For the case
> > > below,
> > > > tack it onto the url with something like &fkey=LA983401KAB. Then when
> > > your
> > > > application is processing the request, it can see that that formkey was
> > > already
> > > > submitted, and handle it appropriately. Either ignore the second
> > > request, or
> > > > display an error, etc.
> > >
> > > Or better yet, use a server side session for this. Roll your own, or use
> > > Apache::Session, or Cache::Cache might be useful. Hidden fields in forms
> > > can be spoofed or changed, so a secure solution needs to rely on the
> > > server side state, not the client.
> > >
> > >
> > > --
> > > + Jon Larsen: Chief Technology Officer, Richweb, Inc.
> > > + Richweb.com: Providing Internet-Based Business Solutions since 1995
> > > + GnuPG Public Key: http://richweb.com/jlarsen.gpg
> > > + Business: (804) 359.2220 x 101; Mobile: (804) 307.6939
> > >
> > >
> > >
> > >
> >+ Jon Larsen: Chief Technology Officer, Richweb, Inc.
> >+ Richweb.com: Providing Internet-Based Business Solutions since 1995
> >+ GnuPG Public Key: http://richweb.com/jlarsen.gpg
> >+ Business: (804) 359.2220 x 101; Mobile: (804) 307.6939
+ Jon Larsen: Chief Technology Officer, Richweb, Inc.
+ Richweb.com: Providing Internet-Based Business Solutions since 1995
+ GnuPG Public Key: http://richweb.com/jlarsen.gpg
+ Business: (804) 359.2220 x 101; Mobile: (804) 307.6939