everything is an application. Web sites let anonymous users browse content,
while web applications let authenticated users perform actions that affect
other users/visitors.
The only part of amazon.com that is an application (of the stuff you can
see) is the checkout process, and you can't bookmark one of those pages.
Well, you can, but when you come back, you'll get a message that says "you
need to start over" or something like that, with a link back to the web site
portion.
Cheers,
barneyb
> -----Original Message-----
> From: Kwang Suh [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 23, 2004 12:51 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]
