>> seed (key)
>> every request. That way it is different every time
>What possible value does this bring?
If my user.login is encrypted one time as kjdfljsldfl and the user comes
back and types in kjdfljsldfl they don't get taken to that circuit, because
it's different this time.
>> 3. The objection to using cfquery is multifaceted. There is the
>> risk of SQL
>> injection if your not doing the correct validation. If your
>> errors are not
>> being handled correctly you can give away table and column names
>> in the
>> error message.
>So don't you think it's more important to handle errors properly than say
"don't ever use <cfquery>"?
I think that with all the benefits of procedures, if you have them
available, you're a fool not to use them, and not just because of the
enhanced security. Obviously proper error handling is important AS WELL.
This is not an either/or argument, rather a complimentary one.
>> 2. By using plain text variable names your going to give the potential
>> intruder a decent insight into your application design, and this
>> will give
>> them the ability to make educated guesses as to your other circuit
>> names.
>So?
So by understanding the structure of an application, you can then begin to
analyze it's weaknesses. In the environment in which I work we want to give
them as little as possible to go on.
>You've got bigger problems should someone gain access to your file system.
Is that so?? I disagree. If someone gains access to my web server they
have nothing. Now my db which is on the other side of a firewall, and only
accepts connections from specific ips, if they got in that it could become
problematic. Why? Because there are no user names or passwords stored on
my web server. There is no way to open a direct connection into my db
without having a user account on the db. Your rights and roles are also
stored in that db, not in the application, and so you would not really get
anything other than images and source code. You don't even get the code of
the procedure calls, and so you are still blind to the schema of my db.
Kwang, again, this is a layered approach to security. No one thing is going
to protect you from everything. You just continue to lock down things in
order to mitigate risk. You can never be without risk, and anyone who
thinks they have completely secured their site deserves to be attacked.
Listen man. You do whatever you feel comfortable doing. No more, no less.
But moving towards my CISSP and GSEC, having been a cyber threat analyst for
the last two years, and soon to be managing a federal CERT, I can tell you
this, there is always going to be some new exploit. It's going to be
something you didn't think of. But that zero day exploit isn't going to be
the one that does all the crazy damage. It's going to be some known
vulnerability that you could have prevented from putting your system at
risk. (slammer, blaster etc.) By duplication of your efforts, by
overlapping your protection you're trying to create a shell around your
application and it's data. Obscurity is just one more tool you can use to
do that.
--
Timothy Heald
Web Portfolio Manager
Overseas Security Advisory Council
U.S. Department of State
571.345.2319
The opinions expressed here do not necessarily reflect those of the U.S.
Department of State or any affiliated organization(s). Nor have these
opinions been approved or sanctioned by these organizations. This e-mail is
unclassified based on the definitions in E.O. 12958.
-----Original Message-----
From: Kwang Suh [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 2:16 PM
To: CF-Talk
Subject: Re: RE: Securing CF Apps.
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
