EncodeForHTML vs. HTMLEditFormat

August 4, 2019
Guide 2 posts
Followers: 1 people
4

EncodeForHTML vs. HTMLEditFormat

Guide 2 posts
Followers: 1 people
August 4, 2019

The code of my (ongoing) ColdFusion project was recently reviewed for security issued. I found one report to be very strange.

It’s about Stored Cross-Site Scripting (XSS) with a high CVSS Score of 9.1 refering to CWE ID: 79

The description reads

Context Description: In application code, untrusted user data is displayed in the user’s browser without input validation and with deprecated output encoding method which can result in a Cross-Site Scripting attack.

Note: 

  • Adobe recommends that you use the EncodeForHTML function, not the HTMLEditFormat function, to escape special characters in a string for use in HTML in all new applications.
  • Entire codebase is using “HTMLEditFormat” method.

I am firstly wondering if anyone of you has ever received a review that specific. I got reviews in the past that mentioned a lack of security features (like output escaping) but never played  EncodeForHTML out against HTMLEditFormat.

When they recognize the application is secured – why, still, the high score?

On Stackoverflow someone once said: HTMLEditFormat() couldn’t tell that the ampersand was already encoded, so it re-encoded it again

The documentation says: canonicalizeOptional. If set to true, canonicalization happens before encoding. If set to false, the given input string will just be encoded. The default value for canonicalize is false

This looks to me like there is no improvement by simply replacing every call to HTMLEditFormat with EncodeForHTML but I would also have to pass true as second parameter to benefit.

There is a blog post from only two years ago that deals with the improvements CF 10 braught: https://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/ It looks to me, like the improvement is not the new function EncodeForHTML as it is. The improvement lies in the set of new functions like encodeForHTMLAttribute, encodeForJavaScript and so forth.

Phrased as question: Is there any benefit from calling EncodeForHTML rather than HTMLEditFormat?

Comments (4)
2019-08-06 15:50:08
2019-08-06 15:50:08

Yes, there is indeed far more benefit to that than the very old htmleditformat (which only encoded a few characters).

And more than just using encodeforhtml, consider also the related functions also added with it in CF10 (encodeforurl, encodeforjavascript, etc.), and/or their member function equivalents added in CF2016.

These all perform encoding based on the OWASP ESAPI project. As you posted another question at the same time, and I had already answered that in more detail, with links to references, I would point you (and readers of this) to that for more on the encodefor features and their benefits.

Like
(2)
(3)
>
Charlie Arehart
's comment
2019-11-14 19:12:53
2019-11-14 19:12:53
>
Charlie Arehart
's comment

I found, somehow, the EncodeForHTML ruined emoji in the text (turned them into “? in diamond”) while the old depreciated HTMLEditFormat didn’t.

Is there a way we can use the newer, better EncodeForHTML while keeping emoji

Like
(1)
>
Billy Fan
's comment
2019-11-14 20:37:24
2019-11-14 20:37:24
>
Billy Fan
's comment

All these functions simply control what HTML is generated. Look at the page you are seeing the problem on, and do a “view source”. Report what you are seeing. Maybe someone can then recommend a better solution–or help understand why you are hitting the problem, in which case you may want to open a bug report at tracker.adobe.com instead.

Like
>
Billy Fan
's comment
2019-11-15 01:04:48
2019-11-15 01:04:48
>
Billy Fan
's comment

That would be a good one for StackOverflow

Like
Add your comment