View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009949 | Taler | merchant backend | public | 2025-05-13 11:36 | 2025-06-12 14:26 |
| Reporter | oec | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Product Version | 1.0 | ||||
| Target Version | post-1.0 | ||||
| Summary | 0009949: Add control to exclude domains and IP-ranges for webhooks | ||||
| Description | In a multi-tenant setup of the merchant backend, which will be hosted on the infrastructure of the merchant-backend-service-provider (provider) on behalf of the tenants/merchants, allowing arbitrary URL's in the webhooks provided by individual merchants might pose a risk to the infrastructure of the provider: In a typical setup, a reverse-proxy will most likely be in charge to control web-traffic from the internet into the backend, but probably no such control will be in place for the traffic generated _internal_ via the taler-merchant-webhook service. Any webhook of any merchant can generate traffic to any IP-address, even internally. Now, in a single-tenant-scenario, this might be a very well needed functionality for the merchant (who is then his own backend provider), in order to communicate to internal ERP systems. However, in a multi-tenant system, that might or might not be the case. If not, allowing arbitrary _internal_ traffic generated by some _external_ entity poses a risk to the multi-tenant-service-provider. F.e., if that setup is configured to rely on `external` authentication (see https://docs.taler.net/core/api-merchant.html#authentication), a merchant instance could potentially alter other instances via internal CRUD calls to the management API. Therefore, we propose to introduce configuration parameters to the merchant-setup by which the merchant-backend-service-provider can include and _exclude_ IP-ranges and/or domain-names for the webhooks set by individual merchants. These COULD be in effect when a webhook created and potentially rejected by the backend, but also MUST be in effect when a webhook is to be executed, in order to accommodate changes in the configuration. This is a defence-in-depth measure. | ||||
| Tags | security | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-05-13 11:36 | oec | New Issue | |
| 2025-05-13 12:10 | oec | Description Updated | |
| 2025-05-13 12:41 | oec | Description Updated | |
| 2025-05-13 14:40 | Christian Grothoff | Status | new => acknowledged |
| 2025-06-12 14:26 | Christian Grothoff | Tag Attached: security |
