View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009948 | Taler | merchant backoffice SPA | public | 2025-05-13 10:30 | 2025-05-15 15:20 |
| Reporter | oec | Assigned To | sebasjm | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | reopened | ||
| Product Version | git (master) | ||||
| Target Version | 1.0 stretch goals | ||||
| Summary | 0009948: Activate Content-Security-Policy default-src: 'none' for SPA | ||||
| Description | The merchant back-end is designed and implemented as a multi-tenant system. The administrator of that system uses the same SPA which is served from the same server and domain as the front-end for the tenants. This implies that any potential XSS issue and its successful exploitation in the SPA would allow an attacker to gain access to the admin's bearer token used for authentication with the back-end. Potential attack vectors here are merchants/tenants or customers (in case of templates) who provide input to the back-end that is rendered in the SPA, if we _assume_ a vulnerability in the SPA implementation (f.e. adding a DOM-element from a raw string). Luckily, W3C has introduced in 2016 a reliable and well supported mechanism in which the server side can communicate to the browser from which sources it should allow scripts (and even which particular scripts by their hash, if necessary). This can be set by the by HTTP-server or as meta-tag by particular HTML-pages. The design decision to use a single HTML-page with a single script source for the merchant UI comes to our advantage: All that is necessary is to add the tag <meta http-equiv="Content-Security-Policy" content="default-src 'self'"> to the <head> of the document. Any lingering coding error that would allow to add f.e. a <script> tag to the DOM at runtime, or call eval on a string would not be executed in the browser and therefore XSS is mitigated. This is a defence-in-depth measure. | ||||
| Tags | No tags attached. | ||||
|
|
I have included this directive in index.html for production deployment: <meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self' data:; style-src 'self';font-src 'self';base-uri 'self';form-action 'self'"> Check that `connect-src` is `self` so that spa will only be connectable to the originated server. I have also created a development version (usable using ./dev.mjs script) which have the same policy but connect-src * to be use with any server. |
|
|
6647cf86b..013531e7c |
|
|
connect-src putting 'self'. Is too restricted, for example the SPA won't be able to connect to the bank I can put this as * and then test if adding a more restricted connect-src directive in http server response will merge both policies correctly |
|
|
after clarification only `script-src` is related to this issue so I'm leaving `connection-src` to any in prod |
|
|
ef6d1466a..510d5f5a3 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-05-13 10:30 | oec | New Issue | |
| 2025-05-13 12:10 | oec | Description Updated | |
| 2025-05-14 20:30 | Christian Grothoff | Assigned To | => sebasjm |
| 2025-05-14 20:30 | Christian Grothoff | Status | new => assigned |
| 2025-05-14 22:44 | sebasjm | Note Added: 0024910 | |
| 2025-05-14 22:45 | sebasjm | Status | assigned => resolved |
| 2025-05-14 22:45 | sebasjm | Resolution | open => fixed |
| 2025-05-14 22:45 | sebasjm | Note Added: 0024911 | |
| 2025-05-14 23:51 | sebasjm | Status | resolved => feedback |
| 2025-05-14 23:51 | sebasjm | Resolution | fixed => reopened |
| 2025-05-14 23:51 | sebasjm | Note Added: 0024912 | |
| 2025-05-15 15:19 | sebasjm | Note Added: 0024916 | |
| 2025-05-15 15:20 | sebasjm | Status | feedback => resolved |
| 2025-05-15 15:20 | sebasjm | Note Added: 0024917 |
