> Any time you construct a query in CF, use cfqueryparam. As
> long as the
> DB supports bind parameters, the query is safe from SQL
> injection.
> Regardless, you still should validate server-side anyway.
> On 3/10/06, Oleg Gunkin <[EMAIL PROTECTED]> wrote:
>> I am trying to validate simple data like dates, emails to
>> prevent clients from dropping my database tables even if
>> they really want to.
That's true unless you use variables to construct portions of the
query which can't have cfqueryparam applied to them, i.e.
<cfparam name="join" type="string" default="right">
<cfquery>
select ...
from table1
#join# join table2 on (...)
</cfquery>
Although most queries don't need to use techniques like this, but if
you use a technique like this, then you need something other than
cfqueryparam to ensure the string is appropriate and not dangerous.
(The onTap framework's sql abstraction engine checks to make sure
tables and columns exist before generating the query, which eliminates
the possibility that these values could be used for sql injection --
the only exception is the order by argument which the documentation
says should never be populated with user data -- users can provide a
sort argument to override the order by, which is tested to prevent
injection)
However, for standard ColdFusion queries where only the values of
columns are dynamic (and not the structure of the query) then
cfqueryparam will protect you completely from sql injection attacks.
This is entirely separate from the issue of form validation, and no,
<input type="hidden" name="otherfield_date" /> is not secure and I
don't recommend using it. Though if you're diligent about using
cfqueryparam (which you should be anyway) even if you do get a
malicious user who changes the form, they won't be able to perform sql
injection by removing your form validation. That being said, I still
wouldn't use the hidden input elements (which is what the new cfform
features in CF7 use for server-side validation, so they're not secure
either), not to prevent sql injection (because that's handled
separately) but rather to prevent a malicious user from receiving a
ColdFusion error as a result of having abused the form. There are two
reasons for not wanting this 1) although it's a good idea to use a
cferror template or sitewide error handler to suppress the default
error display, these aren't always implemented and can provide the
malicous user with information they shouldn't have (whether it's
useful to them may be another story) and 2) even if the error message
isn't helpful to them in hacking your site, I'd rather not give them
the impression that the site might be hackable by letting them disable
validation on an input element.
My advice would be either become very friendly with isValid() and use
that exclusively for form validation, or find or build a tool or
framework for form validation. The onTap framework has one built in,
which may give you some ideas even if you don't necessarily want to
use the whole framework. There's also TerraForm which was written by
Matthew Walker and is not phenomenally expensive.
s. isaac dealey 434.293.6201
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234962
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
