A few days ago I blogged about a list of PHP vulnerabilities and how they applied to ColdFusion users as well. With that in mind I've created a one page resource for ColdFusion users:
ColdFusion Security Checklist
If you ever forget the URL, just check the Guides pod to the right. Let me be absolutely clear on this:
Security is not a task item.
Security is not something you can tack on at the end.
Security is a way of life, a religion. You need to keep it in your head from the very first day a project starts until the end of the world.
So please keep the above points in mind. I made this checklist as a simple high level reminder of things to keep in mind. I can imagine a manager sharing it with his or her employees. It is not meant to be a book.
The unfortunate thing is that even this simple list is ignored by far too many people.
I know that some people will disagree with some of the items on the list. I've already taken some feedback from folks, but it will never make everyone happy. At the end of the day, I hope the list provides some guideposts to at least a) steer you in the right direction and more importantly b) keep security in mind as you develop.
Archived Comments
Ray,
Thanks for providing this resource.
I am curious about your thoughts on keeping the username/password out of the DSN. I understand the purpose is so that someone needs to know more than just your DSN to access your database.
In my experience, I am either on shared hosting where that option isn't available or on a dedicated machine where the issue doesn't seem to apply. What am I missing?
You might also want to add that you shouldn't use the sa user in SQL Server for your ColdFusion DSN.
Steve, that was the idea. Having the U/P in the dsn means anyone can use it, if you aren't using sand boxes.
To be honest, I may remove this item. It has caused the most contention.
do you have links to separate presentations/articles you may have given/written on validation? I presume you have an enormous repository somewhere... perhaps in the central computer on coruscant?
Actually, it occured to me last night that I do not have a list of presentations. It is on my TODO list.
Ray, for what it's worth, I really agree with not putting the password in the DSN.
There are other reasons for doing so in addition to security. In our environment we have many multiple applications with their own database in only a few servers. (So many databases, few servers) By not putting the database info in the DSN we only have one DSN per database server.
Terrence, is there a reason that only having one DSN per database server is actually a significant consideration?
Does this mean you have a bunch of DB usernames and pwds being stored in plain-text somewhere, so they can be used as arguments in <cfquery> parameters?
--
Adam
Absolutely.
Before, you tell me how bad an idea that is, understand that my environment may be very different from yours. We host our own machines. Only people from my company have access to the development and staging boxes. No developers have access to production boxes, except through a code publisher. All SQL accounts are given out with the only read write access. Our datasources don't allow grant, drop, add (and in some cases they are only able to call stored procs.)
In my environment, our setup allows us a lot of flexibility with a little bit of risk.
Hi Terrence.
I wasn't suggesting anything was bad. I was asking... [well: read my posting, it's clear waht I was asking].
You don't seem to have answered by questions. Or I'm not understanding how your response answers my questions, anyhow.
--
Adam
I'm sorry Adam. I got sidetracked.
I like having only datasource per database server because we usually have one database per application, and about 50 separate applications per server, across 3 distinct development environments.
So that at one datasource per application, it would be around 150, as opposed to the 10 we actually have. (two SQL development servers, two SQL production servers, then some various for apps on servers I don't control.)
So managment of all of those datasources is much less work, when it is 1 per server.
Hi Terrence.
I think what you say is fair enough for your environment (although I don't exactly know what additional management there is as far as setting up a DSN or setting up a user in the DB, but anyway). And I still question whether the potential security holes you're creating are worth the "convenience" to you of not having to set up DSNs. Mileage varies, though, so let's agree to disagree.
Your situation hardly describes the "most common situation" though, does it? And surely that's the audience that Ray's doc would be targetted at?
I think *generally* (ie: in most scenarios where one site = one DSN), it is Very. Poor. Advice. to suggest what Ray is suggesting.
I - respectfully - ask Ray to remove that advice from his document, which is otherwise spot on.
--
Adam
Adam, to be clear, you object to the moving of the u/p out of the DSN and into cfquery?
This is definitely a contenious point for most of the readers. I think it's about 50/50 which may be as good as we get.
I do think I address the concerns in the entry, so I think it's ok as is.
Sorry, yes you do.
I didn't (re-)read the entire paragraph.
--
Adam