2

I am aware of various ways to prevent XSS attacks, such as escaping and encoding, which are prone to issues, and using a Content Security Policy which requires extraction of all scripts. However, what concerns prevent us from using an html tag such as <antiscript> to prevent the browser from executing any scripts under this element in the DOM tree, whether directly declared with <script> or as an tag attribute such as onmouseover, within these tags? At first thought, it seems that would be rather easy to detect someone trying to break out of this non-scripting context because the </antiscript> tag would need to appear.

Improve this question

1 Answer 1

Reset to default
1

I don't think it would actually help.

If I understand correctly, you are proposing a scheme like this:

<antiscript>
    <a>"$user-supplied-input"</a>
</antiscript>

correct?

So what's stopping me from breaking out of it by providing the input:

"</a></antiscript><script>do_something_bad()</script>

so that the page source will be:

<antiscript>
    <a>""</a></antiscript><script>do_something_bad()</script>"</a>
</antiscript>

The page is parsed, my <script>do_something_bad()</script> will not be inside the <antiscript> </antiscript> in the DOM. (the HTML that follows it will be broken, but since HTML parses top-to-bottom, my payload will make it into the DOM, so who cares?)

You address this in the question:

It would be rather easy to detect someone trying to break out of this non-scripting context because the tag would need to appear.

But that means that under no circumstances could the string "</antiscript>" appear as text anywhere on the internet. That seems like a problem. What if, for example, you wanted to write a blog describing how to use this feature?

Improve this answer
5
  • Before the user input was sent to the page, a regular expression would remove all instances of </antiscript>. So "</a></antiscript><script>do_something_bad()</script> would be transformed to "</a><script>do_something_bad()</script>. If someone wanted to use the string "</antiscript>" to talk about this tag, then they would use the standard HTML encoding write it as "&lt;/antiscript&gt;"
    – Arcanum
    Sep 2, 2018 at 2:40
  • @Arcanum that, that doesn't make any sense. If you're able to run a regex on the user input as part of generating the page, then why not just do regular HTML escaping? Also, you just entered "&lt;/antiscript&gt;" in a user input box and it showed up as "&lt;/antiscript&gt;", not as "</antiscript>".
    – Mike Ounsworth
    Sep 2, 2018 at 3:52
  • I suspect your solution will work if you think through all the edge-cases, but it's not clear to me that it's better than output escaping.
    – Mike Ounsworth
    Sep 2, 2018 at 4:01
  • Regular HTML escaping is sometimes not an option when we want to allow the user input to contain HTML for formatting purposes, but not for scripts. When we need to allow certain tags, this can be hard as there are many ways to change into a script context; for example even if we allow <font> tags someone could write <font onmouseover="alert(1)"> and there are entire sets of libraries dedicated to this: github.com/ESAPI. It would show up verbatim if StackExchange is escaping the & to &amp; some time between entry and when it is displayed on the screen.
    – Arcanum
    Sep 2, 2018 at 15:44
  • @Arcanum Good point that when you want to allow certain HTML tags, the process of building a safe allowlist is tricky. You'd still need to convince me that scripts (ie JavaScript) are the only dangerous thing. For example I believe <font> can reference malicious font packs, etc. So if you want to allow formatting HTML, I'm not sure you can get around needing an allowlist mechanisms to restrict what tags are accepted.
    – Mike Ounsworth
    Sep 2, 2018 at 16:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .