Is EncodeForHTML as it is more secure than HTMLEditFormat?
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?
Newbie
2 posts
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.
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
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.
That would be a good one for StackOverflow
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
