Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[4.0] Content Security Policy (CSP) Management Component #20686
Summary of Changes
Based on the work done by @yvesh at the JSST Sprint here is the initial version of the Content Security Policy (CSP) Management Component.
This component acts as an CSP Reporter endpoint for reports that csp rules create and allows us to make the creation of CSP rules even more easier within the UI.
What is the idea behind that?
Based on the idea by @SniperSister this component allows us to ship with some kind of
How it works
What is this PR about
This PR now implements the key part of the prozess the com_csp Component including the reporting endpoint. The other features are going to be added step by step.
Important: Please note that the mode selection and configuration is not finally implemented this is something that come with later PRs.
This is a new Feature
Documentation Changes Required
This is a new Feature Documentation is planed but not written yet.
This comment is not going to be popular but first some background. I have met Scott Helme a few times and heard him speak and I absolutely understand what CSP and http headers is all about. But i am not a typical user. CSP etc is a very complex issue that takes skill and knowledge to implement.I am 100% convinced that the Joomla target does not have that experience and that having com_csp is just opening a minefield of issues and making joomla appear to be too complicated.
Ask yourself this question - how many of you had even heard of CSP and http security headers before this PR. I bet very few and those of us reading this are more skilled than the typical user.
So what is the solution to that? If it was just a plugin then it would be like the p3p plugin - you either know what it is and use it or you simply ignore it. But the component raises its profile and introduces a very complex (and potentially dangerous) feature front and center.
In conclusion I am NOT in favour of this component being in core. At best it should be a core supported addon.
I agree that the majority of people will not recognise CSP aside from those who have more knowledge than normal. But I'm going to choose to overrule that based on three factors.
While I agree with Brian's concerns, there's a part of me that right now is thinking "just go for it" and let's have it as a feature through beta phase. Worst case scenario, some of the concerns about the usability and use in general are proved to be true and we move these tools to standalone packages, but at that point hopefully they're also in better shape as it relates to UX and workflow if there are issues needing addressed.
Ok just to clear some points.
Yes. It takes a bit of understanding but providing a tool that help with the Implemention is the intend of this PR and the following PR's also raising awarenes about that Technologie.
Where does that 100% convince come from?
This feature like multilanguage, redirect, overrides is implemented for the people that know what they are doing or at least read a bit of documentation (that is going to be published until 4.0 stable).
I think we all know that this does not make the whole process super easy for anyone like just one click but at least for the users who care about security or want to improve it at all they get a tool to do this kind of easy with the backend tooling that help with that.
Maybe but by that argument any new feature needs to be blocked as no one can have heard about it ;) Raising awareness is one more argument to implement it ;)
On what basis does the
Sure you can break your site if you do it wrong. But you can also unpublish all auth plugins or edit the template files and noone ever told in the PR it is
You know what happen with core supported addons in the past and you know why we stopped creating core supported addons. Also this would not allow the site owners to get know about this possible solution for the problems they are facing.
I'm not in favour adding default whitelists at all. With this tooling it is like recording a excel makro. You enable reporting all reports come in you enable the suggested rules done. Nothing complicated.
I guess this is about the new backend template? If so this is out of scope for this PR but I'm happy to help implement it for com_csp in a later PR.
This post explains what I meant about it being dangerous.
There is a massive difference between reading some docs about setting up redirects and successfully implementing CSP. There is no comparison to the level of skill and knowledge required.
I understand the concerns but after reading the linked article I've learned "Don't use it if you don't know what you are doing." and "Some outdated (unsecure?) browsers may not understand CSP."
On the other hand users can activate "Force SSL" in Joomla and as I know from forums and jobs bring freequently down their sites completely or partially (unsecure content).
Security settings (= blocking this or that) combined with half knowledge will always be double-edged swords.
From my point of view com_csp is a helpful extension and as far as I can see at the moment a well configurable extension where I haven't got anything against seeing it in core.
Maybe we should integrate a consent box in com_csp before users can use ist ;-) (just joking)
Jun 20, 2018
Just wondering how you would feel when the core introduces a new feature which replaces part of your business. Sorry but this is not an argument to add new features to the core.
Don't get me wrong, I think this is a great addon for J4, but we have an eco system to take care of too.
Not sure what you exactly mean. But do you don't agree that the eco system with the extension is a important part of Joomla?
It is all how much research was done upfront if there is no extension which solves that use case. If there is one, then I don't see the point to add it to the core.
I'm all in that the core can trace security issues and visually display them. The problem I have is that we have to be very sensitive what will be added to the core and in which way. But more importantly is how we communicate it to the community, especially from the leadership.
Of course it is! Never wanted to question the importance of the ecosystem. But I guess we all agree that it’s not just Joomla needing a healthy ecosystem but also the ecosystem needing a healthy Joomla, so if there is a potential feature that gives us a competitive advantage (and being the first major webapp with CSP surely is one of these advantages and sends the message of Joomla taking security seriously) we should use it and bring it into core.
Yes, at the end of the day we always need to be careful and ask ourselves what belongs into core and what doesn’t. In this case I’m clearly in favor of adding it because it’s a potential fix for one of our main security issues: XSS. Joomla has a general architecture problem (using PHP as a templating engine) that can’t be easily overcome (switch to a templating language) without killing the ecosystem.
That's why I said that I like it and it's a good thing to improve security. Just comments like "Well, it’s a paid extension for Joomla 3, not quite sure how this can be compared with a free core feature for J4." can be misunderstood by the extension devs. Just wanted to raise awareness what we say where. Anyway, didn't want to make a long story out of it. Pr is merged and all is good.
As a response to @stutteringp0et:
So arguing here why core is implementing CSP when there are 3rd party solutions (introduced after the RFC) is not fair at all. The production team responded publicly on that RFC, and many contributors offered their time to implement this which also makes your comment totally unfair for them.
Also bear in mind that people who base their income on Joomla tend to give back some code as an appreciation, namely @laoneo gave custom fields, @nikosdion gave back the 2FA, the update script, fof and numerous more stuff. This is how an open source product like joomla can thrive by giving back and definitely not by holding progress back...