Probably a dumb question, but going to ask anyway....passing form variables (form.first_Name) or url variables (url.myid) to some sort of "action" page, should I always encodeForHTML() these variables, or is there a time and place to use encodeForHTML()? Working on good security practices for a site and want to double check this best practice so I do it right. Thanks

Taken from Coldbox documentation [https://coldbox.ortusbooks.com/for-newbies/60-minute-quick-start/working-with-event-handlers]: Please note that we used the ColdFusion function

encodeForHTML()

(https://cfdocs.org/encodeforhtml) on the public variable. Why? Because you can never trust the client and what they send, make sure you use the built-in ColdFusion encoding functions in order to avoid XSS hacks or worse on incoming public (

rc

) variables. Note: rc is a structure that is populated with form and url scope.

Will they be displayed among html?

@fmdano It depends on what you mean by "passing form variables"

@bdw429s if the user is filling out a form on the screen, before it goes into the database OR is displayed on another screen, should I always use encodeforhtml

That's two different questions, and "it depends" on a number of things

always does doesn't it....

I can answer one of them right away • should you HTML encode values in the DB No, don't ever do this. When building SQL, you need to escape them for the query (cfquery param) but not for HTML

ok, so I am using cfqueryparam, so that is good...and yeah duh

displayed on another screen,

This depends on what you mean by "displayed". Displayed how? INside a JS string that's appended to the DOM? Inside an HTML tag? Inside an HTML tag's attribute? Inside a query string?

I'd say mainly if they are displaying it inside HTML....

Then use

<div>#encodeForHTML( unstrustedValue )#</div>

so if it is going inside an input tag i should use encodeForHTMLAttribute....

Yes

I knew I could count on you to stretch my brain and educate me 🙂

always do server side encoding, but you can also do client side checks before submitting stuff. this is the gold standard for doing that https://github.com/cure53/DOMPurify

I'm not a fan of removing stuff the user typed

You don't need to remove it, but form validation says is this acceptable, you can decide how to handle it. Plus don't CF engines already strip this stuff automatically anyway (to a degree, but that's another story)

There's scriptprotect, but I hate that feature for the reasons described above 😉 It would be palatable if it at least allowed for per-page overrides. I always end up turning off script protect for the entire site because there will be that ONE page in my CMS's admin that needs to submit HTML from a logged in user and the stupid script protect feature is always clobbering it.

Brad has nailed it here. Encode the value "at the last mile", ie: when it gets "used" in a situation where one knows the appropriate encoding mechanism for the situation at hand. Outputing it in an HTML doc?

encodeForHtml

. In an HTML attribute in that doc?

encodeForHtmlAttribute

. etc. Do not second-guess the ultimate usage and encode it for that upon storage. DO NOT encode a value before storing it in a DB(*), and think yer covered. Why? ~Two~Three reasons: • you don't know how it will be used. You don't. Stop thinking you do. And it's just bad coupling anyhow. • It is more difficult to tell from looking at your output code (eg view) whether you are protected or not. If you see a view with every value encoded at use, you know yer safe. If some are and some aren't [because reasons]? How do you now? • Also the source of the data that ends up being rendered in one's view for that particular variable might not come from the value that was encoded before storing. Again: it's bad coupling to assume it will be. (*) that is not to say that one oughtn't protect any value used in an SQL statement as well. Parameterising data values only gets you so far. When building SQL dynamically one needs to consider the composition of the actual SQL as well. This is tangential to the question asked, but still a consideration. Oh and never ever rely on anything done on the clientside. That stuff is only for UX, not data-processing / security.

Here is a picture I took on my cell phone while buying parts at an autoparts store. You can see their devs clearly HTML Encoded all their product names in the DB and didn't account for the values being used on their point of sale screens.

Dom purify can also be used client side to ensure that embedded xss you saved to the db on your advice didn't bypass something which esapi didn't catch (which library is actively maintained?)

Haha, nice. Yeah the point was - I think - don't encode until you know what yer encoding for, and don't couple the wrong things together in yer application. That just encourages / facilitates fuck-ups. If there are more up-to-date libs than ESAPI, then fill yer boots.

Well, this certainly turned into a great discussion...I always learn something new when I post a question.