Some parts of an "application" can be public facing, you know.
How about Web Services? Are those an application? Well, I can sure tell you they're not a site. Should I be obfuscating those links too? That sure would suck.
----- Original Message -----
From: Adrocknaphobia <[EMAIL PROTECTED]>
Date: Tuesday, March 23, 2004 1:43 pm
Subject: Re: RE: RE: Securing CF Apps.
> You do realize we are talking about applications and not websites.
> There is a big difference, and I've never once found it a good
> idea for a user to bookmark a part of application.
>
> -adam
>
>
> > -----Original Message-----
> > From: Kwang Suh [EMAIL PROTECTED]
> > Sent: Tuesday, March 23, 2004 07:55 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]
