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?
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 packageplone.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.
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.
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 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).
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:
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 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 https://github.com/plone/ploneorg.core/issues we can try to get to it. We'd rather maintain Links on Plone.org than rewrite rules.