View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005121 | Composr | core | public | 2022-12-03 00:57 | 2022-12-27 15:11 |
| Reporter | Chris Graham | Assigned To | |||
| Severity | Feature-request | ||||
| Status | non-assigned | Resolution | open | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0005121: More granularity for trusted site lists (CSP) | ||||
| Description | There are config options for trusting sites, and a hook system for injecting trusted sites also. Composr then uses these, alongside some config settings, to built out a CSP policy. This provides a lot of protection to Composr from XSS, CSRF, or other types of nasty injection vulnerability. It would be better through if the trusted sites could be defined as to what specifically they are to be trusted for. This serves two purposes: 1) Philosophy of minimum privilege. If we need to trust a site for posting a form to it, we shouldn't need to also trust running JS from there too. 2) Smaller CSP headers, as less is being "copy and pasted" across the different CSP categories. Large response headers may result in HTTP proxies blocking pages. Instead of just listing trust domains, we could optionally list them with more context, e.g. paypal[form-action] authorize[form-action,script-src,style-src] Also we could limit stuff to particular match-keys, e.g.: paypal[form-action]{_WILD:purchase,_WILD:shopping} authorize[form-action,script-src,style-src]{_WILD:purchase,_WILD:shopping} Also raw domains currently automatically get www-appended, and it would be nice to be able to say no to that, e.g.: paypal[form-action]{_WILD:purchase,_WILD:shopping}(no-auto-www) authorize[form-action,script-src,style-src]{_WILD:purchase,_WILD:shopping}(no-auto-www) Existing trusted_sites hooks should be upgraded to use this syntax. However, the addons they are for will all need re-testing. | ||||
| Additional Information | I want to stress what we have already for v11 is a huge step-forward over prevailing web norms since the 90s, so not having the granularity isn't a security hole so much as it is scope for further improvement (but with diminishing returns that may or may not be worth it). | ||||
| Tags | Type: Performance, Type: Security | ||||
| Time estimation (hours) | 5 | ||||
| Sponsorship open | |||||
|
|
Here is an issue discussing CSP supporting 'inheritance' from default-src, which would also help reduce header length: https://github.com/w3c/webappsec-csp/issues/321 Hopefully it gets implemented. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-12-03 00:57 | Chris Graham | New Issue | |
| 2022-12-03 00:57 | Chris Graham | Tag Attached: Type: Security | |
| 2022-12-27 15:10 | Chris Graham | Description Updated | View Revisions |
| 2022-12-27 15:10 | Chris Graham | Time estimation (hours) | 3 => 5 |
| 2022-12-27 15:10 | Chris Graham | Note Added: 0007843 | |
| 2022-12-27 15:11 | Chris Graham | Tag Attached: Type: Performance |
