You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#3 accidentally introduced a regression wrt. to CSS rendering. <script> and <style> tags are special in HTML, as they are encoded as CDATA. That essentially means – no escaping, but closing tag can't appear in the payload content and HTML does not provide a way to escape this.
At the moment:
<style> elements generated by web-view use regular text escaping, thus, if they contain any of escaped characters (<>&"' etc.) rendered CSS will be incorrect,
<script> element that we don't have a helper now will: either cause invalid JS to be rendered (if text is used) or invalid HTML (with the risk of opening XSS vulnerability) if raw is used – the latter was also the case for CSS before Escape HTML text and attributes #3 was merged.
For example, addClass $ cls "test" & prop "background" ("url('https://picsum.photos/200/300?random=1&foo=2=bar')" :: Text)) will generate incorrect result:
Potential solution could be to introduce External to AST, which would be always the same as Raw but would refuse to include any </ sequence which would prevent XSS/invalid HTML. This is what blaze-markup does for these tags.
Trivia: Historically, people would split string literals in JS payloads to "escape" them, e.g.
#3 accidentally introduced a regression wrt. to CSS rendering.
<script>
and<style>
tags are special in HTML, as they are encoded as CDATA. That essentially means – no escaping, but closing tag can't appear in the payload content and HTML does not provide a way to escape this.At the moment:
<style>
elements generated by web-view use regular text escaping, thus, if they contain any of escaped characters (<>&"' etc.) rendered CSS will be incorrect,<script>
element that we don't have a helper now will: either cause invalid JS to be rendered (iftext
is used) or invalid HTML (with the risk of opening XSS vulnerability) ifraw
is used – the latter was also the case for CSS before Escape HTML text and attributes #3 was merged.For example,
addClass $ cls "test" & prop "background" ("url('https://picsum.photos/200/300?random=1&foo=2=bar')" :: Text))
will generate incorrect result:Potential solution could be to introduce
External
to AST, which would be always the same asRaw
but would refuse to include any</
sequence which would prevent XSS/invalid HTML. This is what blaze-markup does for these tags.Trivia: Historically, people would split string literals in JS payloads to "escape" them, e.g.
The text was updated successfully, but these errors were encountered: