I don't really like it. I know a ton of developers who in no way escape or set security, so I guess it would help out in that case. But I am using some homegrown cfcs which handle all of the queries (so no cfquery tags are used in the site other than in the cfc), and a ton of homegrown escaping, so there is not any worry.

I know that there are a lot of people that do that. How can you penalize that, especially since that is meant to help with security.

Draconian? Probably... but CYA usually overrules that.
He has to protect his business. And there is nothing like a little SQL injection to kill your server.

As long has he is "gentle" in his explanation he will be ok. Those that aren't using queryparam probably don't know it exists and will appreciate the education. He just needs to be prepared that he will have to work with some of his customers.

He should probably have an updated TOS to also CYA... :-) (You can tell I'm paranoid)

I think this is a bit draconian. There may be third-party code being used that aren't cfqueryparam'ed, but said user isn't always aware of that fact. Is it their fault that other programmers writing these 3rd party code weren't careful enough to use cfqueryparam tags where needed?

I think the question to ask is, can poor SQL hurt the HOST at all? Or just the given user. I think if there is a possibility that poor code endanger the hosting infrastructure, then its not excessive. However, if this is just done to enforce best practices, that's a bit nuts - I am all for letting people shoot themselves in the foot if they want that.

I would have no issue with it. SQL injection attacks can reek havoc on the entire server -- which would affect everyone using that server -- which woudl affect his business.

If someone has an issue with it, they can go elsewhere.

In the past 4 months I have had 3 clients who were badly hit by SQL Injection attacks so I have seen the devastation that this can cause. There is no excuse and really never was any for not using CFQUERYPARAM.

I actually don't think this sort of move is too extreme. And we should not forget that using CFQUERYPARAM also delivers performance benefits.

Not all queries use user accessible scopes as parameters as well. cfqueryparam has no "protection" effect in that case. It may be a legit query with no vulnerability.

Luckily I am not in that situation, but my understanding is that there are new web firewalls for sqli type things as well. Plus http://portcullis.riaforge.... could be made mandatory for those who are known to be sloppy.

Draconian would be shutting down access to the sites in question until it is fixed.

Or, draconian would be saying that queries without cfqueryparam will be manditorily debugged and vetted by hosting staff at a rate of $150/hr.

This? This is just good business.

(And using someone else's code isn't an excuse. If it's on your site, you are responsible for it.)

Although I completely agree with the premise, it seems like a losing battle to me.

What about
cfcompile -deploy <webroot directory> <directory to compile> <output directory> or cfencode??

Will this magic scanning tool catch everything?

Wiat..Rick O and I agree on something? Maybe I should rethnk this...

Hi Rick!

I would never use a host that did something like this.
In fact, I would never use a host I had a suspicion of looking at my code in the first place. The code is my property, they are only giving me a place to execute it.

I would argue that if your code can potentially cause damamge to the host's server, then the host has ever right to do so.

I don't see how a shared host that was doing things right on their own end (sandboxing, etc) could be adversely affected themselves by the lack of a cfqueryparam. If you have a sql injection attack that's the clients problem, not the hosts. Maybe the site starts taking more resources than they otherwise would, but how do you know what's normal in that situation?

Again, I would argue that the host has no business looking at the code of a client in any circumstance except when the client has asked the host to do so and given them explicit permission. (I know there are some hosts out there that will do consultant work or help out with a site, I'm not talking about that sort of situation).

My host is not signing a non-compete, NDA or waiver to get me as a client. How do I know they aren't copying and using my code, selling my code, taking my ideas, etc?

Just my 2 cents.

A post on Mark Kruger's blog related to cfqueryparam and performance (based on Charlie Arehart's unconference presentation)
http://www.coldfusionmuse.c...

Basic summary, use cfqueryparam, but take care in how it's used to avoid potential performance issues

While I completely understand why your friend headed down this direction and the arguments supporting his position, I think it's over the top. If, as was mentioned earlier, you cannot setup your shared host to properly isolate sites/apps, then stop hosting.

CFQP may be a best-practice (and I use them extensively and see the huge value in them), don't freaking tell me how to code! I'll write my own applications as I want! Whether it's spaghetti code or a perfectly built OO application, or anything in between, it's my code (as Ryan G mentions).

What's his next step? Shutting down servers that contain HTML tables for layout?

Hey, don't knock tables for layout man. That's going too far!

Good move. This could help many developers who simply don't know about cfqueryparam become better developers.

If you are going to have a hosting business where people pay you to host their work, then you have to take the good and the bad. Telling people that they have to code a certain way or you won't allow them to host their work is done right dumb from a business perspective. The best thing to do is to move these people and their databases to another server and notify them that not using cfqueryparam could cause their site to be hacked and that's it. The action your "friend" is taking is childish

You don't see companies like hostmysite.com telling their customs to do this.

@tp: Heh, I love you put friend in quotes. He _really_ is a friend of mine. :)

I'm with the people that have said that this is a red flag that the host doesn't know how to sandbox things properly, and my code and data is at risk from corruption or theft by other customers of the host.

Time to find a new host.

While some of your opposing points are valid, your making the assumption that we are a shared hosting provider. We aren't.

We are a boutique host that specializes in application monitoring, support and certification compliance. We monitor errors in real time and provide code correction when warranted.

9 out of 10 times, we are responsible for cleaning up the mess that someones code has caused. Chances are, the developer is no where to be found at 4am.

In simpler terms...
If you clean houses for a living, you don't want the customer who's dog craps all over the carpet and leaves you to clean it up.

While most of your complaints are valid to some degree I'll address a few directly.

Everyone - We are well aware this is no protection from everything. We just believe that enforcing best practices is in the best interests of all of our clients.

Rick - We'd be happy to secure your application at a cost.

Ryan - If you are hosting with us, your code is accessible by us. That's why your with us in the first place.

Josh - We do offer Web Application Firewalls. If you can afford it, were happy to give it to you.

Tony - Actually... no. We don't have to take the good with the bad.

Point blank. Its our environment and your choice.

You are right that its your environment - though its not necessarily a great business practice, but if you want to really piss off your customers then that's your call.

If I had a site hosted by you (who knows, maybe I do since this is anonymous!) and you threatened me, I'd pull my business and site. Not so much because I disagreed with you, but because then I'd be thinking... what next? Are you putting my site through every possible security scan (cross scripting, etc.)?

As for your comment about "if you are hosting with us your code is accessible by us"... would you read your customers' emails, too...? After all, they are on your servers as well. Do you state in your contract that you are going to do this with/to your customers? If not, you might want to rethink your approach.

@Peter

I think you skipped over the entire part where I mention that that's what we are payed for.

The entire reason you would host with us is because we will maintain your code for the health of your application.

No need to rethink our approach.

It's all dependent on who has to deal with the issues. If I have to deal with someone issues, then the iron fist is coming down.

But if the environment is self contained where you're responsible for your own stuff... then do whatever you want.

@Peter - at the risk of putting workd into Ray's friend's mouth. I think the point he was trying to make about 'stealing code' was that if they were going to be dishonest enough to take the code in the first place, scanning the code would be the least of your worries (if you hosted with them).

When I had my sites on a hosted service, the sites would go down frequently. After many calls (from many people) the hosting provider discovered that teh issue came from one site that would hoard all the resources on a regular basis. If I was still in that environment, having my code scanned so that other's bad code can be found would make me feel all warm and fuzzy inside.

Well... I'm interested in the original question... how to find code that doesn't use cfqueryparam... we have tons of old code that I'd like to find and clean up. A little help here?

You could write something that recursively (cfdirectory) goes through your folders looking at .cfm's and .cfc's.

Then within each file (cffile action="read") FindNoCase'ing instances of cfquery's

Within each cfquery, Find() any instance of '=' and 'like', then advance to the first non-space character, and if it's not a '<' then a cfqueryparam is not being used.

Whenever there's a hit, dump that to a log of path/file + line #.

You would want it to be smart enough to only flag the variables that come from user inputs. There is no reason to flag variables that are being set by the application itself if you are only talking about security concerns. It is also possible to securely code without using CFQP. I think a program like this would put some people in the position of having to revisit a lot of code unnecessarily.

For those looking for a queryparam scanner:

http://qpscanner.riaforge.org/

I can't vouch for this.

I would not use a host that does this for several reasons:

cfqueryparam is not the only way to protect against sql injection attacks, and there are valid reasons to not use cfqueryparam (or other flavors of prepared statements).

In a cfc I might scrub my data to a greater degree than cfqueryparam would do ( eg: escaping html,escaping punctuation ).

I would be very concerned that another "Best Practice" directive would be instituted. Best practices tend to evolve over time.

Ultimately, if forcing the use of cfqueryparam is more important than potentially losing customers go for it. If your current customers are ok with this, go for it. If you are willing to lose potential new customers, go for it.

I doubt a large hosting company would ever do this.

many [shared] hosting providers restrict the use of certain cf tags and functions (like cfexecute, cfregistry, createobject(), etc; i have even seen cfdirectory and cffile in some extreme cases!). for obvious reasons. i do not see why the opposite - enforcing the use of <cfqueryparam> where it is a must - should be looked at diferently.

yes, if you must use <cfexecute> in your application, you won't host your app with that provider. same here: you do not want to use <cfqueryparam> - find a different host, sure.

i am all for officially equating not using cfqp when it is a must to having malicious code hosted on your site!

however, of course, any case of not using cfqp must be carefully examined for actual need of using one. one can't just blindly require it be used in each and every query.

my 0.02$

I think this is entirely reasonable in a shared hosting environment, where everything on the server could be affected by a security breach. As Azadi points out above, shared hosts disable all manner of tags and functions and the logic behind insisting on cfqueryparam is no different.

I'm curious, what would this company do for any client who chose to encrypt their coldfusion files? Automatic blacklisting? Would they decrypt them just to check if cfqueryparam was being used?

Because encrypting my files would probably be my first reaction if I heard my hosting company was going to examine all my code for defects.

I think it's perfectly reasonable for the hosting company to do this because your once perfect site is now attacking random visitors with your hacked code.

What I would rather see, though is something from Adobe that would make it take extra effort to bypass the parameterization process instead of the other way around.

@The Guy

I noticed the part about you being paid. So it comes down to one simple question: are your customers paying you to shut them down if they don't do what you tell to in terms of cfqueryparam?

What I'm simply suggesting is that its a questionable business move. I understand about resources being hogged because of bad SQL injections killing or screwing with the db. There may well be a better way of achieving your goal is all.

From The Guy's comments, it's obvious that he's running a specialized type of webhosting service where they focus on application/error/code monitoring. So their customers go into business with them KNOWING that their code will be accessible to the host. So duncan's question about what they would do if a customer chose to encrypt their files makes no sense because they simply wouldn't take any customers who wanted to encrypt their files.
If this policy was coming from a general web hosting company (like HostMySite, for example), then yes I would say it's a bit draconian. But with this particular company, this policy actually seems very consistent with their business model (i.e. protecting their customers from their own code)

I think it is perfectly acceptable to enforce a policy like this, since we all know using queryparam is a fundamental part of CF, where queries are involved. It is no different than hosts popping on the sandbox and disabling cfexecute and cfregistry imho.

@The people saying you would lose money from driving people away. I think this impact is less than the people you would lose from their db connection/cf connection constantly being down, hung, or messed up. I've left many hosts where CF constantly hung like a dozen times a day because of other people's bad code on the machine.

In one case the host had fusion reactor and had spotted the problem. They said they were in communication with the customer to get it fixed, but had no recourse to disable it temporarily themselves. I took this as not being proactive enough and dropped my account there after a week of it not being resolved. It's all trickle-down. The people I had put something up for would then be mad with all the downtime etc etc down the line.

Perhaps a more customer friendly solution would be to do a vulnerability scan for sql injection using a tool like HP's Scrawlr http://www.communities.hp.c... . This is a free tool. There are other vulnerability scanners out there as well.

If a vulnerablility is found, you can let the customer know, and provide a solution for them. If not, there is no need to force the use of cfqueryparam against their wishes.

I work for a printer and we check every piece that comes through for a variety of criteria: technical specs (dimensions, color, bleed, other fun stuff) content (there are limits to the amount of flesh that we'll print), and we'll even point out spelling errors.

While it is unlikely submitted work will cause physical damage to the presses or bindery equipment, jobs can hurt the company and its brand. There are limits of what we'll run that are probably incredibly fuzzy and gray, but they still exist.

Every company that provides infrastructure support to another organization's message has to decide what the limits are. That Ray's friends has decided that his group doesn't want to host a group of victims-in-waiting is an interesting business value proposition that is sure to be received in mixed fashion, like it already has been here.

However, whether you host with this company or another, it is incredibly naive to believe the information hosted on another system is not subject to review by 3rd parties. Not least of which, almost all hosting firms have an acceptable use policy concerning the content being hosted and it can only be enforced if the service has the ability to inspect said content.

I agree with some earlier comments concerning CYA and updating TOS/AUP as, in general, I think transparency is the only sane way to deal with customers.

they should just block cfquery and then they won't have to worry if the programmers are using cfqueryparam or not. the site will be infinitely safer then....

As someone who hosts Coldfusion sites and SQL server. I personally have never seen a SQL injection attack that affected the entire server. The damage is limited only to the areas which each site has access to and controls are in place to stop DOS issues that can happen after a successful SQL injection attack. I can also say that while the use of cfqueryparam is a "no-brainer" in most cases that it also DOES NOT protect against all known SQL injection attacks.

A slightly less confrontational approach would be better for business in the long-term.

@Posted By The Guy Rays Talking About please post who your company is! Stop ranting about the best practices and lets see how your business does

I don't really see a problem with them doing it, if they put it in their service agreement.

For some reason it strikes me kinda the way smoking bans do. I am completely against the idea of legislated smoking bans (if every host was forced to do this), however I fully support a restaurant owner deciding whether or not the business allows smoking (where this host does not). The people then can use the policy of the restaurant to contribute to them making there dining choice (do I want to host there or not).

Personally, I think they should *kinda* implement it, Ie. leave some flexibility for code that might fail an automated check, but pass a "this logically doesn't need it or can't use it" check.

other things to consider...

searching for absence of cfqueryparam will reveal queries that are not using it but doesn't really mean the code is bad.

cfqueryparam was created and designed to define a parameterized query and execution plan. As such there are many many cases where it is actually not a good thing to use cfqueryparam. using cfparam to define type on a variable is probably more or just as secure as using cfqueryparam.

securing queries is not the reason this tag exists. it is unfortunately used as a lazy or uniformed developers method to secure unclean code.

validating and cleaning your users input is ultimately the only way to address security.

using cfqueryparam may, in most cases, prevent sql injection, but the code is still dirty and results in sql statements being saved in your database fields, which can result in other unexpected data later.

The short answer is no.

Although we all know how bad coding can cause a major security problem here, there are cases where I can wrap the query in a function that is type cast.

This eliminates the need for cfqueryparam, and although there are other benefits from using this tag. It is not upto one individual to tell us how to code.

I for one will never use a host that does this. That would be like saying here is your house, but it has to be built using timber only as thats what we want for this area.