Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36172 > unrolled thread

Browser Back Button

Back to article view | Back to comp.lang.java.programmer

Contents

  Browser Back Button Davej <galt_57@hotmail.com> - 2017-01-08 15:41 -0800
    Re: Browser Back Button Arne Vajhøj <arne@vajhoej.dk> - 2017-01-08 19:30 -0500
      Re: Browser Back Button Arne Vajhøj <arne@vajhoej.dk> - 2017-01-08 20:20 -0500
        Re: Browser Back Button Davej <galt_57@hotmail.com> - 2017-01-10 15:29 -0800
          Re: Browser Back Button Arne Vajhøj <arne@vajhoej.dk> - 2017-01-10 19:49 -0500
            Re: Browser Back Button Robert Klemme <shortcutter@googlemail.com> - 2017-01-11 19:13 +0100
              Re: Browser Back Button Davej <galt_57@hotmail.com> - 2017-01-21 11:43 -0800
                Re: Browser Back Button Robert Klemme <shortcutter@googlemail.com> - 2017-01-22 13:52 +0100
                  Re: Browser Back Button Davej <galt_57@hotmail.com> - 2017-01-22 08:34 -0800
    Re: Browser Back Button Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-01-09 19:35 +0100
      Re: Browser Back Button Arne Vajhøj <arne@vajhoej.dk> - 2017-01-09 19:42 -0500
        Re: Browser Back Button Robert Klemme <shortcutter@googlemail.com> - 2017-01-10 08:03 +0100
          Re: Browser Back Button lewbloch@gmail.com - 2017-01-10 11:30 -0800

#36172 — Browser Back Button

I am playing with a simple login/logout scheme using a combination
of JSP and servlets, but apparently I'm not understanding the 
ideal procedure to prevent odd results from the use of the browser 
BACK button.

In the Login.jsp page I post a password and username to LoginServlet.

In LoginServlet I validate the password and add the member object
to the session...

request.getSession().addAttribute("member");

Then I forward to the Membership.jsp page. From Membership.jsp
I can click a logout button which posts to LogoutServlet where 
I use...

request.getSession().removeAttribute("member");
request.getSession().invalidate();

...and then forward back to the Login.jsp page.

The problem is that if I immediately log out after logging in
and then use the browser BACK button the browser will resend
the username and password parameters and log me back in again.

"This document is no longer available.
The requested document is not available in Firefox’s cache.
As a security precaution, Firefox does not automatically 
re-request sensitive documents.
Click Try Again to re-request the document from the website.

[Try Again]"

I guess this is just an odd little quirk, but is there perhaps
an easy way to prevent this?

Thanks.

[toc] | [next] | [standalone]

#36173

On 1/8/2017 6:41 PM, Davej wrote:
> I am playing with a simple login/logout scheme using a combination
> of JSP and servlets, but apparently I'm not understanding the
> ideal procedure to prevent odd results from the use of the browser
> BACK button.
>
> In the Login.jsp page I post a password and username to LoginServlet.
>
> In LoginServlet I validate the password and add the member object
> to the session...
>
> request.getSession().addAttribute("member");
>
> Then I forward to the Membership.jsp page. From Membership.jsp
> I can click a logout button which posts to LogoutServlet where
> I use...
>
> request.getSession().removeAttribute("member");
> request.getSession().invalidate();
>
> ...and then forward back to the Login.jsp page.
>
> The problem is that if I immediately log out after logging in
> and then use the browser BACK button the browser will resend
> the username and password parameters and log me back in again.
>
> "This document is no longer available.
> The requested document is not available in Firefox’s cache.
> As a security precaution, Firefox does not automatically
> re-request sensitive documents.
> Click Try Again to re-request the document from the website.
>
> [Try Again]"
>
> I guess this is just an odd little quirk, but is there perhaps
> an easy way to prevent this?

I don't think there is anything servlet/JSP specific in the
problem.

Long time since I have worked with stuff like this, but I believe
one way of handling it is to redirect instead of forward.

Arne

[toc] | [prev] | [next] | [standalone]

#36174

On 1/8/2017 7:30 PM, Arne Vajhøj wrote:
> On 1/8/2017 6:41 PM, Davej wrote:
>> I am playing with a simple login/logout scheme using a combination
>> of JSP and servlets, but apparently I'm not understanding the
>> ideal procedure to prevent odd results from the use of the browser
>> BACK button.
>>
>> In the Login.jsp page I post a password and username to LoginServlet.
>>
>> In LoginServlet I validate the password and add the member object
>> to the session...
>>
>> request.getSession().addAttribute("member");
>>
>> Then I forward to the Membership.jsp page. From Membership.jsp
>> I can click a logout button which posts to LogoutServlet where
>> I use...
>>
>> request.getSession().removeAttribute("member");
>> request.getSession().invalidate();
>>
>> ...and then forward back to the Login.jsp page.
>>
>> The problem is that if I immediately log out after logging in
>> and then use the browser BACK button the browser will resend
>> the username and password parameters and log me back in again.
>>
>> "This document is no longer available.
>> The requested document is not available in Firefox’s cache.
>> As a security precaution, Firefox does not automatically
>> re-request sensitive documents.
>> Click Try Again to re-request the document from the website.
>>
>> [Try Again]"
>>
>> I guess this is just an odd little quirk, but is there perhaps
>> an easy way to prevent this?
>
> I don't think there is anything servlet/JSP specific in the
> problem.
>
> Long time since I have worked with stuff like this, but I believe
> one way of handling it is to redirect instead of forward.

