We have been using Plone 4.3 with plone.protect 3.x for quite some time, but latest Plone releases, specifically 4.3.17 and 4.3.18, are giving us some headaches as automatic CSRF protection is being fired on unexpected places like workflow transitions and portlets management.
what would be the recommended approach on this? downgrade to plone.protect 2.x?
at least, that's was my conclusion after reading hotfix 20151006 release notes.
For me, the hotfix release notes are not clear enough. I tend to slightly favour the interpretation that there are two ways to get the protection: either use Plone 4.3.9 (or above) AND pin plone.protect to a 3.x version or (leave plone.protect alone and) use the package plone.csrffixespackages. The other interpetation is that aplone.protect3.x version is necessary to get the specific hotfix protection, but in some cases,plone.csrffixes` is necessary in addition.
It seems to me that the release notes stipulate that in some cases, installing plone.csrffixes can avoid some Unauthorized errors (mentioned for Javascript requests). Maybe, this also solves your problems?
no; if I understood correctly, you only need plone4.csrffixes if you're using Plone < 4.3.9 (yes, it says fixes are partially included and that's why I'm asking).
if you use plone.protect >= 3.0 then you add automatic CSRF protection but that must be painful as we're experiencing it right now.
so, the question could be: are all fixes included in plone4.csrffixes already included into Plone 4.3.18?
If you want the hotfix protection on Plone 4.3, you will always have to include plone4.csrffixes. This is too invasive to ever get merged in the core Plone 4.3 code. Especially, too many tests would fail. Should be fixable, but it would mean a lot of effort. It is not going to happen. If you want this protection in Plone core, you must use Plone 5.
plone4.csrffixes requires plone.protect version 3, so you need that package as well.
Technically, you only need plone.protect 3, but then without plone4.csrffixes you will get far too many false positives. plone4.csrffixes basically only fixes the most common false positives, where plone.protect 3 would complain for no good reason.
For example, if a visitor sees a page with an image that needs a scale that has not been rendered yet, plone.protect 3 would complain because this means a database write on a GET request. plone4.csrffixes makes sure it does not complain.
I myself am using both packages for one or two clients. For the others we have patched the worst problems by setting up nginx/Apache to disallow access to ZMI pages (manage and manage_*), which is the documented workaround. This workaround is less good, but should be good enough in most cases.
Note: I am a member of the Plone Security Team, but I was not a member at the time that this hotfix was created.
thanks! I think the documentation needs to be fixed then in 2 places:
based on what you're saying I'm going to re-add the following to our buildouts:
I'll come back in case if I get more issues.
The hotfixes landing page mentions the 20151006 fix for all 4.3 versions. What may throw you off, is that 4.3.9 is the top version mentioned, but that is because the Plone versions are unfortunately sorted alphabetically, which means that 4.3.10 is sorted after 4.3.2.
The individual hotfix page says to apply plone.protect 3.0.18. (This should be .27, but it is hard to remember to update this page when making a release.) And then it says "But with this version you may still notice Unauthorized errors in some javascript requests, especially when using the TinyMCE visual editor. This means you still need to add plone4.csrffixes after all." So that information is there.
The details page is the only one to mention the apache/nginx rules: "While you are working out the patch’s effect on your site, we strongly recommend you implement the above Nginx and Apache block rules."
The information is there, but I had difficulties to understand the description in the release notes - especially the interaction of plone.protect version 3,plone4.csrffixes and Plone version 4.3.9 and above. Your comment 4 in this discussion clarifies the description and should be incorporated into it (probably rewriting a part thereof).
I have updated https://plone.org/security/hotfix/20151006, also with newer versions. Can you check if that is better?
awesome, there are still some issue: the most important to me is this page not listing al Plone 4.3 versions and not listing the patch as needed; that was the main reason I removed it in the first place:
https://plone.org/security/hotfixes
as you can see, Plone 4.3.17 don't mentions this and Plone 4.3.18 is not even listed.
the nginx rule has a small typo; it should be like this (note the \ char):
location ~ \/manage(_(?!translations).+)?$ {
deny all;
}
and now we're talking, can someone (@tkimnguyen?) just remove this useless page please?
I see many Plone 4.3 versions listed there from 4.3 all the way to 4.3.17... only 4.3.13 and 4.3.16 are not listed, presumably because they were never actually released (probably true of 4.3.18 too). So is there really a reason to remove that page?
There is an add-on to Plone.org that was produced for GSoC 2017 that I'd like to see installed, for security fix and release listing. (If I have time, I plan on installing the other part of it at least, that lists Plone add-ons).
you're not reading carefully, my friend; I'll try to be more clear:
Plone 4.3.17 states that NO hotfix is needed, that's FALSE; Plone 4.3.18 is NOT listed at all and, yes, it was released some time ago (the exact date is unknown because someone decided the byline was not a useful feature for a CMS).
I'm not asking to remove the Security page (https://plone.org/security/hotfixes), but to remove the Available hotfixes page (https://plone.org/security/available-hotfixes), which maybe the useless page of the whole site (it only contains a link to the Security page).
there are 2 options for that: avoid showing the link and just do the redirect for anonymous users, or just remove the link and add a plone.app.redirect alias to the security page.
let me know if you need more information.
Oops. I fixed that now.
Can someone add that? (no time left)
Done.
I also added 5.1.2 to the releases. That one needs no hotfixes.
(Reminder to self for future reference: go to the portal_registry controlpanel and add a new release to plone.releases, plone.securitysupport and plone.activemaintenance.)
thanks! now everything is clear.
Thanks Maurits! I had just come back to slap...uh, reply to Hector that those pages are really just showing data entered elsewhere on the site. You just saved him from a big juicy trout sla...reply!
Is this info something we could add to the edit form or a portlet visible only to those with edit access? (I haven't looked at how it's implemented)
Indeed, I don't know why the byline doesn't show on the news item itself, but it does show in its containing folder view News for 2018
I think I created that Link because it was being referenced somewhere (old Plone.org?). And yes I noticed that the Link wasn't redirecting right away and tried to poke at the setting to make it do so but had no luck with it and ran out of time. Let's just say that the migration to the current Plone.org was not as easy as might appear at first glance... it was upgraded all the way from pre 1.0 to 5.1b something I think, what you might call a very organic process that has cruft still stuck between its teeth. Which is a long way of saying, sorry it's not perfect, but if someone files an issue at Issues · plone/ploneorg.core · GitHub we can try to get to it. We'd rather maintain Links on Plone.org than rewrite rules.
WHAT?! after all this years using Plone you don't know about the Redirection Tool? you're kidding me!
there's even a PLIP to merge that on the core.
you deserve it!
If it ain't merged, I dunno about it!
By the way, the number of people who have been working on the Plone.org server in recent years is... 2, so stop giving me grief...