Re: [CSP2] Preventing page navigation to untrusted sources

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