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

[4.0] Content Security Policy (CSP) Management Component #20686

Merged
merged 48 commits into from Jun 20, 2018

Conversation

@zero-24
Copy link
Contributor

zero-24 commented Jun 7, 2018

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 detecting mode for CSP rules in Joomla 4.0. (As announced in the community magazine report of the JSST sprint after JAB18)

How it works

  • you are going to enable the csp detecting mode.
  • in the background the httpheaders plugin sets the headers in report only mode and points all reports to the com_csp endpoint
  • Now you navigate the webseite
  • All reports that come up will be saved in the database
  • Now you can go to the com_csp backed component and review the reports mark them as valid.
  • Now you are going to switch the mode back to automatic
  • The plugin now enforce the rules and just allow the urls you have whitelisted in com_csp
  • In case you find another page that is broken or something that went wrong you can enable the dectect mode again and collect the missing urls
  • disable the detect mode & enabled the new urls
  • and the page should work again.

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.

Testing Instructions

  • install this branch as new install

  • go to the options of com_csp and enable the Enable frontend reporter option.
    image

  • switch to the HTTP Headers Plugin in the plugin manager and configure the following rules:
    image

  • report-uri URL for c&p: index.php?option=com_csp&task=report.log

  • now navigate the frontend

Expected result

  • As you can see in the developer console of the browser your site is now generating reports this reports are sendet to the component.
  • After navigating around please switch back to the com_csp backend component
  • You should now see all the reports that we got in our database.
  • now you can also enable and disable the reported urls

image

Important: Please note that the mode selection and configuration is not finally implemented this is something that come with later PRs.

Actual result

This is a new Feature

Documentation Changes Required

This is a new Feature Documentation is planed but not written yet.

Yves Hoppe and others added some commits May 14, 2018

<field
name="enable_reporter"
type="radio"
class="switcher"

This comment has been minimized.

@brianteeman

brianteeman Jun 7, 2018

Contributor

code style is
name
type
label
description
anything else

@joomla-cms-bot joomla-cms-bot added the RTC label Jun 18, 2018

@zero-24 zero-24 added this to the Joomla 4.0 milestone Jun 18, 2018

@zero-24

This comment has been minimized.

Copy link
Contributor

zero-24 commented Jun 18, 2018

It is your turn now @wilsonge :P Thanks for all the feedback I got here. Very highly appreciated 👍

@brianteeman

This comment has been minimized.

Copy link
Contributor

brianteeman commented Jun 19, 2018

@zero-24 i am checking those strings for you now

@brianteeman

This comment has been minimized.

Copy link
Contributor

brianteeman commented Jun 19, 2018

@zero-24

This comment has been minimized.

Copy link
Contributor

zero-24 commented Jun 19, 2018

Thanks @brianteeman I have just responded to the suggestions all other changes looks good to me Thanks! 👍

@brianteeman

This comment has been minimized.

Copy link
Contributor

brianteeman commented Jun 19, 2018

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.

@wilsonge

This comment has been minimized.

Copy link
Contributor

wilsonge commented Jun 19, 2018

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.

  1. Firstly we're making a conscious effort to overcome the community reputation we hold in some areas about us not being as security conscious as other CMS'. This component shows us putting security first
  2. I expect the default parameters here to change quite a bit before stable. I expect by default we will whitelist google fonts, google analytics + adwords, and some of the major CDNs as well as local CSS (without a nonce). It's not necessarily the most secure set of settings - but it should allow the majority of sites to work give or take out of the box without major reconfiguration.
  3. The design rework is going to give us a separated dashboard and set of components. There is now a more conscious separation between administration components and day to day content components with the split of dashboards. Not all administrators are actually going to be totally aware of this extension.
@mbabker

This comment has been minimized.

Copy link
Member

mbabker commented Jun 20, 2018

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.

@zero-24

This comment has been minimized.

Copy link
Contributor

zero-24 commented Jun 20, 2018

Ok just to clear some points.

re @brianteeman

CSP etc is a very complex issue that takes skill and knowledge to implement.

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.

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.

