Closed dormerod closed 8 years ago
Unfortunately, I think the right approach is to just not escape the HTML server-side. Caveats like the proposed present their own XSS dangers (although the above might be fine, I haven't thought about it it great detail).
Glift escapes the usual list of characters into HTML entities as expected, but runs into double escaping problems when a web server passes it data that's already been escaped.
In particular, the double escaping of the ampersand is problematic, because Glift escapes an already escaped string like:
to:
This results in the browser literally displaying:
to the user when we expected it instead to display:
I think the ampersand escaping is the main issue and it could be fixed by searching for strings like &(\w); and un-escaping them back to &\1; (in other words " back to ").
Would there be any problems with this approach?