Re: [CSP2] How to restrict resources linking to

You might be interested in http://www.w3.org/TR/epr/ and an upcoming draft
for Confinement with Web Origin Labels (COWL) shortly to be published.

On Wed, Sep 2, 2015 at 5:05 AM yao zhongxiao <zhongxiao.yzx@gmail.com>
wrote:

> 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
>