I don't have any links handy, but I'm sure you'll get some posted.
Basically SQL injection attacks, or nasty code of various types, can be
input by malicious users on forms or passed via url vars. Regarding
using cfqueryparam, here are three examples for three common db ops.
In a select:
<cfquery
name="Blah"
datasource="#request.SiteDSN#">
SELECT
filename.EditLevel,
filename.ParentID
FROM filename
WHERE
filename.ID=<cfqueryparam cfsqltype="CF_SQL_NUMERIC"
value=#url.ID#>
AND
filename.SubFilter=<cfqueryparam
cfsqltype="CF_SQL_VARCHAR" value=#client.SectionFilter#>
</cfquery>
In an update:
<cfquery
datasource="#request.SiteDSN#">
UPDATE filename
SET
filename.PageText=<cfqueryparam cfsqltype="CF_SQL_LONGVARCHAR"
value=#form.PageText#>
WHERE
filename.ID=<cfqueryparam cfsqltype="CF_SQL_NUMERIC"
value=#client.EditMarker#>
</cfquery>
In an insert:
<cfquery
datasource="#request.SiteDSN#">
INSERT INTO filename
(
ParentID,
PageText,
ModBy
)
VALUES
(
<cfqueryparam cfsqltype="CF_SQL_NUMERIC"
value=#client.EditParent#>,
'Text Message Here',
<cfqueryparam cfsqltype="CF_SQL_NUMERIC"
value=#client.Producer#>
)
</cfquery>
--Matt Robertson--
MSB Designs, Inc.
http://mysecretbase.com
-----Original Message-----
From: Ian Skinner [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 31, 2002 8:35 AM
To: CF-Talk
Subject: RE: User Name/Password Concepts
Thanks for all your responses. A long summary of all the information
I've
currently received with questions throughout to follow.
Fregas, thanks for the information about Authentix. Unfortunately this
site
is being built and launched on a thread-bare, shoe string budget. All
the
available monetary resources are pretty well allocated. But I will
defiantly look around when we start actually picking our hosting company
to
see if they offer it as a package as Chris White suggested.
As to ULR/FORM attacks, could somebody provide some good
information/resources on what these actually are, and how to properly
use
the CFQueryParam and CFProceParam to avoid them. I've read about this
best
practice several places, but they never really went into specific detail
on
what the Hacks are, just that you should do to prevent them. I find
it's
much easier to write proper code, if I know exactly what the purpose is
supposed to be.
To answer some of Van Dieten's questions.
What is Secure: This is going to be a Commercial, Paid, Membership Only
type site. What I want is enough security to reasonably protect our
paid
content from too easy swiping as well as user abuses such as sharing
logins
with other un-paid members. Also, what are some other user abuses of
which
I may not have considered?
But these security issues must be balanced with Usability. We can't
have so
much security, that we turn away too many potential customers due to the
difficulty of registering and/or login to our site. That's largely
where
I'm asking the community for advice. What kind's of security measures
have
the most bang while at the same time the most transparency to the user.
And
what kinds of usability do these same Users expect from their security?
What is Digest Authentication? That is a new term to me.
Smartcards? what are Smartcards in this context? I don't think I have
one?
Is this something the general consumer is going to have, or more of a
corporate ID/Security type thing?
Single use passwords are probably not the way to go for the entire site,
but
we may use it for a one time preview type thing. We are trying to sell
this
service, and that sounds like it would turn away customers, but let me
hear
if anybody feels otherwise.
As Chris White suggested, I am considering minimum length User Names and
Passwords as well as requiring stronger passwords with mixed cases
and/or
special characters. My question is balancing security and usability
what is
the minimum characters I should allow. How strong should I require the
password be, without turning away too many customers by making the
registration process an ordeal.
The paid account is going to be good for one year, so requiring a new
password every month is probably a bit extreme. But again I would love
to
hear opinions on this.
As to allowing only one user to log in, this I had already planned on
using.
I would love to hear some technical ideas on how to accomplish this?
How do
I check who is currently logged on? How do I blow away the extra user
(new
or old)? What else should I consider, such as browser crashes?
Multiple
open browser instances? Multiple versions of browsers (IE, Netscape,
Opera,
ect)? If I wanted to log this kind of activity to watch for
concentrated
Hack attempts, what should I be looking for?
Thanks to Dwayne Cole for his great list, I would love if this became a
15
or more message thread. One of the reasons I came to this community, is
that I wasn't really finding a good resource for this kind of
information
that told you what you need to do, how to do it, and what impact this
may
have on a commercial site all in one place. I would find pieces of the
puzzle here and there, but it would be great to have a summary of it all
and
how the different pieces can be fit together.
Luckily the security requirements are pretty simple. We are only going
to
have two kinds of users, Trial and Paid. A paid user has access to the
entire site for one year. The Trial user would have access to one
section
of the site of his choosing for a certain period of time (one day, week,
month) yet to be determined. For the trial user, I was planning on
using
one time usernames/passwords automatically generated and mailed to an
e-mail
account. One time per e-mail account only. Now, if somebody really
wanted
to, they could get e-mail account after e-mail account and eventually
gain
access to the entire site, at least for a short time. But at only 10 to
15
dollars a year for membership, it's their time their wasting.
I would like to know more about encrypting links and Form fields, and
securing SQL statements. What am I looking for here? What am I trying
to
prevent?
Finally to address Christian Cantrell's suggestions. Concerning the
logout/logoff function. As well as providing a button, can anybody
comment
on the ways and problems of providing some kind of automatic logoff if a
users closes the browser and/or leaves the site? I read of one idea
where
the site was contained inside a "Frame" HTML element and the frame had
an
"on close" event to run some JavaScript to logoff. Would this work?
Could
it cause any potential problems? Are they other ways I might do
something
like this?
When determining how long to set the session expiration. Can some of
you
provide some experience on what is a good length is that balances
usability
with security? I could easily just pick a number (5, 10, 20 minutes).
But
I have no real reason to pick from one or the other.
Thanks for the suggestion of using the Hash() function. I had forgotten
that one. As I understand your comments, there is no way to every
unhash
the string. So, for a lost password function, I would have to assign
and/or
require a replacement, correct? There would be no way to send the old
one.
If I don't provide a remember-me function, what are some opinions on how
this may affect the usability of the site from the consumers point of
view?
A question of my own.
Are there any issues or concerns I may not know about using
Application.cfm
for security validation? Are there any known hacks to bypass the
running of
this file and getting directly to the content pages?
Thanks again for all your comments. I look forward to reaching that 15+
thread.
Ian Skinner
ILSweb
[EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
