New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add $csp modifier support #685

Closed
ameshkov opened this Issue May 12, 2017 · 16 comments

Comments

Projects
None yet
3 participants
@ameshkov
Member

ameshkov commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill May 12, 2017

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.

gorhill commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 12, 2017

Member

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

Member

ameshkov commented May 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@atropnikov

atropnikov May 12, 2017

Member

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

Member

atropnikov commented May 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 12, 2017

Member

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

Member

ameshkov commented May 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 15, 2017

Member

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

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

Member

ameshkov commented May 15, 2017

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

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

@gorhill

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill May 15, 2017

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.

gorhill commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 15, 2017

Member

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.

Member

ameshkov commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill May 15, 2017

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

gorhill commented May 15, 2017

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

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 15, 2017

Member

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.

Member

ameshkov commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill May 15, 2017

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.

gorhill commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 15, 2017

Member

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.

Member

ameshkov commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill May 15, 2017

What about domain=~example.org?

Yes, domain is supported.

gorhill commented May 15, 2017

What about domain=~example.org?

Yes, domain is supported.

atropnikov added a commit that referenced this issue May 15, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 16, 2017

Member

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

Member

ameshkov commented May 16, 2017

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

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 16, 2017

Member

@gorhill

Yes, domain is supported.

Ok, thank you! Added modifiers limitation description.

Member

ameshkov commented May 16, 2017

@gorhill

Yes, domain is supported.

Ok, thank you! Added modifiers limitation description.

@gorhill

This comment has been minimized.

Show comment
Hide comment
@gorhill

gorhill May 16, 2017

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.

gorhill commented May 16, 2017

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.

atropnikov added a commit that referenced this issue May 17, 2017

atropnikov added a commit that referenced this issue May 22, 2017

atropnikov added a commit that referenced this issue May 22, 2017

@ameshkov

This comment has been minimized.

Show comment
Hide comment
@ameshkov

ameshkov May 23, 2017

Member

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

Indeed, added to the syntax description, thank you!

Member

ameshkov commented May 23, 2017

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

Indeed, added to the syntax description, thank you!

atropnikov added a commit that referenced this issue May 23, 2017

#685
Forbidden CSP directives.

atropnikov added a commit that referenced this issue May 23, 2017

#685
Fixes;

atropnikov added a commit that referenced this issue May 24, 2017

#685
Fixes;

@ameshkov ameshkov closed this Aug 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment