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.

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 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.

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.

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.)

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

Hi Rick!

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.

A post on Mark Kruger's blog related to cfqueryparam and performance (based on Charlie Arehart's unconference presentation)
http://www.coldfusionmuse.com/index.cfm/2008/11/18...

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

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

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

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

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.

@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.

@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.

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 #.

For those looking for a queryparam scanner:

http://qpscanner.riaforge.org/

I can't vouch for 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'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.

@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.

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.

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.

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.

@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

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.