about a web site I can understand your point, however much of what we do are
actually applications ion the true sense, and not just sites. The security
of our public sites is very different.
--
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: Conan Saunders [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 3:03 PM
To: CF-Talk
Subject: RE: Securing CF Apps.
At 01:30 PM 3/23/2004, you wrote:
> >> 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.
Maybe that's true in your specific application, but I don't think that
practice has any security value for web applications in general. Trying to
conceal your application's structure (as revealed through the PUBLIC
interface of page paths, fuseactions, and URL/FORM variables) sounds like
an exercise in futility and security through obscurity.
I want my application's public interface to be as clear and easy to use as
possible. If a user is able to guess a concise, logically named URL and
find a page he wants, or hand-edit the value of a clearly named URL
parameter to obtain better search results, that's a victory for the user
and for me.
Does every single request to your site look like this:
"/index.cfm?aewuotijasdoijfj"? I don't see how that gains you much security
at all, and it's at the expense of a fair amount of user friendliness:
ability to bookmark; ability to type short, logical URLs; ability to
properly link to your application's functionality; etc.
As somebody said earlier, one case where you DO have a legitimate use for
encrypting URL/FORM variables is when you're outputing internal values
(database row IDs, etc) to a form or query string that will then be posted
back to your application, and you don't want the end user to see the
internal DB value. There, you are encrypting the VALUE, but not the
variable name itself.
Conan
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
