In light of the recent
plone4.csrffixes security fix, I’d like to share some of our experiences in debugging and fixing CSRF protection false positives. Because
plone.protects approach for automatic CSRF protection is pretty comprehensive (which is good), it can result in cases where there’s false positives – a dialog that is shown to the user asking them to confirm their intent (to prevent the request forgery), even though no actual CSRF attack has occurred.
We’ve been using the automatic CSRF protection from
plone.protect 3.x with Plone 4 for a little more than half a year now, before it was officially supported. We therefore hit quite a few situations where we had to debug false positives caused by a write-on-read, both the ones in stock Plone 4 (which now have been addressed), and ones caused in our own add-ons.
Particularly because of the recently introduced
HTTP_REFERER check you should rarely ever hit those false positives any more, but if you do, here’s some techniques for debugging and fixing them.
How plone.protect’s auto CSRF protection works
CSRF protection (automatic or manual) in Plone is done via
plone.protect. Plone 4 used to pin
plone.protect == 2.x, which put a basic framework for manual CSRF protection in place.
plone.protect >= 3.0, which was targeted at Plone 5, then introduced automatic CSRF protection.