firewall issueshttps://lab.civicrm.org/extensions/firewall/-/issues2023-04-12T11:03:36Zhttps://lab.civicrm.org/extensions/firewall/-/issues/22Configurable rates/limits2023-04-12T11:03:36ZcantrellnmConfigurable rates/limitsI know this is already in the list of future development/ideas, but I'd like to encourage a change to make the fraud/invalid CSRF event limits (currently 5) and 2 hour interval configurable. We had a card testing incident over the past c...I know this is already in the list of future development/ideas, but I'd like to encourage a change to make the fraud/invalid CSRF event limits (currently 5) and 2 hour interval configurable. We had a card testing incident over the past couple days (with Firewall enabled) that was brought to my attention after payments on our Stripe account were temporarily blocked.
Out of 729 events logged in the `civicrm_firewall_ipaddress` table there were 649 unique IP addresses, so we're not getting anywhere close to the 5 events that would block them in time to prevent trouble. I'd like to be able to block them sooner, after 1 or 2 events, and to make that period longer than 2 hours. (I'll be lowering the CSRF timeout from the default 12 hours, 141 of those events were invalid CSRF events.)
It would also be nice to be able to block payments of $1 from Civi without upgrading to Stipe's "Radar for Fraud Teams" to add a custom rule there, but I understand that's probably beyond the scope of this issue.https://lab.civicrm.org/extensions/firewall/-/issues/1Improvement ideas2023-04-12T11:02:57ZRichImprovement ideasThis follows on from <https://lab.civicrm.org/snippets/37> and a brief conversation between @mattwire and @artfulrobot at CiviCamp Birmingham.
We agreed that the best way forward might be:
To work with developing this extension.
To ma...This follows on from <https://lab.civicrm.org/snippets/37> and a brief conversation between @mattwire and @artfulrobot at CiviCamp Birmingham.
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. `$csrfService->getCSRF($params=[])` where `$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
```
And `$csrfService->checkCSRF($inputToken, $params=[])` where `$params` keys may contain `secret` and `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.RichRichhttps://lab.civicrm.org/extensions/firewall/-/issues/25Proposal: hook on block2022-12-09T14:57:48ZJKingsnorthProposal: hook on blockProposal is to add a hook when the firewall blocks a request.
This would allow other extensions to be notified on a block event, and do custom logic/logging/notifications.
---
An alternative we considered was to add the hook to should...Proposal is to add a hook when the firewall blocks a request.
This would allow other extensions to be notified on a block event, and do custom logic/logging/notifications.
---
An alternative we considered was to add the hook to shouldThisRequestBeBlocked, to allow the $block to also be altered. However, we decided against this because:
- It would be better to implement custom blocking rules using a more robust mechanism, eg: extending a base event class provided by the firewall extension (#22), rather than via hooks
- It would run on every page load, although the impact would probably be negligible1.5JKingsnorthJKingsnorth