Re: [CSP2] Preventing page navigation to untrusted sources

> There are so many ways to exfiltrate data that if you assume you have XSS you have already lost. Still, speedbumps are not useless.
Although the web is quite leaky indeed CSP is getting quite close to patching it up. Add to that that Google Caja has already succeeded at all this stuff with far more limited tooling we can at least assume it's doable. And yes, certain attacks like with a secondary party analyzing CPU load is definitely possible, but it requires a *lot* more care and is a lot more unreliable than direct communication like navigation and `postChannel` provide. Lastly CSP already seems concerned with script based data leakage in the `connect-src` directive.
> ​This message from last yearhttps://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"
One small note: Although this would be valuable for my private use case, the way it is proposed in that message is incomparably more limited than this proposal. Where this proposal provides value to any data-sensitive web app, the linked proposal only provides value to a very specific subset of sandboxes.
> 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.
Have to speak out explicitly against the idea of an interstitial page. I can not think of any situation whatsoever where this provides value to either the user or the developer. To just explore the different use cases: - Web app owner wishing to lock his site down:   o Misses adding the 'clean' destination developer-private-site.com : If the user is served with a huge warning page associated with his name I believe the developer would have preferred the links not working at all.   o Actual XSS-attack : An interstitial page now creates space for the attacker to convince the user to navigate to the malicious site after all. E.g. `alert('You will get an incorrect error page after click on this link. Click "Continue" at the bottom of the page to get your free iPhone.')` - Web app needing to sandbox third party content:   o Once again an interstitial page will only provide space to social engineer data out of the sandbox. 
> 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.

Totally agree.
Greetings, David Mulder
PS. Sorry for double post, mail client is acting up 



     On Wednesday, April 29, 2015 6:31 AM, 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