Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Browser Back Button
Date: Tue, 10 Jan 2017 08:03:59 +0100
Lines: 25
Message-ID: <edjfb0Fg0mjU1@mid.individual.net>
References: <9fc9d84a-b4a7-45a6-a47a-ab7d885bf5ce@googlegroups.com> <o50l57$t2g$1@gwaiyur.mb-net.net> <o51aks$18p4$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Trace: individual.net Y3MXpwsouQhjk8iKiWFsYgDdLFEz6ihMGN1j9d3vxAcgexJ8A=
Cancel-Lock: sha1:25k9ibPV8OvojgDe5wrvz0XU9o0=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
In-Reply-To: <o51aks$18p4$1@gioia.aioe.org>
Xref: csiph.com comp.lang.java.programmer:36180

On 10.01.2017 01:42, Arne Vajh=C3=B8j 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 repla=
y
>> 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

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