And to avoid any doubt. LoginServlet redirect instead
of forward to Membership.jsp.

Arne

[toc] | [prev] | [next] | [standalone]

#36182

On Sunday, January 8, 2017 at 7:20:29 PM UTC-6, Arne Vajhøj wrote:
> On 1/8/2017 7:30 PM, Arne Vajhøj wrote:
> > On 1/8/2017 6:41 PM, Davej wrote:
> >> I am playing with a simple login/logout scheme using a combination
> >> of JSP and servlets, but apparently I'm not understanding the
> >> ideal procedure to prevent odd results from the use of the browser
> >> BACK button.
> >>
> >> In the Login.jsp page I post a password and username to LoginServlet.
> >>
> >> In LoginServlet I validate the password and add the member object
> >> to the session...
> >>
> >> request.getSession().addAttribute("member");
> >>
> >> Then I forward to the Membership.jsp page. From Membership.jsp
> >> I can click a logout button which posts to LogoutServlet where
> >> I use...
> >>
> >> request.getSession().removeAttribute("member");
> >> request.getSession().invalidate();
> >>
> >> ...and then forward back to the Login.jsp page.
> >>
> >> The problem is that if I immediately log out after logging in
> >> and then use the browser BACK button the browser will resend
> >> the username and password parameters and log me back in again.
> >>
> >> "This document is no longer available.
> >> The requested document is not available in Firefox’s cache.
> >> As a security precaution, Firefox does not automatically
> >> re-request sensitive documents.
> >> Click Try Again to re-request the document from the website.
> >>
> >> [Try Again]"
> >>
> >> I guess this is just an odd little quirk, but is there perhaps
> >> an easy way to prevent this?
> >
> > I don't think there is anything servlet/JSP specific in the
> > problem.
> >
> > Long time since I have worked with stuff like this, but I believe
> > one way of handling it is to redirect instead of forward.
> 
> And to avoid any doubt. LoginServlet redirect instead
> of forward to Membership.jsp.
> 

I'm having a problem using a redirect because I'm using a filter, and
the filter doesn't seem to like that. I end up with a 500 error.

One solution seems to be to invalidate the session upon a successful
login and create a new session for the session member object.

[toc] | [prev] | [next] | [standalone]

#36183

On 1/10/2017 6:29 PM, Davej wrote:
> On Sunday, January 8, 2017 at 7:20:29 PM UTC-6, Arne Vajhøj wrote:
>> On 1/8/2017 7:30 PM, Arne Vajhøj wrote:
>>> On 1/8/2017 6:41 PM, Davej wrote:
>>>> The problem is that if I immediately log out after logging in
>>>> and then use the browser BACK button the browser will resend
>>>> the username and password parameters and log me back in again.

>>>> I guess this is just an odd little quirk, but is there perhaps
>>>> an easy way to prevent this?
>>>
>>> I don't think there is anything servlet/JSP specific in the
>>> problem.
>>>
>>> Long time since I have worked with stuff like this, but I believe
>>> one way of handling it is to redirect instead of forward.
>>
>> And to avoid any doubt. LoginServlet redirect instead
>> of forward to Membership.jsp.
>>
>
> I'm having a problem using a redirect because I'm using a filter, and
> the filter doesn't seem to like that. I end up with a 500 error.
>
> One solution seems to be to invalidate the session upon a successful
> login and create a new session for the session member object.

Or you could troubleshoot that filter problem. There must be a reason
and a solution to that problem.

I would not like to run with a filter that barfs on redirects.

Arne

[toc] | [prev] | [next] | [standalone]

#36184

On 11.01.2017 01:49, Arne Vajhøj wrote:
> On 1/10/2017 6:29 PM, Davej wrote:

>> I'm having a problem using a redirect because I'm using a filter, and
>> the filter doesn't seem to like that. I end up with a 500 error.
>>
>> One solution seems to be to invalidate the session upon a successful
>> login and create a new session for the session member object.

I do not think that is necessary, you just need to record proper login 
state in the session.  Creating new sessions eats up entropy and is 
usually also slower than updating the session instance.

> Or you could troubleshoot that filter problem. There must be a reason
> and a solution to that problem.
>
> I would not like to run with a filter that barfs on redirects.

Agree.  This is a typical use case for using a Filter.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#36205

