We agreed that the best way forward might be:
To work with developing this extension.
To make CSRF a service registered in the container, and fix a contract/interface for its use which is flexible. e.g.
$params may contain the following keys - all optional:
validFrom: time() + 15, // 15 seconds from now validTo: time() + 300, // 5 mins from now secret: 'blah', // included in the hash; not visible in the token public: 'donation', // included in the hash; visible in the token
$csrfService->checkCSRF($inputToken, $params=) where
$params keys may contain
public as above.
That we should introduce a generic firewall Symfony event (
civi.firewall ?) which at least has a string
type property. Core and extensions are free to invent and use their own type strings, and should also contain a
context property which should be an array of anything that might be useful to store about that event. It is suggested that the following types be used:
csrf_invalid(context may contain more reasons like expired/missing/etc.)
invalid_input(normal validation errors)
suspicious_input(input is invalid in a way a normal user would not be expected to achieve, e.g. data in honeypot field, or a known pattern of data input is identified - we could think about a service to check input in this way via a hook/event)
successful_sumission(of a form)
rejection(something in this request has triggered an IP ban)
denied(submission received from a blocked user/IP)
That this and other such extensions can listen to events and take action as they so wish, based on configuration. An idea for this is detailed at https://lab.civicrm.org/snippets/37
That a central service (@artfulrobot interested in providing this) specifically for CiviCRM users could be used to periodically fetch a list of dodgy IP addresses that CiviCRM sites have blocked - sites would report to this service when they blocked an IP, too. The need for a CiviCRM service like this exists, we felt, because we all use the same software and so are vulnerable as a class attack. But views welcome about existing services that could do us just as well.
Side-note on language: Let's use block list and safe list, rather than blacklist and whitelist. There's far too much clumsy language around in software which equates black with bad and white with good (master/slave comes to mind too) and at a time where white supremacy is on the rise we should resist anything that could imply complicity.