Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Scripting Sightly Engine 1.0.18
-
None
Description
For the following Sightly script
<a data-sly-element="${'invalidelement' @ context='unsafe'}"></a>
the generated Servlet looks like this
Object var_tagvar0 = renderContext.call("xss", renderContext.call("xss", "invalidelement", "unsafe"), "elementName"); if (RenderUtils.toBoolean(var_tagvar0)) { out.write("<"); out.write(RenderUtils.toString(var_tagvar0)); } if (!RenderUtils.toBoolean(var_tagvar0)) { out.write("<a"); } out.write(">"); if (RenderUtils.toBoolean(var_tagvar0)) { out.write("</"); out.write(RenderUtils.toString(var_tagvar0)); out.write(">"); } if (!RenderUtils.toBoolean(var_tagvar0)) { out.write("</a>"); }
So the element name is XSS protected twice. First with 'unsafe' (which doesn't modify the given literal) and then with 'elementname', which removes the literal.
Therefore the generated HTML from the servlet is <a></a> instead of <invalidelement></invalidelement>
This contradicts the documentation at https://docs.adobe.com/docs/en/htl/docs/block-statements.html#element which says
For security reasons, data-sly-element accepts only the following element names:
a abbr address article aside b bdi bdo blockquote br caption cite code col colgroup
data dd del dfn div dl dt em figcaption figure footer h1 h2 h3 h4 h5 h6 header i ins
kbd li main mark nav ol p pre q rp rt ruby s samp section small span strong sub
sup table tbody td tfoot th thead time tr u var wbrTo set other elements, XSS security must be turned off (@context='unsafe').
The HTL spec only says
The element name is automatically XSS-protected with the elementName context, which by the way doesn't allow elements like <script>, <style>, <form>, or <input> (see the Display Context section for the exact list).
(https://github.com/Adobe-Marketing-Cloud/htl-spec/blob/master/SPECIFICATION.md#224-element).
I am wondering, if it really is just impossible to give out arbitrary tag names with data-sly-element.
IMHO if another context is given, that one should replace the "elementName" context, instead of being added on top.
Attachments
Issue Links
- is caused by
-
SLING-5568 Sightly filters don't remove their specific options from the expression during processing
- Closed
- is cloned by
-
SLING-7024 Sightly doesn't allow to emit style or on event attributes for data-sly-attribute
- Closed
- relates to
-
SLING-6866 HTL doesn't allow to overwrite the context for data-sly-text
- Closed