Re: [CSP2] Preventing page navigation to untrusted sources

<hat=individual>
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
>