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

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
reading
> > > for those who haven't seen it:
> > >
> > >
http://blog.valverde.me/2015/12/07/bad-life-advice/#.VvLe6rMpDmE
> > >
> > > (I was a little surprised to see that the behavior of browsers had
shifted
> > > over the years to transparently retry POSTs over broken connections
by default.)
> >
> > Very interesting indeed. One can easily imagine an attack; e.g., a
captive
> > 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
the
> > places where it most matters, e.g., online payments).
> >
> > Regardless, it seems like we should either change the implementations,
or
> > change the spec.
>
> I guess that we should at least document that this behaviour exists and
must
> be addressed in applications. For many years I've heard users ask if
haproxy
> 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
clicking
> "Yes" in the warning box). By indicating that this behaviour exists, we
can
> 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.

Phil