Input validation to avoid XSS

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

Input validation to avoid XSS

Guide 2 posts
Followers: 1 people
August 4, 2019

I recently had a code reviewed for security issues. The report read “In application code, untrusted user data is displayed in the user’s browser without input validation and with deprecated output encoding

How can input validation look? Is it an option to remove invalid or unwanted HTML with a library like JSOUP from a string before it is entered into a database?

What methods do you use? Why is input validation important, when output validation takes place.

Comments (4)
2019-08-06 13:39:50
2019-08-06 13:39:50

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.

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.

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 htmleditformat function, but it was quite limited.

CF10 then added the encodeforHTML function, along with several other encodefor* 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 how to use that to do such encoding even before the new CF functions were added.)

CF2016 then added member functions for those 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 encodefor 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.

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 isvalid 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.

Instead, for real validation/sanitization of input text such as for XSS and related vulnerabilities, look to the isSafeHTML and getSafeHTML 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 Canonicalize function (added in CF10), to help remove encodings from a string before it may be validated.

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:

Finally, there are also tools to help you find and fix such problems in CFML (both output protection and input validation). First was the CF Enterprise Security Code Analyzer (built into CFBuilder 2016 and above, working with the Enterprise edition only of CF 2016 and above).

More recently is Pete Freitag’s Fixinator (https://fixinator.app) 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.

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.)

Like
(2)
(3)
>
Charlie Arehart
's comment
2019-08-06 14:01:56
2019-08-06 14:01:56
>
Charlie Arehart
's comment

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 display of potentially XSS-injected output.

Then I remembered you were also asking about validation of such input. 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.

Like
(1)
>
Charlie Arehart
's comment
2019-08-07 21:59:19
2019-08-07 21:59:19
>
Charlie Arehart
's comment

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

 

Like
>
Bernhard Döbler
's comment
2019-08-07 22:57:06
2019-08-07 22:57:06
>
Bernhard Döbler
's comment

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).

Like
Add your comment