On Wednesday, January 11, 2017 at 12:13:35 PM UTC-6, Robert Klemme wrote:
> On 11.01.2017 01:49, Arne Vajhøj wrote:
> > On 1/10/2017 6:29 PM, Davej wrote:
> 
> >> I'm having a problem using a redirect because I'm using a filter, and
> >> the filter doesn't seem to like that. I end up with a 500 error.
> >>
> >> One solution seems to be to invalidate the session upon a successful
> >> login and create a new session for the session member object.
> 
> I do not think that is necessary, you just need to record proper login 
> state in the session.  Creating new sessions eats up entropy and is 
> usually also slower than updating the session instance.
> 
> > Or you could troubleshoot that filter problem. There must be a reason
> > and a solution to that problem.
> >
> > I would not like to run with a filter that barfs on redirects.
> 
> Agree.  This is a typical use case for using a Filter.
> 


What about the practice of placing this at the top of a JSP?

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%
    response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
    response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
    response.setHeader("Expires", "0"); // Proxies.
%>
<!DOCTYPE html>
[...etc...]

[toc] | [prev] | [next] | [standalone]

#36212

On 21.01.2017 20:43, Davej wrote:
> On Wednesday, January 11, 2017 at 12:13:35 PM UTC-6, Robert Klemme wrote:
>> On 11.01.2017 01:49, Arne Vajhøj wrote:

>>> I would not like to run with a filter that barfs on redirects.
>>
>> Agree.  This is a typical use case for using a Filter.

> What about the practice of placing this at the top of a JSP?
>
> <%@page contentType="text/html" pageEncoding="UTF-8"%>
> <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
> <%
>     response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
>     response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
>     response.setHeader("Expires", "0"); // Proxies.
> %>
> <!DOCTYPE html>
> [...etc...]
>

You do not want to have this type of functionality (detect that someone 
is not logged in and redirect to the login page) in every JSP.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#36215

On Sunday, January 22, 2017 at 6:52:48 AM UTC-6, Robert Klemme wrote:
> On 21.01.2017 20:43, Davej wrote:
> > On Wednesday, January 11, 2017, Robert Klemme wrote:
> >> On 11.01.2017 01:49, Arne Vajhøj wrote:
> 
> >>> I would not like to run with a filter that barfs on redirects.
> >>
> >> Agree.  This is a typical use case for using a Filter.
> 
> > What about the practice of placing this at the top of a JSP?
> >
> > <%@page contentType="text/html" pageEncoding="UTF-8"%>
> > <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
> > <%
> >     response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
> >     response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
> >     response.setHeader("Expires", "0"); // Proxies.
> > %>
> > <!DOCTYPE html>
> > [...etc...]
> >
> 
> You do not want to have this type of functionality (detect that someone 
> is not logged in and redirect to the login page) in every JSP.
> 


But what about sending "no-cache" headers to prevent caching of 
sensitive pages?

[toc] | [prev] | [next] | [standalone]

#36178

On 09.01.17 00.41, Davej wrote:
> The problem is that if I immediately log out after logging in
> and then use the browser BACK button the browser will resend
> the username and password parameters and log me back in again.

This will probably work even with more pages in between.

First of all check that your content page really relies on a successful 
login. The content page must not have the login credentials in the 
request. neither in the url nor in post data nor in cookies.

Then use HTTP redirect 303 in case of successful login.

Destroy the session on logout and accept a login only if it comes with 
the current, unpredictable session ID and the session is not just 
created by the login request. This will prevent from any kind of replay 
attack.

If you can't destroy the session ID place a unique id in the session 
each time you present the login page, pass the ID in a hidden field and 
verify the ID on login. Destroy the ID on logout.


Marcel

[toc] | [prev] | [next] | [standalone]

#36179

On 1/9/2017 1:35 PM, Marcel Mueller wrote:
> Destroy the session on logout and accept a login only if it comes with
> the current, unpredictable session ID and the session is not just
> created by the login request. This will prevent from any kind of replay
> attack.

I thought HTTPS protected against replay attacks?

Arne

[toc] | [prev] | [next] | [standalone]

#36180

On 10.01.2017 01:42, Arne Vajhøj wrote:
> On 1/9/2017 1:35 PM, Marcel Mueller wrote:
>> Destroy the session on logout and accept a login only if it comes with
>> the current, unpredictable session ID and the session is not just
>> created by the login request. This will prevent from any kind of replay
>> attack.
>
> I thought HTTPS protected against replay attacks?

Yes, on the TCP level.  And strictly it is SSL that does the protection. 
  But browser back does not do a replay of network requests.  It sends a 
previous request again.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#36181

On Monday, January 9, 2017 at 11:04:14 PM UTC-8, Robert Klemme wrote:
> On 10.01.2017 01:42, Arne Vajhøj wrote:
> > On 1/9/2017 1:35 PM, Marcel Mueller wrote:
> >> Destroy the session on logout and accept a login only if it comes with
> >> the current, unpredictable session ID and the session is not just
> >> created by the login request. This will prevent from any kind of replay
> >> attack.
> >
> > I thought HTTPS protected against replay attacks?
> 
> Yes, on the TCP level.  And strictly it is SSL that does the protection. 
>   But browser back does not do a replay of network requests.  It sends a 
> previous request again.

One standard technique is to issue a one-time token to the non-idempotent screen. Any resubmission will resend that token, and the server can detect that it has already processed the token and ignore the request.

One thing you should never do is to defeat the visual effects of the back button altogether. 

-- 
Lew

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web