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]
