Obviously an ecommerce SITE (which is what Amazon is) needs users to be able
to return to a specific product.
Web services security is very different from either public site or
application security. You're comparing apples and oranges.
--
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 3:54 PM
To: CF-Talk
Subject: Re: RE: RE: Securing CF Apps.
I'd say something like Amazon.com is an application, and boy, would I ever
hate it if I couldn't bookmark a link to a book. Or their wish lists.
That's not a site.
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]
