Closed Narmu-1 closed 9 months ago
Hello @jonesde is this a valid bug? how to fix it?
Was able to reproduce. Thank you @Narmu-1 for figuring this out!
How to fix this is another question. Some ideas are server side validation of {{ or }} (handling potential whitespace) for all fields by default, add server side escaping for { and } characters such as https://v2.vuejs.org/v2/guide/security#HTML-content, or/and changing the ftl templates to sanitize output characters.
thanks @acetousk for confirming. Can you please assign the labels for this issue. Regards.
There is now a fix in place for the label and link elements for the qvt (/qapps) and vuet (/vapps) render modes. See this commit in moqui-runtime:
https://github.com/moqui/moqui-runtime/commit/28454b42596900b0e301c6b452836d9ca672483c
From a bit of research the best solution seems to be adding the v-pre
attribute to an element wrapping the text so that the text is not interpreted by Vue JS, avoiding the template injection issue and resulting in the text just being displayed.
There does not seem to be a way to encode the text so that it is not interpreted. This means that for any custom Vue templates, or any other places in the framework we discover over time, the v-pre attribute will need to be adding (possibly in a wrapping span element like I did for the link macros so that it doesn't break the intended parts of the template because it seems to disable Vue template interpretation for the element with a v-pre attribute as well as the contents of the element!).
This fixes the issue for the Product Store screen and various others. If you find any other places this happens please let me know, in this issue or another one.
adding the the following string to the input fields in https://demo.moqui.org/qapps
{{constructor.constructor('alert(1)')()}}
will result in injecting the template to the application and will trigger stored XSS