W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Retrying failed POSTs [was: Retry safety of HTTP requests]

From: Phil Lello <phil@dunlop-lello.uk>
Date: Thu, 24 Mar 2016 11:56:21 +0000
Message-ID: <CAPofZaH43UAoggi_V-P=td+Qvq1CHqmhh1ZVnwmPok1nCbh0vA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Mark Nottingham <mnot@mnot.net>, Erik Nygren <erik@nygren.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 24 Mar 2016 06:54, "Willy Tarreau" <w@1wt.eu> wrote:
> On Thu, Mar 24, 2016 at 10:08:53AM +1100, Mark Nottingham wrote:
> > On 24 Mar 2016, at 5:37 AM, Erik Nygren <erik@nygren.org> wrote:
> > >
> > > This post on attacks against POST retries in HTTPS is also worth
> > > for those who haven't seen it:
> > >
> > >
> > >
> > > (I was a little surprised to see that the behavior of browsers had
> > > over the years to transparently retry POSTs over broken connections
by default.)
> >
> > Very interesting indeed. One can easily imagine an attack; e.g., a
> > portal asks for online payment, and gets paid twice.
> >
> > The advice to use a CSRF token is good, but it's pretty obvious that
it's not
> > being followed consistently or well (although maybe it's good enough in
> > places where it most matters, e.g., online payments).
> >
> > Regardless, it seems like we should either change the implementations,
> > change the spec.
> I guess that we should at least document that this behaviour exists and
> be addressed in applications. For many years I've heard users ask if
> could replay failed requests, I respond "no and it must not" then they say
> "but my current product XYZ does"... No wonder why a friend received two
> similar books the same day (and was charged twice).
> It's not very hard to address in applications where this is sensitive (eg:
> payment). It requires a transaction ID. It's a good practise against bad
> user behaviour as well (eg: people pressing back, then forward and
> "Yes" in the warning box). By indicating that this behaviour exists, we
> sensitize developers to this and make them improve their applications.
> Note that I'm not trying to defend auto-retry. I'm just saying we know it
> exists sometimes.
> Willy
Theoretically this should be addressed by a nonce in the message flow -
perhaps the http/2 stream should be reusable to provide a built-in for this
scenario? My http/2 experience is still theoretical at present, but I
believe the intent is one stream per request.

Received on Thursday, 24 March 2016 11:56:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 March 2016 11:56:58 UTC