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 (tm) 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.
I would really hope a website couldn''t remotely clear out my browser history... Tony On 2/12/06, David Mitchell <monch1962@gmail.com> wrote:> > 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 > (tm) 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. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060213/b9668fd2/attachment.html
On 2/13/06, Tony Collen <tcollen@gmail.com> 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
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.
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. On 14/02/06, Estelle Winterflood <estelle.winterflood@gmail.com> wrote:> 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. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
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 ;) 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 On 2/13/06, David Mitchell <monch1962@gmail.com> wrote:> 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. > > On 14/02/06, Estelle Winterflood <estelle.winterflood@gmail.com> wrote: > > 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. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 13-Feb-06, at 2:30 PM, Tony Collen 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
On 2/13/06, Wayne Larsen <wayne@larsen.st> wrote:> > On 13-Feb-06, at 2:30 PM, Tony Collen 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" :) This seems like a useful way of handling it. Tony
>> 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.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. -- Posted with http://DevLists.com. Sign up and save your time!
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. On 14/02/06, Tony Collen <tcollen@gmail.com> wrote:> 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 ;) > > 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 > > On 2/13/06, David Mitchell <monch1962@gmail.com> wrote: > > 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. > > > > On 14/02/06, Estelle Winterflood <estelle.winterflood@gmail.com> wrote: > > > 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. > > > _______________________________________________ > > > Rails mailing list > > > Rails@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
On Tuesday, February 14, 2006, at 7:13 AM, David Mitchell wrote:>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. > >On 14/02/06, Estelle Winterflood <estelle.winterflood@gmail.com> wrote: >> 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. >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/railsDave, 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. -- Posted with http://DevLists.com. Sign up and save your time!