[Looking for Charlie's main web site?]

New "ColdFusion 8 developer security guidelines" at Adobe DevCenter

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I haven't seen much mention of this elsewhere, but I happened upon a new 47-page whitepaper called "ColdFusion 8 developer security guidelines", by Erick Lee, Ian Melven, and Sarge Sargent. It's listed in the Adobe Security DevCenter, which shows it having been posted as of today.

Like other whitepapers that have been put together by Adobe, Macromedia, Allaire, and others, this one offers overviews of key concerns along with proposed best practices.

Is it complete? Does it really need to be?

As with any such document, there will be debate among some readers about whether the practices are always really the "best". It's inevitable. But let's give credit that the authors do try to give a rather brief round up of the features, their options, and the impact of choices.

Just as Ben's famous CF "Certification Study Guide" is a quick summary of key things in CFML (and no substitute for the complete ColdFusion documentation or the WACK books), so too would I argue that this guide is a quick summary of important points to consider. Readers would do well to understand the issues completely, both in terms of the generic concerns they raise and the specifics of CFML features and options. For that, the docs and other books would be great resources.

Still, many readers won't have time for that, so despite the fact that some may pick it apart, it will serve a large percent of the community who might otherwise have no knowledge of the concerns and configuration features. For that, we should thank the authors.

Its sections

The document is divided into the following sections: Authentication, Authorization, CFCs, Session Management, Data validation and interpreter injection, Ajax, PDF integration, .NET integration, HTTP, FTP, Error handling and logging, File System, Cryptography, Configuration, Maintance and References.

Earlier editions, and what's updated in the CF8 guide?

While the guide does focus on CF8, there is another version of the document for those running CF7, the "ColdFusion 7 developer security guidelines". It, too, is by 2 of the 3 authors of the other whitepaper, Erick Lee and Sarge Sargent. It's only 33 pages, and it too is listed at the Adobe DevNet Security Developer Center, where it show it having been updated as of Oct 2007.

You might think that the CF8 guide is updated only to refer to things new in CF8, but in fact I find some things in the CF8 guide that are not in the CF7 guide, but are not new for CF7. Perhaps they decided to expand the CF8 guide in ways that they didn't push back down into the CF7 guide (understandable if time was limited). That means that CF7 developers may want to read the later guide, though they'd have to ignore features that are indeed new to CF8.

For instance, I found a discussion of the trusted cache feature only in the CF8 guide (more on that below). I didn't do a careful comparison of what's different.

BTW, I'll add that I found references in searches both on the Adobe site and Google to a version of the security guidelines at a URL that no longer works. Since I couldn't access it, I was unable to determine how this CF7 version was updated (or if it was simply renamed, to distinguish it from the new CF8 version. Perhaps the authors can comment here if they read this entry.)

Where to offer feedback?

That last comment brings up a concern I have with the whitepapers offered on the Adobe site (and the articles offered on the Developer Center, as well, of which I've been an author recently.) There's no place for folks to leave feedback. It would be nice for there to be a place to have discussions about the things written in such whitepapers or articles. (The Devnet articles do offer a feedback link, but it's one way, not an open discussion.)

I'm sure some will want to comment on or trade best practices regarding the topics in this paper. Also, I'd like to share at least one error I found: in the discussion of the trusted cache feature, it's described as, "Enable Trusted cache in production environments. When enabled, ColdFusion will only server requested templates held in its memory cache. This provides performance gains but also prevents ColdFusion from running hacked or invalid templates."

Yikes. I wonder who wrote that (and who missed it during any review).That's not the purpose of trusted cache at all. It's about whether the server should look to disk to see if a template, once compiled and loaded into memory, has changed on disk. The server always only serves (not the typo, too, "will only server") pages held in its memory cache. Using trusted cache is certainly a performance gain, but I really have no idea what the reference is to "hacked or invalid templates". That makes me think the person writing this has a very wrong idea about the feature. But I'm not meaning to rip the guidelines. As I said earlier, I'm sure that many will find them very useful, and since folks rarely read the docs, it's a nice way to condense into 40+ pages some key points. I'll let others comment here about any other concerns they have. At least it will serve as one place to have such discussion. If there's a better place, I'll welcome people pointing to that.

For more content like this: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, I can help via my consulting services
  • See that for more on how I can help a) over the web, safely and securely, b) usually very quickly, c) teaching you as we go, and d) with satisfaction guaranteed
