-adam
> -----Original Message-----
> From: Tom Kitta [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 23, 2004 08:08 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]