Where does that 100% convince come from?
This feature was never intended for the people that don't know what html is. It is also not intended for that users who think the JSST (Or Joomla at all) has access to the admin PW's..

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.

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.

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 ;)

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.

On what basis does the very complex and potentially dangerous definitions come from?

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 to complex or potentially dangerous because if you don't understand it or you will not understand it you don't use it :)

At best it should be a core supported addon.

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.

re @wilsonge

Firstly we're making a conscious effort to overcome the community reputation we hold in some areas about us not being as security conscious as other CMS'. This component shows us putting security first

Full agree.

I expect the default parameters here to change quite a bit before stable. I expect by default we will whitelist google fonts, google analytics + adwords, and some of the major CDNs as well as local CSS (without a nonce). It's not necessarily the most secure set of settings - but it should allow the majority of sites to work give or take out of the box without major reconfiguration.

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.
Also CSP is not going to be enabled by default. Everyone should make an informed decision about enableling that feature.

The design rework is going to give us a separated dashboard and set of components. There is now a more conscious separation between administration components and day to day content components with the split of dashboards. Not all administrators are actually going to be totally aware of this extension.

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.

@brianteeman

This comment has been minimized.

Copy link
Contributor

brianteeman commented Jun 20, 2018

This post explains what I meant about it being dangerous.
https://www.tunetheweb.com/blog/dangerous-web-security-features/

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.

@ReLater

This comment has been minimized.

Copy link
Contributor

ReLater commented Jun 20, 2018

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).
Others check "Activate HSTS" in their SSL provider settings because it's "more performant and more secure" and don't think about the risks concerning cache in user browsers that possibly may occur.

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)

zero-24 added some commits Jun 20, 2018

@wilsonge wilsonge merged commit c5d269c into joomla:4.0-dev Jun 20, 2018

3 of 4 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
Hound No violations found. Woof!
continuous-integration/drone/pr the build was successful
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@joomla-cms-bot joomla-cms-bot removed the RTC label Jun 20, 2018

@zero-24 zero-24 deleted the zero-24:cspj4 branch Jun 20, 2018

@zero-24

This comment has been minimized.

Copy link
Contributor

zero-24 commented Jun 20, 2018

Thanks for all the feedback and help 👍 I now start implementing the integration part.

@stutteringp0et

This comment has been minimized.

Copy link
Contributor

stutteringp0et commented Jun 20, 2018

This functionality has been available as a 3rd party plugin for many months.

JED: System - Content Security Policy

@SniperSister

This comment has been minimized.

Copy link
Contributor

SniperSister commented Jun 20, 2018

Well, it’s a paid extension for Joomla 3, not quite sure how this can be compared with a free core feature for J4.

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jun 21, 2018

Well, it’s a paid extension for Joomla 3, not quite sure how this can be compared with a free core feature for J4.

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.

@SniperSister

This comment has been minimized.

Copy link
Contributor

SniperSister commented Jun 21, 2018

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.

I get your point - but how can one solve this? Not adding such a feature isn’t an option either, right?

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jun 21, 2018

but how can one solve this?

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?

Not adding such a feature isn’t an option either, right?

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.

@brianteeman

This comment has been minimized.

Copy link
Contributor

brianteeman commented Jun 21, 2018

there are multiple commercial gdpr extensions on the jed as well

@SniperSister

This comment has been minimized.

Copy link
Contributor

SniperSister commented Jun 21, 2018

But do you don't agree that the eco system with the extension is a important part of Joomla?

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.

@laoneo

This comment has been minimized.

Copy link
Member

laoneo commented Jun 21, 2018

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.

@dgrammatiko

This comment has been minimized.

Copy link
Contributor

dgrammatiko commented Jun 21, 2018

As a response to @stutteringp0et:
your plugin was published on April 2018
screen shot 2018-06-21 at 12 35 28

The decision on implementing CSP in core was done over a year before you released that plugin: #14246
and the first part was also merged in core over 3 months before you released your plugin: #18301

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

@wilsonge

This comment has been minimized.

Copy link
Contributor

wilsonge commented Jun 21, 2018

Guys please leave it alone here. People have made their points. Locking this topic

@joomla joomla locked as too heated and limited conversation to collaborators Jun 21, 2018

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