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

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

Received on Thursday, 24 March 2016 06:49:03 UTC