structure of your application.
The open source community likes to make the point that security through
obscurity doesn't work. Just because someone says it doesn't make it true.
the methods I use to secure my site are open. hell you can go download the
udf I use to do url encryption right now to see how I do it. You can even
crack it if you take the time. It's a seed bump. Just like you have to
decide how much time and money your going to put into securing your
application or site, so does the intruder have to decide to go after you or
another weaker site.
Also not all encryption standards are widely available. As a matter of fact
in some instances it is illegal to let people know the detail of high level
encryption algorithms.
--
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: Tom Kitta [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 3:18 PM
To: CF-Talk
Subject: RE: RE: RE: Securing CF Apps.
I agree with Kwang Suh, security through obscurity is no security at all.
This is quite well known throughout security community and all encryption
standards available to the wide public adhere to it.
TK
-----Original Message-----
From: Kwang Suh [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 2:56 PM
To: CF-Talk
Subject: Re: RE: RE: Securing CF Apps.
> 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.
This would not be acceptable in many situations, because it prevents
bookmarking and renders search engines useless.
> >> 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.
What's wrong with:
<cfquery>
exec my_stored_proc
</cfquery>
?
> >> 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.
If I have complete access to your file system, this means that I can, say,
create a file that monitors tcp/ip traffic between your web server and db
server and sends the packets over to me where I can then scan for your
password. Or I could simply delete everything on the web server.
>
> 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
> yourapplication and it's data.
If what you're building is that important to secure, I recommend that you
never ever make it available on the public internet.
Obscurity is just one more tool
> you can use to
> do that.
I used to work with a security/cryptology expert. His #1 rule:
"Never, ever use obfuscation".
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
