portal entry

select a category, or use search below
(searches all categories and all time range)

Input validation to avoid XSS

| View in Portal
August 04, 2019 10:55:07 PM GMT
<p>How to perform input validation to avoid XSS?</p>
<p>The post <a rel="nofollow" href="https://coldfusion.adobe.com/2019/08/input-validation-avoid-xss/">Input validation to avoid XSS</a> appeared first on <a rel="nofollow" href="https://coldfusion.adobe.com">ColdFusion</a>.</p>
Labels: ColdFusion, Discussion, Modern CFML, discussion, modern cfml, security


<p>XSS is of course a problem that has affected web apps, including CF-based ones, for decades. But yep, sometimes we may only become sensitive to the issues (and seek solutions) once we get hit with an attack or (perhaps better) have some security scan help us see we may have vulnerabilities.</p> <p>And CF has had various solutions for addressing it in various ways, whether for input validation or output protection, for about as long. The oldest were far less capable than those added since CF10 and above. When you say your errors report use of "deprecated output encoding", that would be related to any output protection you may be using. Perhaps your code uses the older approaches, and you may just need to update to the more modern ones.</p> <p>Let's look at options for output protection first, as those help with dealing with bad content that may already be in your database, etc. These functions tend to focus on stripping out from a given string any html, javascript, or other content that seems "unsafe". The oldest "solution" may be the <strong>htmleditformat</strong> function, but it was quite limited. </p> <p>CF10 then added the <strong>encodeforHTML</strong> function, along with several other <strong>encodefor*</strong> functions (encodeforjavascript, encodeforurl, encodeforcss, and more). These all do MUCH more than the old htmleditformat (which handled only a few "worrisome" characters), being based on the OWASP ESAPI project. (For the sake of completeness, even later updates of CF8 and 9 had offered the ESAPI library built-into CF, and some folks showed then <a href="https://www.petefreitag.com/item/788.cfm" rel="nofollow">how to use that</a> to do such encoding even before the new CF functions were added.)</p> <p>CF2016 then added <strong>member functions for those</strong> encoding functions (so that rather than wrapping the string with a call to the function, you could append the function to the variable holding the string, which suits some coding styles better). CF2016 also added the <strong>encodefor</strong> attribute in tags like cfoutput and as an arg for functions like writeoutput, when wrapping each output item seems tedious. There are pros and cons to all these solutions, and you can google to find the docs for each, but I offer below some resources that discuss them and CF/XSS protection in general.</p> <p>As for validating the input (which is indeed just as important), there are also various solutions. First and most simplistically there has long been (since CF7) an <strong>isvalid</strong> function, which could at least validate something for any of a number of specific expected patterns of input (like if it was numeric, or a date, zipcode, email, etc.). But that's won't help with checking if an input text field has "unsafe" content.</p> <p> Instead, for real validation/sanitization of input text such as for XSS and related vulnerabilities, look to the <strong>isSafeHTML</strong> and <strong>getSafeHTML</strong> functions, added in CF11, which sanitizes input using an antisamy policy file (either CF's default found in cfusion\lib\antisamy-basic.xml, or one you create and can specify at the code or application level). Consider also the <strong>Canonicalize</strong> function (added in CF10), to help remove encodings from a string before it may be validated.</p> <p>There are many resources discussing these things and XSS with regard to CF. First I list a couple of seminal ones, then ones addressing changes in each release, in descending order of recency:</p> <ul> <li><a href="http://www.learncfinaweek.com/week1/cross_site_scripting__xss_/" rel="nofollow">http://www.learncfinaweek.com/week1/cross_site_scripting__xss_/</a></li> <li><a href="https://www.adobe.com/devnet/coldfusion/articles/security-improvements-cf11.html" rel="nofollow">https://www.adobe.com/devnet/coldfusion/articles/security-improvements-cf11.html</a></li> <li><a href="https://medium.com/pete-freitag/coldfusion-2016-security-encodefor-969a8858b8ee" rel="nofollow">https://medium.com/pete-freitag/coldfusion-2016-security-encodefor-969a8858b8ee</a></li> <li><a href="https://helpx.adobe.com/coldfusion/developing-applications/building-blocks-of-coldfusion-applications/using-the-member-functions.html#SupportedStringmemberfunctions" rel="nofollow">https://helpx.adobe.com/coldfusion/developing-applications/building-blocks-of-coldfusion-applications/using-the-member-functions.html#SupportedStringmemberfunctions</a></li> <li><a href="https://www.raymondcamden.com/2014/04/09/getSafeHTML-and-ColdFusion-11" rel="nofollow">https://www.raymondcamden.com/2014/04/09/getSafeHTML-and-ColdFusion-11</a></li> <li><a href="http://cfpavankumar.blogspot.com/2014/04/using-antisamy-framework-with.html" rel="nofollow">http://cfpavankumar.blogspot.com/2014/04/using-antisamy-framework-with.html</a></li> <li><a href="https://gist.github.com/dcepler/4126222" rel="nofollow">https://gist.github.com/dcepler/4126222</a></li> <li><a href="https://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/" https://www.raymondcamden.com/2014/04/09/getSafeHTML-and-ColdFusion-11rel="nofollow" rel="nofollow">https://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/</a></li> <li><a href="https://www.isummation.com/blog/day-3-avoid-cross-site-scripting-xss-using-coldfusion-10-part-2/" rel="nofollow">https://www.isummation.com/blog/day-3-avoid-cross-site-scripting-xss-using-coldfusion-10-part-2/</a></li> </ul> <p>Finally, there are also tools to help you find and fix such problems in CFML (both output protection and input validation). First was the <strong>CF Enterprise Security Code Analyzer</strong> (built into CFBuilder 2016 and above, working with the Enterprise edition only of CF 2016 and above).</p> <p>More recently is Pete Freitag’s <strong>Fixinator</strong> (<a href="https://fixinator.app/" rel="nofollow">https://fixinator.app</a>) tool which (though commercial) works with any edition of CF and does not require using any editor/IDE. I highly recommend folks implement either one of these tools to secure their code.</p> Long answer to what may seem a "simple question", but then it's a rather complex problem, again with various solutions and which have evolved over the years. Hope that was helpful. (And I should probably create a blog post out of this, though I will wait to see if any comments may suggest additions or enhancements.)
Comment by Charlie Arehart
2226 | August 06, 2019 01:39:50 PM GMT
Bernhard, in case you (or anyone else following this post and comments) may have gotten an email of (or have already read) my initial comment, please note that I have just updated it since originally posting it about 15 mins ago. When I first read your post and replied, I focused on what is for most folks the most common first step for protecting against XSS, by controlling the <span style="text-decoration: underline;">display</span> of potentially XSS-injected output. Then I remembered you were also asking about <span style="text-decoration: underline;">validation of such input</span>. So I have added a bit more about that. Again, see the list of resources, as some (and the tools) do go into both facets of the problem.
Comment by Charlie Arehart
2227 | August 06, 2019 02:01:56 PM GMT
Hi Charlie, thank you so much for your answer. Much more extensive, than I had hoped for. It will take me some time to read and to understand everything. I accept the fact, that my knowledge is not very recent. I  received results of security test of ColdFusion projects in the past. They never really made the impression the testers - or the software they use to test the application - knew CF. It came as a surprise to read such a specific point in the report. I split the issue in two questions for a simple reason. Regarding the securing of the output the solution was clear. Use the newer functions (7 years old) instead of the older ones. Regarding the validation of the input I'm open to suggestions. You advise to use isValid. This is definitely useful to get meaningful data, not only XSS-safe data.   Thank you again, Bernhard  
Comment by Bernhard Döbler
2232 | August 07, 2019 09:59:19 PM GMT
Understood, and happy to help. But don't stop at isvalid. :-) That is the minimal solution. Be sure to check out the issafehtml and getsafehtml, for more (and for their ability to be extended).
Comment by Charlie Arehart
2233 | August 07, 2019 10:57:06 PM GMT