Add $csp modifier support

[ameshkov]

This modifier completely changes the rule behavior. If it is applied to a rule, it will not block the matching request. The response headers are going to be modified instead.

In order to use this type of rules, it is required to have the basic understanding of the Content Security Policy security layer.

For the requests matching a $csp rule, we will strengthen response's security policy by adding additional content security policy equal to the $csp modifier contents. csp rules are applied independently from any other type rule type. Other basic rules have no influence on it.

Multiple rules matching a single request
In case if multiple $csp rules match a single request, we will apply each of them.

csp syntax

csp value syntax is similar to the Content Security Policy header syntax.

csp value can be empty in the case of exception rules. See examples section for further information.

Limitations

1. Please note, that there're a few characters forbidden in the csp value: (,), ($)
2. csp rules support limited list of modifiers: domain, important, subdocument
3. Rules with report-* directives are considered invalid.

csp examples

• ||example.org^$csp=frame-src 'none' — prohibits all frames on example.org and it's subdomains.
• @@||example.org/page/*$csp=frame-src 'none' — disables all rules with csp modifier exactly matching frame-src 'none' on all the pages matching the rule pattern. For instance, the rule above.
• @@||example.org/page/*$csp — disables all the $csp rules on all the pages matching the rule pattern.
• ||example.org^$csp=script-src 'self' 'unsafe-eval' http: https: — disables inline scripts on all the pages matching the rule pattern.

[gorhill]

two characters must be escaped: comma (,) and ($)

As said, to simplify we can just forbid the use of , -- ; can be used to separate different policies in the same filter. Regarding $, I don't see why it needs escaping, I do not see it mentioned anywhere in the CSP standard.

[ameshkov]

@gorhill agreed, rephrased it. Regarding $, it can't be used in the CSP standard indeed, it's just would be better to make the syntax more bulletproof (for the case of possible future changes in the standard). I guess it makes sense to forbid both , and $ then.

[atropnikov]

@ameshkov Do I understand correctly, @@||example.org/page/*$csp=frame-src 'none' disables only the "first part" of the rule ||example.org^$csp=frame-src 'none'; connect-src http ?

[ameshkov]

@atropnikov

Do I understand correctly, @@||example.org/page/*$csp=frame-src 'none' disables only the "first part" of the rule ||example.org^$csp=frame-src 'none'; connect-src http ?

Nope, it disables all rules with the csp value exactly matching frame-src 'none'

I'll update the modifier description so that it was clear.

[ameshkov]

I guess $document rules should also disable $csp rules.

@@||example.org^$document disables all the $csp rules matching example.org

[gorhill]

Yes, whitelisting disable this, just like as any other blocking filters.

By the way, I mistakenly mentioned that third-party was supported, while its not. Currently I see that CSPs will always apply to just the main document (of the root frame, or embedded frames), thus this will always be first party.

[ameshkov]

Currently I see that CSPs will always apply to just the main document

Why not to the nested frames?

For instance, FB SDK communicates with its server through an iframe. You might want to keep FB API working, but block this communication.

I don't say it is a real-life example, but I suppose having such an option might come in handy sometimes.

[gorhill]

"Main document" as in "not secondary resources". I did mention "root frame, or embedded frames".

[ameshkov]

Sure, there's no point in applying csp to anything different from a document.

The point about third-party iframes still stands, though. Same goes for the domain modifier.

Here is one more real-life example. Remember that contentWindow.stop circumvention thing?

We have two options of blocking it (pseudo-code below).

1. Website specific: ||example.org^$csp=frame-src http://*/* https://*/*. We'll have to add a rule for every website affected.
2. General rule: ||xpanama.net^$third-party,csp=connect-src 'none',domain=~example.org

We sure can have the point 2 without third-party and domain modifiers, but it will make it hard to handle exceptions then.

[gorhill]

Personally I see csp= in the same realm as generichide or inline-script: I've never ever met a case where these needed to be evaluated against whether the document to which they apply is embedded or not. There is actually no code in uBO to test for "third-partyness" for these types.

The only time I see where third-party may become meaningful is if injecting CSP policies into script resources used for workers -- not sure in practice we will ever need to do this since we probably will want to block workers altogether rather than limit what they can do.

[ameshkov]

in the same realm as generichide or inline-script

inline-script will basically become a csp shortcut, isn't it?

The only time I see where third-party may become meaningful is if injecting CSP policies into script resources used for workers

What about domain=~example.org?

Let's just mention in the syntax description, that third-party must not be used with this modifier. AG will still silently support it (as for us it's easier to do than to stop supporting it).

If we stumble upon a case where third-party really makes any difference, we'll return to this discussion.

[gorhill]

What about domain=~example.org?

Yes, domain is supported.

[ameshkov]

@seanl-adg @Alex-302 guys, please take a look at this new feature.

[ameshkov]

@gorhill

Yes, domain is supported.

Ok, thank you! Added modifiers limitation description.

[gorhill]

Something I had thought about but it ended up slipping my mind, it's mentioned in ABP's issue tracker, this should be made into a rule for parsers: a parser must drop a csp= filter which contains a report-uri or report-to directive.

[ameshkov]

a parser must drop a csp= filter which contains a report-uri or report-to directive.

Indeed, added to the syntax description, thank you!