trace() output not escaped properly before rendered into web page

[Jens-G]

http://try.haxe.org/#e9c1E

     trace('<script>alert("yo man")</script>');

This leads to an alert() being shown, which should not happen.
Instead, the string should be printed into the output window.

[markknol]

This is a bug in https://github.com/markknol/console-log-viewer I'll fix this soon.

[markknol]

It now logs html-tags correct: http://try.haxe.org/#F659f

BUT it does not solve what's happening here.

The <script> inside the log create/close the script tag on the page, so it's correct you see half of the code and an illegal token error.
It's basically does the same when you create this html-page:

<script><script>alert('yo man')</script> bla bla</script>

This writes the everything after the first </script> on the page.

@clemos Should we blacklist something like this too? Since you can now break the script tag premature; I'm not sure if this is a potential security issue too.

[clemos]

I guess I should not inline the generated JS in the "runner" iframe, that's all.
I'll look into that.

[Jens-G]

Thanks for looking at this,. Two remarks:

a) In console.log("<div>alert(yo man\")</div>"); the closing div tag should be escaped too: console.log("<div>alert(yo man\")<\/div>");

Reference: https://mathiasbynens.be/notes/etago

b) Re security: Whenever I'm able to inject code into a page like we have it here, I'd recommend to always treat it as security relevant, even when it actually seems not to be an exploitable thing. Why? Two reasons:

• it is hard to know how that code is going to be used in the future, and at some day it may become security relevant, but nobody will notice it until someone actually exploits it and does some real damage.
• people are f*ing damn creative when it comes to craft exploits, beyond your wildest imaginations. The problem we face here is mainly that of what is called "the unknown unknowns": you don't know what you don't know, and thus may overlook a weak point in the entire security concept.