Summary
User supplied values passed through to certain attributes in form widgets are not fully escaped for potentially dangerous tokens, and in some cases are rendered in browser as valid html tags.
Details
Attributes passed to the widget (such as label_field) containing <, >, and similar tokens are not fully escaped. This results in some raw values reaching the widget, and rendering in part or fully.
For example, a label of: "Test User <script>I can pass this to the label_field and it gets rendered</script>" is rendered in the choices's label visually as "Test User " with the trailing space, and what appears as an un-executed script tag following it (which is visible when viewing source).
The actual output rendered in the browser for this example is: <div role="option" data-value="63f205b6" class="item" data-ts-item="">Test User <script>I can pass this to the label_field and it gets rendered</script></div>
The script tags appears to be valid in Chrome dev tools, but doesn't appear execute code.
Impact
Although the risk may be mediated since the content within the rendered <script></script> tags does not seem to actually/immediately run, potential may exist for other ways of increasing the risk (e.g.: code injection). In addition, the widget does not display correctly for valid strings containing < or >. Valid use-cases for printing these characters include widget label fields displaying email addresses (e.g.: "User Jane <[email protected]>"
Because of the relatively small number of users at this moment, our plan to yank affected releases on PyPI and GitHub, and because raw text is rendered but does not seem to be executable, I am marking the Severity Low.
Update to version 5.3.3. The only difference from 5.3.2 is the code and documentation changes to resolve this vulnerability, so the update process should not be problematic.
References
Summary
User supplied values passed through to certain attributes in form widgets are not fully escaped for potentially dangerous tokens, and in some cases are rendered in browser as valid html tags.
Details
Attributes passed to the widget (such as
label_field) containing<,>, and similar tokens are not fully escaped. This results in some raw values reaching the widget, and rendering in part or fully.For example, a label of:
"Test User <script>I can pass this to the label_field and it gets rendered</script>"is rendered in the choices's label visually as"Test User "with the trailing space, and what appears as an un-executed script tag following it (which is visible when viewing source).The actual output rendered in the browser for this example is:
<div role="option" data-value="63f205b6" class="item" data-ts-item="">Test User <script>I can pass this to the label_field and it gets rendered</script></div>The script tags appears to be valid in Chrome dev tools, but doesn't appear execute code.
Impact
Although the risk may be mediated since the content within the rendered
<script></script>tags does not seem to actually/immediately run, potential may exist for other ways of increasing the risk (e.g.: code injection). In addition, the widget does not display correctly for valid strings containing<or>. Valid use-cases for printing these characters include widget label fields displaying email addresses (e.g.:"User Jane <[email protected]>"Because of the relatively small number of users at this moment, our plan to yank affected releases on PyPI and GitHub, and because raw text is rendered but does not seem to be executable, I am marking the Severity Low.
Update to version 5.3.3. The only difference from 5.3.2 is the code and documentation changes to resolve this vulnerability, so the update process should not be problematic.
References