W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: UPGRADE: Feature detection?

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 12 Feb 2015 21:38:29 +1100
Message-ID: <CABkgnnXNSUxyF18Qhf_bpQRUo2mK-Kp9LyB9kkgnAaOEqhN9mQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC