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

[Andy Talbot <atalbot () sli co im>]

Hi K

I've only caught the rear end of this thread, so I do apologise if I'm
replicating something that has already been said or I've missed the point of
your query.

As part of our past web developments, one of the most simplest methods of
preventing resubmitted authentication (assuming logout has been performed!),
was the inclusion of a SessionID as part of every POST/GET statement. Upon
logout the unique SessionID (on SQL server) is time/date expired (also set
to a default time out after x mins of no activity) and also expires
regardless of activity after x hours, (forcing a new login). Thus for each
POST/GET the SessionID must be unexpired in each instance.

As Ingo has said below, a unique transaction token also works very well and
this was another preventative measure of resubmission acceptance that we
like.

Kind Regards

Andy Talbot 
IT Developer
PC Development Team

-----Original Message-----
From: Ingo Struck [mailto:ingo () ingostruck de]
Sent: Tuesday, August 05, 2003 1:57 PM
To: K Kohli
Cc: webappsec () securityfocus com
Subject: RE: Browser refresh sends username/password after log out --
URGENT


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



===========================================================================================

The information in this e-mail is confidential and may be legally
privileged.  It is intended solely for the addressee and access to this
e-mail by anyone else is unauthorised.

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it is prohibited
and may be unlawful.

At present the integrity of e-mail across the Internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  Therefore we
will not accept liability for any claims arising as a result of the use of
this medium to transmit messages by or to the Scottish Life International
group of companies.

The Scottish Life International group of companies is owned by Royal London.

Scottish Life International Investment Group who provides marketing services is a Royal London company which is 
regulated by the Financial Services Authority for UK investment business and only promotes the investment, life 
assurance and pensions products of the Royal London marketing group.
Registered Office: 19 St Andrew Square, Edinburgh EH2 1YE, United Kingdom.
Registered in Scotland No. 166387.

Scottish Life International Insurance Company Limited, a Royal London company, is the Isle of Man based product 
provider of life assurance and investment products of the Royal London marketing group. Scottish Life International 
Insurance Company Limited is authorised by the Isle of Man Government Insurance and Pensions Authority. A member of the 
Association of International Life Offices.  Registered in the Isle of Man Number 076981C.  Registered Office: Exchange 
House, 54-58 Athol Street, Douglas,
Isle of Man IM1 1JD, British Isles.

Scottish International Fund Managers Limited, a Royal London company, is licensed to conduct investment business as a 
Category 3 licenceholder by the Isle of Man Financial Supervision Commission under the Investment Business Act 1991.  
Registered in the Isle of Man number 89411C.  Registered address: 54-58 Athol Street, Douglas, Isle of Man, IM1 1JD, 
British Isles.