-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Conversation
… 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.
Thanks - I am optimizing this a bit and will update. |
@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. |
Thank you, it looks to be working fine on my end I'm curious why |
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. |
Ok, thanks for the explanation. |
Now it is triggering eval CSP because of I actually was using If you want to fix plugin templates I think this is not the place. |
I am using this on my project Content-Security-Policy
I am not using unsafe-eval and i have no CSP errors (on Firefox), could you provide an example ? Could you elaborate ? BTW this was not merge, but these commits are handling CSP |
I created an issue #1612 with more details. There is also an example. Please see MDN documentation about I came to this issue because my problem was introduced in aa99882 and it look like here is the source for the change. |
Ok I can understand this now. I will try to work on something when I have some time. |
I would propose to remove the |
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. |
Scope
This pull request includes a
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