-adam
> -----Original Message-----
> From: Matt Liotta [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 23, 2004 10:15 PM
> To: 'CF-Talk'
> Subject: Re: Securing CF Apps.
>
> Where do people get the idea that adding hassles to the user makes
> anything more secure. It's like our nations airport security. Making me
> jump through hoops and delaying me doesn't make things more secure; it
> pisses me off. It is possibly to have strong security and provide an
> application that meets the users' needs. Taking away bookmarks, back
> buttons, etc. doesn't do that.
>
> -Matt
>
>
> On Mar 23, 2004, at 2:23 PM, Heald, Tim wrote:
>
> > Here's my take on it.��You layer security on like an onion.��In many
> > cases
> > you protect against the same kinds of attacks many times.��I don't
> > want a
> > user to get to a specific area of my site unless they are logged
> > in.��Ok so
> > I check a session or client variable that I set upon login.��Well I
> > have a
> > user that has logged in and gotten to my page.��Now they book marked
> > the
> > page.��Well written correctly since their session doesn't exist I
> > send them
> > to the login page.��However I personally would like to take it a step
> > further.��I don't want people to be able to bookmark pages in my app
> > at all.
> > Also I don't want them to be able to figure out the structure of my
> > application because I used plain text, easy to understand names for
> > the
> > different sections of the app (in this case circuits).��So I encrypt
> > my url
> > variables.��Why?��They don't get any information about the structure
> > of my
> > app, or about the information I am passing between pages.��When they
> > book
> > mark the site the fuseaction is gobly gook.��Means nothing and kicks
> > them to
> > my home page or login or whatever.��Ok, what else is involved here?
> > Validation.��Both client and server side.��You use client side
> > knowing that
> > it is easily defeated by turning off _javascript_s, but you use it to
> > keep
> > from hitting the server.��Then you do it again on the client side to
> > make
> > sure that nothing got by.��In 90% of the cases they user will have
> > _javascript_ enabled and it will have saved some of your server
> > resources.
> > Now you have communications between the db and cf.��What can you
> > do?��Well
> > for one you use an actual db user account to validate
> > people.��Why?��Because
> > then you can limit what actions the user can take, not only through
> > the
> > application, but through the db as well.��Also your not storing a
> > username
> > and password anywhere.��Someone said earlier that means they can open
> > up SQL
> > + or enterprise manager and login to the db, well this is true, but
> > they are
> > only able to see and do the same exact things that they would be able
> > to do
> > through your application, if the DB is locked down correctly.��In
> > oracle at
> > least you have to be granted rights to even know if a table
> > exists.��I can
> > have a user table, but if you don't have select or whatever other
> > privileges, you get a table not found error.
> >
> >
> > In the past we have made many mistakes in security.��I am sure that
> > we still
> > make many as a community.��New exploits are announced daily.��Most of
> > the
> > things that we are trying to protect against aren't even used anymore
> > because in general developers learned form their mistakes.��Does this
> > mean
> > we should stop doing them?
> >
> > --
> > 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: Heald, Tim
> > Sent: Tuesday, March 23, 2004 2:05 PM
> > To: CF-Talk
> > Subject: RE: Securing CF Apps.
> >
> > 1. If your properly encrypting the url your going to change your seed
> > (key)
> > every request.��That way it is different every time
> >
> > 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.
> >
> > 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.��Also should someone gain access to your file system
> > they can
> > build a pretty complete picture of your database from the
> > queries.��You
> > can't do this when all you are using is Stored Procedures, especially
> > if
> > your variable names don't match your column names.��Throw in views
> > and you
> > can obscure it even more.
> >
> > --
> > 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 12:55 PM
> > To: CF-Talk
> > Subject: Re: Securing CF Apps.
> >
> > > My issue with <cfquery> is that you are exposing your db design.
> > > It's alot harder to hack a db is you dont know the table and
> > > column names.
> >
> > huh?
> >
> > > As for encrypting the fuseaction, the question is why not?
> >
> > Because it's useless.
> >
> > Let's think this through:
> >
> > I have a fuseaction called "products.list"
> >
> > It encrypts to "wafiawjfw"
> >
> > I type in "wafiawjfw" in the url.
> >
> > It lists the products.
> >
> > Where's the security?
> >
> > Users
> > > can start throwing errors by trying different fuseaction calls.
> > > Which in turn could expose too much info if you dont have a site
> > > wide error handler.
> >
> > Let me get this straight.��I should waste time encrypting urls, and
> > yet be
> > stupid enough not to have an error handler.
> >
> > Let's think this one through:
> >
> > I type in "wiejfiawefijwf", which doesn't decrypt properly.
> >
> > The site then throws an error, and since I don't have a site wide
> > error
> > handler, it exposes a whole bunch of information.
> >
> > Where's the security?
> >
> > The topic of this thread is securing cf apps.
> > > Although it may not be 100% necessary, it sure doesn't hurt.
> >
> > It doesn't help either.
> > ��_____
> > ��_____
> >
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
