Skip to content
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

Fix #1565: CSP compliance with plugin templates (don't trigger inline JS and CSS rules) #1571

Closed
wants to merge 1 commit into from

Conversation

Kwaadpepper
Copy link
Contributor

@Kwaadpepper Kwaadpepper commented May 30, 2020

Scope

This pull request includes a

  • Bug fix
  • New feature
  • Translation

Changes

The following changes were made

  • add uniqId method, generates unid ID hash (base 36) using random and DateTime (to avoid collisions)

  • add parseEvent method, is an alternative to the evil Eval function, is used to "eval" inline events of templates

  • add cspBuffer "class"
    It will store attributes to prevent Dom from parsing them and triggering CSP policies
    It contains 2 methods:
    - parse, will store inline CSS and inline JS events to apply them later using CSSOM and JS event bind
    - apply, will apply inline CSS and inline JS stored previously
    To find where to apply things, it uses the temp attribute "cspTMP" containing a unique ID.

    Please note that I found not found a reliable way to get a list of supported events,
    So i compiled some commons events in domEventsList. This should be enough i think.
    Since inline event are deprecated for a long time now. There is no need for more I think.

    This is more like a patch to fix conceptions flaws.

Please note that as said here #1565 (comment) some info could be added to the documentation.

Related Issues

If this is related to an existing ticket, include a link to it as well.
#1565
https://bugzilla.mozilla.org/show_bug.cgi?id=1582115

… JS and CSS rules)

- add uniqId method, generates unid ID hash (base 36) using random and DateTime (to avoid collisions)
- add parseEvent method, is an alternative to the evil Eval function, is used to "eval" inline events of templates
- add cspBuffer "class"
    It will store attributes to prevent Dom from parsing them and triggering CSP policies
    It contains 2 methods:
      - parse, will store inline CSS and inline JS events to apply them later using CSSOM and JS event bind
      - apply, will apply inline CSS and inline JS stored previously
    To find where to apply things, it uses the temp attribute "cspTMP" containing a unique ID.

  Please note that I found not found a reliable way to get a list of supported events,
  So i compiled some commons events in domEventsList. This should be enough i think.
  Since inline event are deprecated for a long time now. There is no need for more I think.

  This is more like a patch to fix conceptions flaws.
@kartik-v
Copy link
Owner

Thanks - I am optimizing this a bit and will update.

@kartik-v
Copy link
Owner

@Kwaadpepper thanks - have enhanced your PR and fixed a bit of minor issues in the inline event parsing and added a few function utilities for easier use. Please have a relook if anything amiss in your tests and let know.

@Kwaadpepper
Copy link
Contributor Author

Thank you, it looks to be working fine on my end

I'm curious why CSP_ATTRIB: 'data-csp-01928735' ? If you wanted to randomize the attr name you could you uniqId function ? I am also curious, why should this attribute name be randomized ?

@Kwaadpepper Kwaadpepper deleted the fix-csp branch May 31, 2020 14:23
@kartik-v
Copy link
Owner

kartik-v commented May 31, 2020

Thank you, it looks to be working fine on my end

I'm curious why CSP_ATTRIB: 'data-csp-01928735' ? If you wanted to randomize the attr name you could you uniqId function ? I am also curious, why should this attribute name be randomized ?

Just to ensure we do not have a similar naming attribute conflict being injected by the developer as part of his/her code. Its a constant attribute name but named such that it is highly unlikely to conflict.

Note that the developers have flexibility in the plugin to define their own HTML templates and they may be injecting their own data attributes and we do not want that to conflict with this.

@Kwaadpepper
Copy link
Contributor Author

Ok, thanks for the explanation.

@kw-pr
Copy link

kw-pr commented Jul 31, 2020

Now it is triggering eval CSP because of Function().
I am afraid this made things worse.

I actually was using script-src 'self'; before this patch and it was working.

If you want to fix plugin templates I think this is not the place.
You should fix the plugin or use unsafe-hashes as a workaround.

@Kwaadpepper
Copy link
Contributor Author

Kwaadpepper commented Jul 31, 2020

I am using this on my project

Content-Security-Policy

default-src  'self' data: blob: 'nonce-Uv96RimOSuoCMSJU'
script-src  resource://pdf.js/ 'nonce-Uv96RimOSuoCMSJU'
style-src 'self'  'nonce-Uv96RimOSuoCMSJU'
frame-src 'self' https://docs.google.com
object-src 'self' blob:; base-uri 'self' resource://pdf.js/web/
media-src 'self' blob:; report-uri /omenfilemanager/csp/report

I am not using unsafe-eval and i have no CSP errors (on Firefox), could you provide an example ?
I do not understand why Function() would trigger unsafe-eval rule.

Could you elaborate ?

BTW this was not merge, but these commits are handling CSP
aa99882
83ae330

@kw-pr
Copy link

kw-pr commented Jul 31, 2020

I created an issue #1612 with more details. There is also an example.

Please see MDN documentation about unsafe-eval und Function().

I came to this issue because my problem was introduced in aa99882 and it look like here is the source for the change.

@Kwaadpepper
Copy link
Contributor Author

Ok I can understand this now. I will try to work on something when I have some time.

@kw-pr
Copy link

kw-pr commented Jul 31, 2020

I would propose to remove the domElementEvents part of aa99882. domElementsStyles looks fine to me.

@Kwaadpepper
Copy link
Contributor Author

Kwaadpepper commented Jul 31, 2020

I think you may be right. I can't think of a workaround. And if there were one it would be a security hole in the CSP system.

You could propose a PR if you have time.

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

Successfully merging this pull request may close these issues.

3 participants