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-13 12:10 |
Reporter | oec | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | new | Resolution | open | ||
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. | ||||