Loading ...
Sorry, an error occurred while loading the content.

Re: F5 problem

Expand Messages
  • C. Jon Larsen
    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
    Message 1 of 8 , Apr 16, 2003
    • 0 Attachment
      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.

      -jon

      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
      > database.
      > If they try to craft the url's by hand to skip steps, the application will
      > notice
      > 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.
      >
      > -Andrew
      >
      > 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 ?
      > >
      > >-jon
      > >
      > > >
      > > > 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
    Your message has been successfully submitted and would be delivered to recipients shortly.