encodeForHtml()
(new in CF10) vs htmlEditFormat()
, how are they different?
I think it is same as encodeForHTML function in java's OWASP ESAPI. More secure to avoid XSS attack to use content in HTML.
<cfsavecontent variable="htmlcontent">
<html>
<head>
<script>function hello() {alert('hello')}</script>
</head>
<body>
<a href="#bookmark">Book Mark & Anchor</a><br/>
<div class="xyz">Div contains & here.</div>
<IMG SRC=javascript:alert(&# x27XSS')>
<IMG SRC=javascript:alert('XSS')>
</body>
</html></cfsavecontent>
<cfoutput>#htmleditformat(htmlcontent)#</cfoutput>
<br />
<cfoutput>#encodeforhtml(htmlcontent)#</cfoutput>
EncodeFor* functions are based on the OWASP ESAPI libraries. The main difference is that HTMLEditFormat() merely replaces "bad" strings, like &
, <
and >
with good strings, like &
, <
and >
whereas EncodeForHTML() is smarter, with one advantage being it can recognize content that is already encoded and not double-encode it.
For example, if a user submitted the following content to your site:
<div>
Here is <i>test</i> html content includes<br/>
<script>alert('hello')</script>
Notice how & rendered with both functions.
</div>
Both HTMLEditFormat() and EncodeForHTML() would properly escape the '<' and '>' characters. But HTMLEditFormat() would blindly encode the &
again such that your output looks like:
... how &amp; rendered ...
Where it would otherwise look like with encodeForHTML():
... how & rendered ...
HTMLEditFormat() couldn't tell that the ampersand was already encoded, so it re-encoded it again. This is a trivial example, but it demonstrates how the ESAPI libraries are smarter and, therefore, more secure.
Bottom line, there's no reason to use HTMLEditFormat() in CF10+. For maximum protection, you should replace the Format functions with the Encode functions.
The complete example above and more background are at isummation: http://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/
来源:https://stackoverflow.com/questions/10597073/encodeforhtml-vs-htmleditformat