Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Improper output encoding in Execution Details page
-
The
/executions/execution-details
page does not appear to completely encode all user-generated content.Consider the following OtterScript, which demonstrates a classic script-injection:
Log-Information "<script type='text/javascript'>window.alert('oops!');</script>";
- Run that script as an ad-hoc job;
- Navigate to the
/executions/execution-details
page for that execution; - Expand the Execution logs section, and its child Execution section;
- Observe that the embedded JavaScript alert is shown.
I think this is specific to content that is lazy-loaded into the page (the content of the Execution section only loads when the section is expanded). If
Log-Error
is used instead ofLog-Information
, the issue does not seem to occur. I think this is because the Execution section is already expanded when there are warning/error messages.Subsections headers emitted by script in described nested blocks don't seem to be affected either, so...
# <script type='text/javascript'>window.alert('oops!');</script> { Log-Information "This should be logged inside a subsection; the subsection header encoding seems fine"; }
...seems not to be an issue, even though the Execution section is not initially expanded.
However, unexpanded messages inside the subsection are still subject to the issue...
# <script type='text/javascript'>window.alert('in comment header');</script> { Log-Information "<script type='text/javascript'>window.alert('in info');</script>"; }
For what it is worth, I originally noticed this because I trying to
Log-Information
some generated XML content, prior to writing it to a file. The tags of the XML intermingled with the HTML content and broke the rendering.The
<script>
example is easier to demonstrate (and may itself present a wider XSS issue...)
-
@jimbobmcgee thank you again for the very detailed analysis; we will get this fixed via OT-515, it's most an easy encoding to add