Re: Browser refresh sends username/password after log out -- URGENT

[Chris Scott <cgscott () ll mit edu>]

Possibly due to the use of frames. The result of the POST for the login 
form could be a frameset, and pages 2 thru 7 are displayed in a frame. 
So the reload tries to refresh the page containing the frameset, which 
resulted from the login POST.

Chris


Tim Aranki wrote:

> The fact that a refresh on the 7th page is sending the form vars from
> the login sounds to me like something else is happening:
>
> 1.  Refresh on 7th page
> 2.  App determins that user is not logged in and redirects to login page
> 3.  Browser tries to be smart, and on the redirect sends its cached form
> vars for the login page
>
> Do you see any redirect headers in the net traffic?  Unless you are
> writing the login form fields to every page, I do not see how/why the
> browser would resend those specific field vars...why would it not send
> all field vars from the last 6 pages then? My guess is a redirect, and a
> browser that is trying to be too smart.
>
> Hth,
> -tim
>
> -----Original Message-----
> From: Krk [mailto:krk41 () yahoo com] 
> Sent: Tuesday, August 05, 2003 11:59 PM
> To: Ingo Struck
> Cc: webappsec () securityfocus com
> Subject: RE: Browser refresh sends username/password after log out --
> URGENT
>
>
> Hi Ingo ...
>  thanks for the reply. 
>
> More clearly the issue here is also that:
>
> 1.) We login using username/password
> 2.) Suppose we have browsed 7 pages after log in
> and then we say logout and we get logout message so
> after logging in this is the 8th page.
>
> 3.) Now after this we just do 1 back, so
> effectively we should bein the 7th page that we had
> browsed.
>
> 4.) Now we do a refresh( this is again on the 7th
> page and not on the login page) and the same
> request that we had sent in the login form is being
> resent. This is what i am wondering that how come
> the refresh sends the form fields that were entered
> in the Login Form and not the "Logout" request
> which
> we had sent from the 7th page. 
> 5)hope I am making the question clear.
>
> thnaks
>
> Krk
> --- Ingo Struck <ingo () ingostruck de> wrote:
>  
>
> > Hi...
> >
> > See my comments inline.
> >
> > > 1) - 5)
> > I guess anybody in this lists knows that... ;o)
> >
> > > 6) Can anyone explain this behaviour and how
> > to
> > > avoid the resubmission of the credentials.
> > What you see here is a "feature" of most today's
> > browsers.
> > The reason for that is the idea of a history: you
> > should be
> > able to move back and forth in the browsers
> > history and see
> > exactly the "content" that you saw before.
> > For GET reqs this is not a problem, because all
> > necessary
> > parameters are encoded in the URL. For POST,
> > however, it
> > is necessary to memorize the posted parameters to
> > be able
> > to reconstruct the result of a former request. So
> > it is indeed
> > an exact copy of the former request that is
> > issued if you click
> > ok in the confirmation dialog. This dialog exists
> > exactly because
> > it may be unwanted to "replay" that former
> > request.
> >
> >
> > > 7) How many requests does the browser window
> > store
> > > in its temporary cache.
> > I haven't heard of any browser with
> > full-automatic persistent
> > storage of submitted form data.
> > If you close your browser, all POSTed parameters
> > are lost.
> > However, most modern browsers, provide a facility
> > to store
> > form data permanently. Some of them seem to set
> > that as
> > a default, but all of them that I know ask before
> > they store form
> > data and allow to switch off that thing
> > completely.
> >
> > Your problem is only an issue for "shared"
> > browsers, i.e. machines
> > where the browser is shared by multiple users
> > (e.g. icafes, highschool,
> > library etc.)
> >
> >
> > The solution for your problem is two-way:
> > 1) inform your users that it is a *VERY HIGH
> > RISK* to use public
> > browsers for banking anyway and advise them *NOT
> > TO DO THAT*
> > 2) use a technical work around for the problem.
> >
> >
> > There are two main approaches, where the first is
> > more common and
> > the second is more secure.
> >
> > Work-Around I) (not recommended, using pop-up
> > windows to break
> >                the browser's history)
> >
> > You may work around the problem if you place the
> > login dialog
> > in a pop-up window, since that breaks the
> > browser's history.
> > I know many libraries doing that for their
> > online-accounts.
> > The mechanism is like that:
> >
> > a) for the login, pop up a new browser window
> > b) after login finished close that new window
> >
> > To be perfectly sure that nothing went wrong, you
> > should break the
> > browser's history during logout too:
> >
> > c) for logoff, pop up a new browser window
> > d) close *all* other open browser window
> >
> > An alternative is to run the complete application
> > within a new pop-up
> > window, that is then closed upon logoff. That
> > breaks browser's history
> > too effectively.
> >
> > Of course, popping up a window is an absolute
> > NO-GOs regarding
> > usability, but it may be necessary as a security
> > work-around.
> >
> > The main drawback of this solution is, that you
> > need to enable scripting,
> > which by itself is a security problem.
> >
> > Work-Around II) (recommended, works with
> > transaction tokens)
> >
> > Add a per-request token for each submitted form.
> > The mechanism is like that:
> >
> > a) for each new session generate a random number
> > in the lower half
> > of the number range (e.g. 0 up to 1/2 MAX_INT),
> > store that number
> > in the session, it is your CURRENT TRANSACTION
> > c) for each response that leads to a form using
> > POST,
> >  encrypt the CURRENT TRANSACTION and send it as
> > a hidden field within
> >  the form that needs input, this is your
> > TRANSACTION TOKEN
> > e) for each request that contains a TRANSACTION
> > TOKEN, decrypt that token,
> >  parse it to a number and compare the result to
> > the CURRENT TRANSACTION.
> >  If they are both equal, then you received a
> > correct transaction so you
> >    i) increase the CURRENT TRANSACTION in the
> > session (this is vital!)
> >    ii) process the request
> >  Else the transaction is illegal and you can
> > ignore the request.
> >
> > You could create completely random transaction
> > tokens as well (saves the
> > effort
> > of encrypting the numbers), but then you run into
> > the probability that you
> > replicate some old transaction, if you RNG is
> > poor.
> >
> > Hope that helped and kind regards
> >
> > Ingo Struck
> >
> >    
>
>
> =====
> " DON'T WORRY BE HAPPY,
>     EVERY NIGHT YOU HAVE SOME TROUBLE,
>     IF YOU WORRY YOU MAKE IT DOUBLE,
>     SO DON'T WORRY BE HAPPY NOW...."
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
>