Re: [CSP2] Preventing page navigation to untrusted sources

Let's take a look at a concrete proposal and evaluate it against some of
the scenarios we have in mind.  That seems to be the best way forward.
Maybe it will also help to identify a couple of use cases.  Perhaps there
are other solutions available once we clarify.

On Thu, Apr 30, 2015 at 6:54 AM David Mulder <david.mulder@ymail.com> wrote:

> Hey,
>
>  Did you understand the keyword `allow-user-override` the way I
> understood/described it in my second post
> <https://www.notehub.org/2015/4/30/hi-2>? And if so, did you comprehend
> the 'attack' I described (the 'clickjacking' one)? Due to that I do not see
> any value in that keyword, but I might be missing something obvious.
>
>  Greetings,
>
>  David Mulder
>
>
>
>
>   On Thursday, April 30, 2015 12:23 AM, Deian Stefan <
> deian@scs.stanford.edu> wrote:
>
>
> David Mulder <david.mulder@ymail.com> writes:
>
> >> 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​
>
> <https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0047.html%E2%80%8B>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
> >
> >
> >
>
> Hey guys,
>
> I worked on this, but have not yet finished -- will have a PR for this
> by the end of the weekend. I like the proposal of having
> 'allow-user-override'; this seems like a good escape hatch and maybe
> cover many of the use cases for script-navigation-dst.  (Though in
> principle I like the idea of script-navigation-dst, I think the
> implementation seems non-trivial.) David: does this sound reasonable to
>
> you?
>
>
> Thanks,
> Deian
>
>