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

["Tim Aranki" <tim.aranki () dev-quest com>]

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