W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2015

Re: [CSP2] How to restrict resources linking to

From: yao zhongxiao <zhongxiao.yzx@gmail.com>
Date: Wed, 2 Sep 2015 11:59:38 +0800
Message-ID: <CAHKtDqdxzpXLZjKUX4KBSCEq=7pmEUJ23ocS=xDswopNntQqrQ@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: public-webappsec@w3.org, Mike West <mkwst@google.com>, w3c@adambarth.com, dveditz@mozilla.com
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
Received on Wednesday, 2 September 2015 04:00:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:15 UTC