Comments
Charlie, thanks for the link, I'll be reading this whitepaper today. As for trusted template cache and hacked templates, I _think_ what the authors may have meant is that once a valid template is loaded into the cache, it doesn't matter if the source template is hacked, only the template held in cache will be served. I agree that this is not the purpose of trusted cache, but it is a side effect.
# Posted By Nathan Mische | 10/23/07 8:20 AM
thanks for being on top of this, I already have the previous document but I didn't know about the new version.
# Posted By Michael White | 10/23/07 9:48 AM
Thanks guys.

@Michael, do you know how long ago you got that previous version, even roughly? And is there a date of publication in the version you have? If you happen to have a moment to compare it to the CF7 doc, I'll just be curious if it's the same, and if not then it'll be helpful to gauge how long the document's been around and in revisions.

@Nathan, as for that "side benefit", no offense intended but I'd still argue it's pretty spurious. The trusted cache setting doesn't say "never read the source from disk". Any number of things can force it to refresh, not the least of which is a server restart. But also one can manually or programmatically refresh it. Finally, even during the life of the server, any given template can be flushed from the cache by the server itself to make room if the cache is full and it's the least recently used. In all these cases it will then reload the template from the source (or java class file if that's enabled, but again that's recompiled if the source changes also).

Given all that, there just seems no justification in even hinting that there's some security benefit to the trusted cache. I just fear that some see the word "trusted" and misunderstand it. It's about trusting that the version in memory need not be updated by any code changes on disk, such as in a production environment. It's about saving the time of looking to disk on each request to see if the source has changed.

Perhaps the option could have been named better, but too late now.
# Posted By Charlie Arehart | 10/23/07 11:15 AM
I downloaded it on 9-27-2007 but the title page says May 2007. the file size is 564k and it's 34 pages. the new version is only 282k but it's 47 pages.
# Posted By Michael White | 10/23/07 5:58 PM
when I looked at the properites of the pdf it says created 5/17/2007 4:53:01 pm (just before quittin time). also interesting is it says the application was Macromedia FlashPaper 2.01.2283.0
# Posted By Michael White | 10/23/07 6:02 PM
Michael, you say the "new version" is 47 pages. That's the CF8 one. I was asking if you could please compare your "older" one to the CF7 one that's also available (link above), which is 33 pages. So it seems your older one is 1 page longer than the "new" CF7 one. Curious. Maybe it was that discussion of trusted cached that was in the old one that was dropped in the new CF7 one. :-) Actually, can you check, please? Just search for "trusted cache". Thanks.

And thanks for the other info on the file properties.
# Posted By Charlie Arehart | 10/24/07 11:33 AM
no trusted cache mentioned in the document. sorry. it looks like page 34 just has a little footer garbage on it, so maybe they just cut it off.
# Posted By Michael White | 10/25/07 10:00 AM
OK, thanks. We'll let it be.
# Posted By Charlie Arehart | 10/25/07 6:34 PM
Hi Charlie,
I was looking for a place to give feedback and find any revisions.
Thanks for posting this.
I noticed that several of the 'best practices in action' examples wouldn't work as they're written.
They end up using a mishmash of code from different snippets used above.
For example in the authentication and session management section (p.28) the cffunction name="dbLogin" is used instead of "LoginUser" but only LoginUser is referenced from the Application.cfc file.
The access of this function is changed from public to private as well (I needed it to be public to make it work).
In that same function the cfarguments: strUserName & strPassword are replaced by uUserName & uPassword in the isValid regex.

I also found a typo in the cflog text they use #cfcatch.details#.
I think it should be #cfcatch.detail#, without the 's'. At least in for me using, cf8 with IIS.

I suppose someone might argue that the concepts in the examples are all correct and finding and correcting syntax errors helps the user better learn the concepts... but unless that's established as parameter for the whitepaper (ie. Your challenge: correct the code in the examples!) it's just a source of frustration and a gumption trap as Robert Pirsig put it.

Anyhow I think this might help anyone else trying to get started with this stuff.

Thanks too for your reminder about ColdFusion documentation and the WACK books.
# Posted By Vid | 2/13/09 1:15 PM
@Vid, thanks for sharing (and sorry for missing this when you posted a few weeks ago). It is a shame that there are not better ways to post feedback to online Adobe docs. Oh well. As you say, at least this will stand for those who do find it. Thanks, again.
# Posted By Charlie Arehart | 3/4/09 10:20 AM
Copyright ©2019 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting