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

Re: [CSP2] Preventing page navigation to untrusted sources

From: Brad Hill <hillbrad@gmail.com>
Date: Wed, 29 Apr 2015 05:11:05 +0000
Message-ID: <CAEeYn8jcG147D=t2OXMtgBKiMEeeuE+mKdK43YWFd80zQnvTDA@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>, David Mulder <david.mulder@ymail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Good points. I don't imagine we'd ever allow such a policy to prevent
using, e.g the built-in back buttons or closing the tab.  (Not that back
always helps in a long redirect chain, but that's an issue we have to deal
with today independent of any such directive)

On Tue, Apr 28, 2015 at 9:09 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> On Mon, Apr 27, 2015 at 2:57 PM, David Mulder <david.mulder@ymail.com>
> wrote:
>> Given that an attacker has found a way to execute Javascript through an
>> XSS injection `connect-src` could be a valuable tool to prevent data from
>> being leaked. The problem however is that it is not possible to prevent
>> page navigation
>> ​ ​
> [....]​
> ​ ​
>> It would be incredibly valuable if a website owner could limit to which
>> pages his pages are allowed to link or direct in any way.
> ​This is a common request that we haven't gotten around to yet. There are
> so many ways to exfiltrate data that if you assume you have XSS you have
> already lost. Still, speedbumps are not useless.
> I know this has been talked about from the beginning but one older
> reference I can find is
> https://lists.w3.org/Archives/Public/public-web-security/2011Feb/0106.html
> ​
> ​This message from last year
> https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0047.html​
> eventually led to raising our ISSUE 69 (
> http://www.w3.org/2011/webappsec/track/issues/69) to discuss this along
> with postMessage as part of "CSP 3"
> ​Considering the lengths we see some malicious sites go to in preventing
> users from leaving​ until they've agreed to whatever I wouldn't want such a
> directive to leave users trapped on the CSP-protected page. Instead maybe
> an interstitial warning page as we do for phishing attempts, informing the
> user that the navigation was not an expected exit point for the page and
> could be an attack, along with a big "get me out of here" button that takes
> the user to their homepage. _Not_ back to the previous page which we know
> to be compromised according to its own specified policy. Of course UI
> treatments are outside the scope of our spec. And of course implementations
> would have to make sure that bookmarks or URLs typed directly into the
> address bar were not hindered by the policy; even navigation from external
> windows should continue to work.
> -Dan Veditz
Received on Wednesday, 29 April 2015 05:11:32 UTC

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