Adhere to Content Security Policy? #37
Comments
lifthrasiir
added
question
|
That's an interesting question, because so far Roadroller was only used in the environment where CSP is intentionally disabled. If you can alter the CSP but want to avoid <!doctype html>
<meta http-equiv="Content-Security-Policy" content="
default-src 'self';
script-src 'sha256-T1TBzCp/JoxyTN6FlxyZNO8iaImLgAhOKc82rZ9IhBs='
'sha256-6nnaJ087RaGKbw89CHsxjtA6ddq/U+WmK8+9+TCGXyo='
">
<!-- the first hash for the the following <script>, the second hash for the embedded <script> -->
<script>alert('???');document.write(`<script>alert("hello?")<\/script>`);</script>If you can't alter the CSP however, I think there is no solution (and there should be no solution since otherwise it would be an obvious loophole). |
|
Thanks - yeah, disabling CSP security selectively for the added script would work, if that is possible to deploy. Are all roadroller optimization techniques fundamentally based on unsafe-eval? Or in other words, if there was a CSP-safe variant of roadroller, what kind of optimization techniques could remain there? |
|
If you need to compress the JavaScript code, yes, it necessarily requires unsafe-eval because the decompressed code would have to be fed back to the JS engine. You may still be able to use Roadroller for compressing data files, which is possible but not yet well supported right now. |
Is it possible to use this compressor while adhering to CSP unsafe-eval policies? (i.e. avoid the use of eval(), new Function() etc.)
The text was updated successfully, but these errors were encountered: