http://coldfusion.com logo
#cfml-general
Title
# cfml-general
f

fmdano

02/04/2022, 9:12 PM
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
d

davidrschaller

02/04/2022, 9:22 PM
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.
m

Myka Forrest

02/04/2022, 9:22 PM
Will they be displayed among html?
b

bdw429s

02/04/2022, 9:23 PM
@fmdano It depends on what you mean by "passing form variables"
I suspect you're looking at the wrong part of your workflow
encodeForHTML()
should be used when building up HTML with untrusted values. Whether that HTML is going ot be used to "pass variables" is largely orthogonal.
What would be best is if you show us some code and we can determine what you're doing and what the code needs to do
f

fmdano

02/04/2022, 9:24 PM
@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
b

bdw429s

02/04/2022, 9:24 PM
That's two different questions, and "it depends" on a number of things
f

fmdano

02/04/2022, 9:25 PM
always does doesn't it....
b

bdw429s

02/04/2022, 9:25 PM
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
āœ… 1
f

fmdano

02/04/2022, 9:26 PM
ok, so I am using cfqueryparam, so that is good...and yeah duh
āœ… 1
b

bdw429s

02/04/2022, 9:26 PM
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?
All of those have different answers šŸ™‚
f

fmdano

02/04/2022, 9:26 PM
I'd say mainly if they are displaying it inside HTML....
b

bdw429s

02/04/2022, 9:27 PM
Then use
Copy code
<div>#encodeForHTML( unstrustedValue )#</div>
Which, mind you, is different from
Copy code
<input type="text" value="#encodeForHTMLAttribute( unstrustedValue  )#">
f

fmdano

02/04/2022, 9:28 PM
so if it is going inside an input tag i should use encodeForHTMLAttribute....
b

bdw429s

02/04/2022, 9:28 PM
Yes
Because the rules for metacharacters are slightly different
f

fmdano

02/04/2022, 9:28 PM
I knew I could count on you to stretch my brain and educate me šŸ™‚
šŸ‘ 1
z

zackster

02/04/2022, 9:34 PM
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
b

bdw429s

02/04/2022, 9:39 PM
I'm not a fan of removing stuff the user typed
šŸ‘ 1
āœ… 1
If someone legally changed their name to
Brad <b>Wood</b>
then who am I to question that or remove any of those characters?
āž• 1
I will put exactly that in my DB and, since I will use
encodeForHTML()
when I display it back to them, it will show up exactly like that again.
The only time I use stuff like antisamy is when I have a form where the user is explicitly granted the ability to enter a subset of HTML and I want to allow approved tags and remove the disallowed tags.
So unless you're building a bulletin board from 1999, most people use DOM cleaners unnecessarily IMO
z

zackster

02/04/2022, 10:21 PM
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)
b

bdw429s

02/04/2022, 10:24 PM
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.
a

Adam Cameron

02/04/2022, 10:55 PM
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.
šŸŽÆ 2
b

bdw429s

02/04/2022, 11:10 PM
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.
šŸ˜‚ 1
ā¤ļø 3
z

zackster

02/04/2022, 11:13 PM
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?)
99% of your users just want to upload safe, well-formed content
ESAPI still are using log4j1....
šŸ‘€ 1
a

Adam Cameron

02/05/2022, 9:48 AM
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.
The ESAPI bods seem to be fairly certain they aren't using Log4J 1.x. Indeed they don't seem to be using Log4J at all, instead using java.util.logging. Well... just according to themselves, anyhow: https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/ESAPI-security-bulletin6.pdf It also seems to be under active development: https://github.com/ESAPI/esapi-java-legacy/pulls?q=is%3Apr+is%3Aclosed or https://github.com/ESAPI/esapi-java-legacy/issues?q=is%3Aissue+is%3Aclosed (I did not look at the details of the activity, just that there seems to be some on a regular - if not continuous - basis)
f

fmdano

02/06/2022, 6:24 PM
Well, this certainly turned into a great discussion...I always learn something new when I post a question.