W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: Restrict loopback address to Secure Contexts?

From: Mike West <mkwst@google.com>
Date: Tue, 27 Sep 2016 10:48:07 +0200
Message-ID: <CAKXHy=fsHvp5KeUh52w5-nRhKyxT0gt8z2twsYOCHZ-1MVXofA@mail.gmail.com>
To: "Eduardo' Vela <Nava>" <evn@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Devdatta Akhawe <dev.akhawe@gmail.com>, Crispin Cowan <crispin@microsoft.com>, "wilander@apple.com" <wilander@apple.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Sep 27, 2016 at 10:42 AM, Eduardo' Vela" <Nava> <evn@google.com>

> An attacker that can inject code to talk to van also inject code
> that iframes an https site that talks to Blocking access to
> from HTTP sites doesn't help the user, does it?
An HTTPS site framed in an HTTP top-level site is not considered a "secure
context" (see
https://w3c.github.io/webappsec-secure-contexts/#examples-framed for some

> The only argument I can imagine is that a web server mistakenly
> allows access from http://onesite.com to fo scare stuff, and such attack
> would be harder to achieve if we force secure origins to talk to local host.
I think this is harder to exploit than you're suggesting, given the above.
The attacker would need to navigate the user to a top-level secure context
that they control. Totally not impossible, but not as easy or as invisible
as injecting elements into an existing page.

> However, there are legitimate use cases for http sites to talk to
> localhost.. so I would rather it was left allowed.
What kinds of use cases are you thinking of?

Received on Tuesday, 27 September 2016 08:49:00 UTC

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