Clearing browser history?


#1

Hello everyone,

I’ve got an app where, when a user logs out, I want the browser
history to be cleared so no-one can go back and see what the user was
doing.

I remember seeing info on how to do this before - can’t find it in
Google (the search terms “clear”, “browser” and “history” aren’t that
great!), which means I can’t remember if it was a Neat Rails Trick
™ or involved getting down and dirty with JavaScript (plus coping
with different browser versions - ugh!).

Has anyone got a pointer to info on how to clear browser history?

Thanks in advance

Dave M.


#2

I would really hope a website couldn’t remotely clear out my browser
history…

Tony


#3

On 2/13/06, Tony C. removed_email_address@domain.invalid wrote:

I would really hope a website couldn’t remotely clear out my browser
history…

And more importantly, I would hope that a website isn’t relying on
this for any kind of security.

– James


#4

David

Why don’t you just display a warning when the user logs out, eg. “If
you are using a shared computer, please close your browser window for
security reasons”.

And you could try to force the user to use a separate window, similar
to how netbanking usually works (when you click the button to access
netbanking, a popup window is often opened where you enter username &
password and continue).

Estelle.


#5

Yep. For starters, you shouldn’t be storing sensitive information in
the URL as HTTP GET, e.g.:

/myBankingApp/showAccount/123-45-6789 # An SSN

or

/myBankingApp/transfer?from=12345&to=56789&total=50.00

While tempting because it’s really easy, this is painfully obviously
insecure :wink:

Secondly, a short session timeout/cookie lifetime would help mitigate
the problem. A cookie with an expiry in the past will go away when
the browser is closed. At the place I work at, we timeout the user’s
session after about 5 minutes and automatically log them out. This is
extra important because we deal with private health information.

Thirdly, if it’s that sensitive, also consider securing the app
using HTTPS. I know browsers will do things like not caching pages
that use SSL. Hooking into window.close() is only so good, because it
relies on Javascript.

If you look at eBay and Amazon, they constantly ask you to log in.
While being kind of a PITA, it’s pretty secure.

A good way to test your site security would be to go through the app
as a logged in user, close the browser or log out, and then try to go
to a specific page in the user’s history as a non-logged in user.
Obviously having your controllers do “before_filter :login_required”
or whatever is a good thing, but also doing queries that include the
user’s credentials from the session also seems like a good thing.
That way you’re getting the user information from your login
controller and nowhere else.

Regards,
Tony


#6

On 13-Feb-06, at 2:30 PM, Tony C. wrote:

Thirdly, if it’s that sensitive, also consider securing the app
using HTTPS. I know browsers will do things like not caching pages
that use SSL. Hooking into window.close() is only so good, because it
relies on Javascript.

This is a good suggestion. On a tangent, is it possible to make a
browser cache a page that uses ssl?

With a CMS using HTTPS, I have to make sure users know that they
can’t click on a link while editing text in a form, because the back
button will reload the form, losing any changes they have made. This
has been the cause of some unfortunate data loss, that I would like
to be able to eliminate.

Thanks,
Wayne


#7

Thanks everyone,

My primary concern is to ensure that sensitive information isn’t
viewable via someone hitting the ‘Back’ button. I’ve got other
methods of enforcing security as well.

I hadn’t thought of using the Internet banking approach of opening a
new window; strange, since I’ve tested multiple Internet banking
setups in the past. Think I’ll go with that, and link the “Logout”
functionality to a window.close() as well as deleting all session
info.

Regards

Dave M.


#8

On 2/13/06, Wayne L. removed_email_address@domain.invalid wrote:

On 13-Feb-06, at 2:30 PM, Tony C. wrote:

Thirdly, if it’s that sensitive, also consider securing the app
using HTTPS. I know browsers will do things like not caching pages
that use SSL. Hooking into window.close() is only so good, because it
relies on Javascript.

This is a good suggestion. On a tangent, is it possible to make a
browser cache a page that uses ssl?

Not from the server-side. MSIE has an option to enable caching of
pages, but the user has to obviously set it.

With a CMS using HTTPS, I have to make sure users know that they
can’t click on a link while editing text in a form, because the back
button will reload the form, losing any changes they have made. This
has been the cause of some unfortunate data loss, that I would like
to be able to eliminate.

Google Mail handles this with JS alerts and auto-saving of drafts…
just as I am typing it, it says “Draft autosaved at 4:07 pm” :slight_smile: This
seems like a useful way of handling it.

Tony


#9

button will reload the form, losing any changes they have made.
This has been the cause of some unfortunate data loss, that I would
like to be able to eliminate.

I’d also suggest HTTPS. The browser history is really not your
“property” so to speak: it belongs to the user who created that path
from page to page. HTTPS at least lets you control its creation in the
first place. (Although almost every web application can benefit from
good support of the browser Back button and the page history.)

Regarding the danger of losing form data, in practice, the best thing to
do is often to put important forms on pages that are dedicated wholly to
them, and not surround the forms with tempting-looking links. If you
need contextual links–say for help information related to the form–you
might want to have those open popups.


#10

I don’t have any sensitive data stored within the URL; however, if you
scroll back through the browser history, you can see data onscreen
(retrieved from the history) that is sensitive.

I’ve already got short timeouts on cookies, and I’m about to deploy over
HTTPS.

I think the best approach will be to close the browser window when the
user logs out. That way there’s no scrolling back through screen
history.

Of course, now I’ve got the problem of getting users to ACTUALLY log
out, which is a whole separate issue…

Regards

Dave M.


#11

On Tuesday, February 14, 2006, at 7:13 AM, David M. wrote:

info.

security reasons".
http://lists.rubyonrails.org/mailman/listinfo/rails


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

Dave,

You can use Cache-Control, Expires and Pragma No-Cache to prevent
browser from caching the page. This will make sure the Back button does
not show the cached page.

Best Regards, Roustem.