Re: [CSP2] Preventing page navigation to untrusted sources

Hey,
 Did you understand the keyword `allow-user-override` the way I understood/described it in my second post? 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​ 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