- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 12 Feb 2015 21:38:29 +1100
- To: Mike West <mkwst@google.com>
- Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>, Eric Mill <eric@konklone.com>, Jacob S Hoffman-Andrews <jsha@eff.org>
On 12 February 2015 at 18:35, Mike West <mkwst@google.com> wrote: > The upgrade strawman we're discussing intends to act on form > submissions as well. To what extent do you expect upgrading from HTTP > to HTTPS for non-idempotent methods to be dangerous? XHR for same "origin" I suppose as well. GET, fine, at least by definition, though the actual implementation of safe&idempotent has been rocky in the past. POST, well... We have evidence that services running on different ports are indeed different and sometimes separate. Even if 443 and 80 together enjoy special status, it's clear that they are not always identical. That https://forbes.com might be making form posts against http://forbes.com (to pick an well-known example), creates an actual risk that an unwanted request is made. And then permitted. Given that the request is made with cookies and full authentication information, that creates at least a theoretical risk. I think a lot of this can be managed through the explicit opt-in. That would require that the site a) be warned of the dangers and b) takes some extra steps to ensure that they aren't exposing themselves to those dangers. I know that extra knobs have their own costs, but would a two-stage opt-in be a way to manage this? One for passive-only and a second for an unconditional rewrite. Most sites probably won't need to rewrite XHR or form submissions, but I can see them being a little cagey about something that might pwn them if they missed something. Conservative, or maybe just lazy.
Received on Thursday, 12 February 2015 10:38:56 UTC