Re: [CSP2] How to restrict resources linking to

Hi, Craig

You have given a good and vivid case.

What I really mean to discuss is that  *will csp directive(maybe link-src
or others) and csp policy rule used to block links that appear on visiting
website be good for content security ? will it be a acceptable extension
for csp specs? *

As you metioned in the email, the discussion focuses on the second case or
"latter case".

As illustrated in the previous email.

> Please let me abstract the above cases and illustrate to the following
> senario.
> PageA has a hyberlink to PageB, and one of pages is malicious webpage.
> If we take roles into consideration, there are two cases.
> 1. PageA  ---links to---> *PageB
> 2. *PageA ---links to---> PageB
> where "*" indicates the current or protected page, and another is the
> restricted page.


What I suggest to resolve is the case 2 in the above senario.
That is *PageA ---links to---> PageB.
Where PageA is visiting page and PageB is the links in PageA.

Moreover, thank you for your good case, and I'm sorry if the my words in
previous email bother you, can you point out where is the puzzled points?

Sincerely!
Best regards
Zhongxiao yao



2015-09-02 17:53 GMT+08:00 Craig Francis <craig.francis@gmail.com>:

> Hi Yao,
>
> I may have just missed this, but is your suggestion to block other
> websites linking to your website (i.e. the one that provides the CSP
> header), or are you thinking about links that appear on your website?
>
> The former would be very unlikely to happen in CSP, but the latter may
> have some merit.
>
> For example, if I had a comment section on a blog, I may not want comments
> that link to other websites, but I may have a WYSIWYG editor for basic
> formatting. Hopefully the comments are still being filtered with a HTML
> sanitiser (to strip out any JavaScript), but it may not be configured to
> remove links, resulting in the commenter being able to link to a malicious
> website.
>
> Craig
>
>
>
>
> On 2 Sep 2015, at 04:59, yao zhongxiao <zhongxiao.yzx@gmail.com> wrote:
>
> Hi,  Brad Hill,
>
> Hi,  Everybody
>
> Thank you for your reply and point out possible solution for use cases.
>
> Maybe, it's my fault to title the email with "How to restrict resources
> linking to".
> What i really want to discuss in group is "is it possible or nessary to
> extend CSP rule to restrict a web resource which will be referred or
> navigate to?"
>
> Please let me show my points from the following aspects.
>
> 1.  As mentioned in your email, "CSP in general is a whitelist, not a
> blacklist mechanism, and I presume any list of sites you want to block is
> potentially unbounded"
>
> I am agree with you. It's definitely right and any policy with defined
> directive in CSP is formed by whitelist mechanism. However, from the
> opposite perspective, if we define a withelist, meanwhile, we also define
> the blacklist implicitly at the same time. Because, all policies in
> blacklist are those not in whitelist, aren't  they?
>
> Let's take referrer policy for example. If we define rules with
> referrer-src in whitelist, at the same time, we also define the policy to
> restrict the web resource those not in whitelist obviously, is that mean we
> define the blacklist for referrer-src implicitly ?
>
> 2.  Another view in your email is that  "CSP doesn't prevent any resource
> from linking to your resource, though your server might examine an HTTP
> Referer header (if one is sent) and decline to provide a response if it
> doesn't provide an expected value, or  the frame-ancestors directive can be
> used to restrict display of a resource in certain embedded contexts, but
>  not generally as part of navigation."
>
> As far as I know, CSP has not included any directives to define the policy
> for resource that linking to. The resource from other domains may go to
> browser directly and bypass your server examining the HTTP Referer header.
> It's dangerous !
>
> Furthermore, CSP may be implemented in agent client(browsers). The
> implementation in chromium is a good example. The csp implementation in
> chromium provides two level controls. The default policy is used while
> customized CSP policy has not defined explicitly, and if customized CSP
> policy is provided, the default CSP policy in system is overridden.
>
> The chromium implementation accepts CSP rules defined by meta or
> transmitted from server to browser where policy  is enforced. The browser
> fire a violation event at the protected resource’s document and send report
> to server (by report-uri).
>
> There are also  two more aspects about the restriction for resources
> linking to.
>
> 3.  CSP defines a policy language used to declare a set of content
> restrictions for a web resource, and a  mechanism for transmitting the
> policy from a server to a client where the policy is enforced. (
> https://w3c.github.io/webappsec/specs/CSP2/)
>
> The restrictions for resources sourced from and linking to are two aspects
> of confinement for a web resource. All directives of CSP policy are
> oriented to restrict web resources those sourced from except report-uri
> directive.
> However, CSP has not provided any directive to define the policy for
> resource that linking to. If we want to take CSP specs as blueprints to
> design and implement a service rather than Google's SafeBrowsing or
> Microsoft's SmartScreen service.
> wouldn't it be much more holonomic to supply a unified linking policy,
> event if it's an optional policy, rather than a required content security
> policy?
>
> For the sake of integrity of specs, meetting developers' content security
> requirements, supplying a much more unified and widely acceptable content
> security policy to restrict web resources linking to or navigating to will
> be a good and friendly extension for CSP specs.  isn't it ?
>
>
> 4.  Finally, from the aspects of developers, intentions to restrict
> resource sourced from and confine the resources navigating to in webapps or
> web services are very common.
> I think it will be an easy and efficient way helping designer and
> developers to mitigate the potential hostile attack or distributing malware
> by only define the navigating rules. It will provide designer or developer
> a good choice for content security policy of their webapps or web services.
>
>
> I am not sure if I have expressed my points clealy. If there are some
> mistakes or misunderstanding, do not  hesitate to point out. I am happy and
> it's my pleasure could make a discussion with you. If possible, I hope we
> can dig much more deeper on this topic (wish more and more participants).
>
> Sincerely!
>
> Best regards
>
> Zhongxiao yao
>
>
> 2015-09-01 0:47 GMT+08:00 Brad Hill <hillbrad@gmail.com>:
>
>> CSP doesn't prevent any resource from linking to your resource, though
>> your server might examine an HTTP Referer header (if one is sent) and
>> decline to provide a response if it doesn't provide an expected value, or
>> the frame-ancestors directive can be used to restrict display of a resource
>> in certain embedded contexts, but not generally as part of navigation.
>>
>> The work slowly moving forward on COWL (http://cowl.ws/) aims to provide
>> some confinement properties for document environments, but in general we
>> are very wary of breaking navigation in this way in the browser.
>>
>> It might help to understand your use cases better.  If a site you want to
>> block is "illegal" (by which I'll presume it is a phishing site or
>> distributing malware) wouldn't it make more sense to block navigation
>> generally using something like Google's SafeBrowsing or Microsoft's
>> SmartScreen service, instead of having to shoehorn this into a per-resource
>> policy?  CSP in general is a whitelist, not a blacklist mechanism, and I
>> presume any list of sites you want to block is potentially unbounded.
>>
>> -Brad
>>
>> On Mon, Aug 31, 2015 at 2:19 AM yao zhongxiao <zhongxiao.yzx@gmail.com>
>> wrote:
>>
>>> Sorry if it was out of scope, I am quite new in this mailing list.
>>>
>>> I want to seek advice from all of you about the rules to restrict
>>> malicious hyperlink that will be linked to.
>>> There are following ways but not limited to those:
>>> 1. <a href="https://www.evil.com/hijacked/Phishing.html">Visit illegal
>>> website</a>
>>> 2. <link href="https://www.evil.com/hijacked/Phishing.html"
>>> rel="external">Visit illegal website</a>
>>> 3. window.open("https://www.evil.com/hijacked/Phishing.html")
>>>
>>> Please let me abstract the above cases and illustrate to the following
>>> senario.
>>> PageA has a hyberlink to PageB, and one of pages is malicious webpage.
>>> If we take roles into consideration, there are two cases.
>>> 1. PageA  ---links to---> *PageB
>>> 2. *PageA ---links to---> PageB
>>> where "*" indicates the current or protected page, and another is the
>>> restricted page.
>>>
>>> As far as I know, referrer directive could be used to constrain the
>>> sources of current page in csp rules [
>>> https://w3c.github.io/webappsec/specs/CSP2/].
>>> However, It seems to be incapable of restricting the resources those
>>> will be linked to. That means csp can cover case 1 , but it can not cover
>>> case 2. (Am i right ?).
>>>
>>> Above all, there are 2 questions as follow:
>>> 1. Is there existing solution or working around solutions？
>>> 2. Is it possible to add directives for href to provide a easy way to
>>> constrain the resources that will be referred from the current protected
>>> page?
>>>
>>>
>>> It's my pleasure if I could get reply and make discussion on this topic!
>>>
>>> sincerely!
>>>
>>> Zhongxiao Yao
>>>
>>> China.
>>>
>>
>
>
> --
> Name: zhongxiao yao
> Email: zhongxiao.yzx@gmail.com
>
>
>


-- 
Name: zhongxiao yao
Email: zhongxiao.yzx@gmail.com