|
|
|
|
|
|
by diggan
432 days ago
|
|
|
> forbidding inline script protect you from What you use as an example has nothing to do with inline/"external" scripts at all, but everything to do with setting DOM contents vs text content. Most popular frameworks/libraries handle that as securely by default as one could (including React) and only when you use specific ways (like React's dangerouslySetInnerHTML or whatever it is called today) are you actually opening yourself up to a hole like that. If you cannot rely on the escaping of whatever templating engine/library you're using, you're using someone's toy templating library and probably should switch to a proper one that you can trust, ideally after actually reviewing it lives up to whatever expectation you have. > `<h3> {{ 'hello dear <strong>$user</strong>' | translate | unsafe }}` This would have been the exact same hole regardless if it was put there/read by external/inline JavaScript. I do agree with your last part that CSP does help slightly with "defense in depth", for when you do end up with vulnerabilities. |
|
|
> What you use as an example has nothing to do with inline/"external" scripts at all, but everything to do with setting DOM contents vs text content.
I fail to understand your point (it's certainly an understanding problem on my side)
What I wanted to express is that: 1. you can with some CSP forbid loading of cross origin script (i.e forbid hacker.ru/toto.js ) to be loaded 2. but even if you do this, you also want to block inline script (or use inline+nonce) because evil script can be executed from within your origin by using a vulnerability somehwere between the code and the final dom
> This would have been the exact same hole regardless if it was put there/read by external/inline JavaScript.
yes we both agree that it's the same vulnerability at the end, i'm just saying that you can arrive there from different path, and these different path are protected by different CSP mechanism