On Thu, Jul 16, 2009 at 12:12 AM, Michael Christensen wrote:
> - If you use cfqueryparams in your query, the query is executed as a prepared
> statement on the SQL server.
To be exact, it is send to the SQL server as a prepared statement.
Whether the SQL server executes it as a prepared statemen
>>An attack can be made
to inject SQL on a CF application using CFQuery that cannot be prevented
with cfqueryparam.
Well... it depends what you mean by "SQL injection"
One thing CFQUERYPARAM cannot prevent is inserting malicious content in
a text field,
like links or simply reference, to porn s
No, the queries written in those examples are patently stupid. Anyone
deliberately circumventing the protection that bind parameters provide
by subsequently forcing using those parameters to be used as literal
SQL gets what they deserve.
mxAjax / CFAjax docs and other useful articles:
http://www.
> > CFQUERYPARAM will prevent all SQL injection attacks
>
> This is demonstrably false. Semantics, arguments and opinions aside,
> spreading misinformation like this is irresponsible. An attack can be made
> to inject SQL on a CF application using CFQuery that cannot be prevented
> with cfquerypar
I believe that Brad Wood has made the case for that with his afformentioned
blog post.
Emmit
On Thu, Jul 16, 2009 at 8:48 PM, James Holmes wrote:
>
> Can you provide examples?
>
> mxAjax / CFAjax docs and other useful articles:
> http://www.bifrost.com.au/blog/
>
> 2009/7/17 Emmit Larson :
> >
>
Can you provide examples?
mxAjax / CFAjax docs and other useful articles:
http://www.bifrost.com.au/blog/
2009/7/17 Emmit Larson :
>
>>> CFQUERYPARAM will prevent all SQL injection attacks
>
> This is demonstrably false. Semantics, arguments and opinions aside,
> spreading misinformation like th
am. To paraphrase Uncle Bill, "...it must follow, as the
night the day, thou canst not then prevent a SQL injection
attacks with cfqueryparam".
Kind regards,
Emmit
On Thu, Jul 16, 2009 at 3:26 PM, wrote:
>
>
> Original Message ----
> Subject: Re: CF prepared s
app is
unilaterally protected from gremlins.
I do like how you said "explicitly treating data as executable code".
That's really what it's all about no matter what method/tag you use.
~Brad
Original Message
Subject: Re: CF prepared statements
From: Dave Wa
> You should know better than that, Dave. I'll always be here to point
> out the edge case--
If you use EXEC, EXECUTE, sp_executesql, whatever, you are explicitly
treating data as executable code. That's what those SPs and functions
do. I don't think that's an edge case; it's a different case e
Original Message
Subject: Re: CF prepared statements
From: Dave Watts
CFQUERYPARAM will prevent all SQL injection attacks.
You should know better than that, Dave. I'll always be here to point
out the edge case--
http://www.codersrevolutio
> And there are other kinds of attack CFQUERYPARAM will not protect from
> anyway.
CFQUERYPARAM will prevent all SQL injection attacks. There are other
attacks, and other remediation steps for said attacks, but I don't see
how that's relevant to this.
Dave Watts, CTO, Fig Leaf Software
http://ww
Do we have to have this same conversation once per week?
mxAjax / CFAjax docs and other useful articles:
http://www.bifrost.com.au/blog/
2009/7/16 Claude Schneegans :
> If it is only for SQL injection prevention, there are other means that
> do not make queries unreadable.
> And there are other
>>No, they can certainly have a bad effect on performance.
I must admit two things here:
1. I was more quoting many people here about performance than giving my
own experience,
2. personnally, I don't like CFQUERYPARAM, I use it only when really
necessary, ie. only on text fields
coming fr
> >2) could prepared statements have an adverse effect on performance?
>
> On readability, yes, but certainly not on performance.
No, they can certainly have a bad effect on performance. Cached
execution plans don't necessarily provide the optimal plan for every
set of parameter values. And you c
> LOL Dave, you crack me up.
Hey, cut me some slack, I was eating pierogies.
> As far as your first question-- like Dave said, the only way NOT to use
> a prepared statement is to drop the query param. Also, on this subject,
> dropping the number of max pooled statements to 0 or unchecking main
>>2) could prepared statements have an adverse effect on performance?
On readability, yes, but certainly not on performance.
~|
Want to reach the ColdFusion community with something they want? Let them know
on the House of Fus
dfusionmuse.com/index.cfm/2008/11/18/performance.and.cfqueryparam
~Brad
Original Message ----
Subject: RE: CF prepared statements
From: Dave Watts
Date: Wed, July 15, 2009 5:31 pm
To: cf-talk
1. No
2. Yes
Dave Watts, CTO, Fig Leaf Software
-Original Message-
From: Mich
1. No
2. Yes
Dave Watts, CTO, Fig Leaf Software
-Original Message-
From: Michael Christensen
Sent: Wednesday, 15 July, 2009 18:12
To: cf-talk
Subject: CF prepared statements
Okay, so here's how I figure it works:
- If you use cfqueryparams in your query, the query is executed
Okay, so here's how I figure it works:
- If you use cfqueryparams in your query, the query is executed as a prepared
statement on the SQL server.
- If you don't use cfqueryparams, the query is not executed as a prepared
statement.
Am I right so far? If so, here's a couple of questions:
1) can
19 matches
Mail list logo
