4 ms·

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

theandrewbailey 1y ago
CSP tells the browser where scripts and styles can come from (not just inline, but origins/domains, too). Let's pretend that an attacker can inject something into a page directly (like a SQL injection, but HTML). That script can do just about anything, like steal data from any form on the page, like login, address, or payments, or substitute your elements for theirs. If inline resources are forbidden, the damage can be limited or stopped. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
- magicalhippo 1y ago
  Still recall the classic forum exploits of including Javascript in your signature or similar, before such software started escaping input.
bryanrasmussen 1y ago
sounds weird to me too, although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script - about the only way I can think of it being bad.
- diggan 1y ago
  > although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script Wouldn't even matter, as it's the origin of wherever it ends up being executed that matters, not where the code was loaded from. So JS code loaded from cdn.jquery.com on mywebsite.com would have the origin mywebsite.com, even if loaded with a typical <script> tag. In short, CORS applies to network requests made by scripts, not to the scripts themselves
  - bryanrasmussen 1y ago
    ah yeah, sorry wasn't thinking clearly.
flir 1y ago
Cross-Site Scripting. If a user injects a malicious script into the page, it doesn't get run.
allan_s 1y ago
forbidding inline script protect you from ``` <h3> hello $user </h3> ``` with $user being equal to `<script>/* sending your session cookie out, or the value of the tag #credit-card etc. */</script>` you will be surprised how many template library that supposedly escape things for you are actually vulnerable to this , so the "React escape for me" is not something you should 100% rely on. In a company I was working for the common vulnerably found was `<h3> {{ 'hello dear <strong>$user</strong>' | translate | unsafe }}` with unsafe deactivating the auto-escape because people wanted the feature to be released, and thinking of a way to translate the string intermixed with html was too time-consuming for inline style, it may hide elements that may let you input sensitive value in the wrong field , load background image (that will 'ping' a recipient host) with CSP activated, the vulnerability may exists, but the javascript/style will not be executed/applied so it's a safety net to cover the 0.01 case of "somebody has found an exploit in
- diggan 1y 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.
  - allan_s 1y ago
    my point is that all your templates are at thend coded by human that make mistakes https://nvd.nist.gov/vuln/detail/CVE-2024-6578 https://nvd.nist.gov/vuln/detail/CVE-2024-6578 , you may be not using "dangerouslySetInnerHTML" directly but your dependencies may > 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

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

theandrewbailey 1y ago

CSP tells the browser where scripts and styles can come from (not just inline, but origins/domains, too). Let's pretend that an attacker can inject something into a page directly (like a SQL injection, but HTML). That script can do just about anything, like steal data from any form on the page, like login, address, or payments, or substitute your elements for theirs. If inline resources are forbidden, the damage can be limited or stopped. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

magicalhippo 1y ago
Still recall the classic forum exploits of including Javascript in your signature or similar, before such software started escaping input.

bryanrasmussen 1y ago

sounds weird to me too, although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script - about the only way I can think of it being bad.

diggan 1y ago
> although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script Wouldn't even matter, as it's the origin of wherever it ends up being executed that matters, not where the code was loaded from. So JS code loaded from cdn.jquery.com on mywebsite.com would have the origin mywebsite.com, even if loaded with a typical <script> tag. In short, CORS applies to network requests made by scripts, not to the scripts themselves
- bryanrasmussen 1y ago
  ah yeah, sorry wasn't thinking clearly.

flir 1y ago

Cross-Site Scripting. If a user injects a malicious script into the page, it doesn't get run.

allan_s 1y ago

forbidding inline script protect you from ``` <h3> hello $user </h3> ``` with $user being equal to `<script>/* sending your session cookie out, or the value of the tag #credit-card etc. */</script>` you will be surprised how many template library that supposedly escape things for you are actually vulnerable to this , so the "React escape for me" is not something you should 100% rely on. In a company I was working for the common vulnerably found was `<h3> {{ 'hello dear <strong>$user</strong>' | translate | unsafe }}` with unsafe deactivating the auto-escape because people wanted the feature to be released, and thinking of a way to translate the string intermixed with html was too time-consuming for inline style, it may hide elements that may let you input sensitive value in the wrong field , load background image (that will 'ping' a recipient host) with CSP activated, the vulnerability may exists, but the javascript/style will not be executed/applied so it's a safety net to cover the 0.01 case of "somebody has found an exploit in

diggan 1y 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.
- allan_s 1y ago
  my point is that all your templates are at thend coded by human that make mistakes https://nvd.nist.gov/vuln/detail/CVE-2024-6578 https://nvd.nist.gov/vuln/detail/CVE-2024-6578 , you may be not using "dangerouslySetInnerHTML" directly but your dependencies may > 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