Permit blocking of certain hosts

[yoavweiss]

Use case

The site admin at AwesomeMedia™ started getting complaints about one of the site's many "second-hand" third parties. Reports say that it is behaving badly: delivering excessive amounts of data, slowing down the entire site, stealing private info or even (gasp) delivering malware to its users. However, AwesomeMedia™ doesn't include that content directly. Instead it is coming from thirdpartymanager.com, which was breached/tricked/bribed into letting this bad-behaving content through.
Obviously, our brave admin wants to stop sending this content to their users ASAP.

Today their options are fairly limited:
either remove thirdpartymanager.com entirely from the wide range of sites they manage (which would cost AwesomeMedia a lot of money until this is resolved), or call their contact on thirdpartymanager.com and yell at them until it is fixed (which can take a while as they may be sleeping, on vacation, or just slow to respond).

What our admin really wishes they had is a magical HTTP header that permits them to tell the browser "if you see requests for this host, block them immediately!". They could then add these headers to their responses, and kill the rogue third party, while letting through others.
That doesn't negate the need to have a tough conversation with thirdpartymanager.com, but that can happen after the users are safe.

Proposal

Current CSP syntax doesn't include a way to tell the browser to block a certain host while letting through all others. I believe it should.

I propose the addition of a new directive block which value is a source list, where all sources in that list would be blocked whenever an attempted request towards these sources is made.

/cc @mikewest

[mikewest]

A few things come to mind:

1. Wouldn't AwesomeMedia™ need to whitelist thirdpartymanager.com? Couldn't they just remove it from their whitelist rather than blacklisting it? Or are you assuming something like script-src https:; block thirdpartymanager.com?
2. Do the things you want to block occur in the context setting the policy, or in a nested context? My impression is that AwesomeMedia™ is generally going to load <script src="https://thirdpartymanager.com/loader.js">, which will frame https://stuff.thirdpartymanager.com/ which then loads All The Things. CSP wouldn't be effective against that style of embedding (except insofar as https://www.w3.org/TR/csp-embedded-enforcement/ might eventually get implemented).
3. Assuming reasonable answers to the above, wouldn't malicious usage just start at a.a.a.com and run through z.z.z.com? Domains are cheap, and blacklists don't seem like much more than a speed bump.

[yoavweiss]

Wouldn't AwesomeMedia™ need to whitelist thirdpartymanager.com? Couldn't they just remove it from their whitelist rather than blacklisting it? Or are you assuming something like script-src https:; block thirdpartymanager.com?

Yeah, I'm thinking of a scenario where AwesomeMedia has no particular CSP directives in place. So they would set something like script-src https:;block malicious_ads_are_us.com (they wouldn't block thirdpartymanager.com as that delivers many different ads, where most are not malicious or abusive).

Do the things you want to block occur in the context setting the policy, or in a nested context? My impression is that AwesomeMedia™ is generally going to load <script src="https://thirdpartymanager.com/loader.js">, which will frame https://stuff.thirdpartymanager.com/ which then loads All The Things. CSP wouldn't be effective against that style of embedding (except insofar as https://www.w3.org/TR/csp-embedded-enforcement/ might eventually get implemented).

They might occur in either. I don't think this should block on embedded enforcement but it would certainly help to be able to block malicious hosts both in the main context as well as embedded ones.

Assuming reasonable answers to the above, wouldn't malicious usage just start at a.a.a.com and run through z.z.z.com? Domains are cheap, and blacklists don't seem like much more than a speed bump.

I'm assuming it won't be trivial to do something like that in the context of ad exchanges/tag managers, and that if it is possible, that's a security hole that they should block.

[mikewest]

They might occur in either. I don't think this should block on embedded enforcement but it would certainly help to be able to block malicious hosts both in the main context as well as embedded ones.

Is malvertising the only use case here? Because I think that use case really would depend on embedded enforcement being deployed (and respected by the embedee). At least for DoubleClick, code generally runs one frame down from the top-level.

I'm assuming it won't be trivial to do something like that in the context of ad exchanges/tag managers, and that if it is possible, that's a security hole that they should block.

It doesn't seem hard? For example, I give thirdpartymanager.com a link to https://totallyawesome.com/yay.js, and then sneakily serve a 302 redirect to a.com.

[hillbrad]

Why is reporting the misbehaving site delivering malware to SafeBrowsing
and SmartScreen not the most appropriate course of action here?

On Mon, Jul 4, 2016 at 6:06 AM Mike West notifications@github.com wrote:

They might occur in either. I don't think this should block on embedded
enforcement but it would certainly help to be able to block malicious hosts
both in the main context as well as embedded ones.

Is malvertising the only use case here? Because I think that use case
really would depend on embedded enforcement being deployed (and respected
by the embedee). At least for DoubleClick, code generally runs one frame
down from the top-level.

I'm assuming it won't be trivial to do something like that in the context
of ad exchanges/tag managers, and that if it is possible, that's a security
hole that they should block.

It doesn't seem hard? For example, I give thirdpartymanager.com a link to
https://totallyawesome.com/yay.js, and then sneakily serve a 302 redirect
to a.com.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACFbcNjoyyKOk_XH7ZHZsk5XAwt0LNNQks5qSQVhgaJpZM4JETai
.

[dveditz]

Most ads seem to operate in nested iframes; are you proposing that this blocking behavior would affect content inside 3rd party frames? That would be dangerous. I understand your desire to do so in this hypothetical case, but it could also be used maliciously.

Sites need to negotiate with thirdpartymanger to create an API by which they can give a list of content they don't want thirdpartymanager to host on their site.

[yoavweiss]

Why is reporting the misbehaving site delivering malware to SafeBrowsing
and SmartScreen not the most appropriate course of action here?

For the malware case, that would be appropriate as a long term solution, but I'm not sure such reports have an immediate effect. Also, malware is the extreme case here, but I'm interested in blocking of 3rd party hosts also for performance reasons.

Most ads seem to operate in nested iframes; are you proposing that this blocking behavior would affect content inside 3rd party frames? That would be dangerous.

Can you elaborate on the danger with that approach?

[mikewest]

I'm inclined to wontfix this, as it would add (even) more complexity to the policy mechanism in general, and cuts against the general best-practice of enumerating the known-valid sources, as opposed to restricting the known-invalid sources.

It's also not clear to me that a one-off blockage is going to be an effective solution to the threat you present: assuming that a trusted source turns malicious, you'll be playing whack-a-mole as they iterate through bad1.site, bad2.site, bad3.site, and so on. Am I misinterpreting the way in which this would be used?

[andypaicu]

I also feel that a blacklist won't be appropriate for CSP.

1. The rest of CSP is designed to whitelist allowed resources not blacklist bad resource
2. As @mikewest mentioned above, a blacklist might not even be effective when considering how easy it is to change a host
3. The added complexity of a block mechanism is quite considerable as you have to make it granular, similar to the rest of CSP which would either require a new set of directives or a new keyword on each existing directive

Considering these points, I want to close this issue, any objections from anyone?

[yoavweiss]

No objections. Thanks for considering.