> >> 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]
