I'm a little bit late on this topic, but I thought I would throw in my .02
anyway.
You have a great point Kevin. Encrypting your fuseactions is like using a
twisty-tie to lock the doors at the pentagon. In my opinion, security starts
from within. That is, start your security initiatives at the most basic
level (server) and work your way out to the top layer (application).
All the suggestions I've read on this thread are great. I just wanted to
point out that there are many different factors when dealing with security.
So, I guess I'll pose this question: What types of security issues have
people run into? Knowing this might help us, as a community, come up with
different ways in securing our applications.
Maybe Michael could start a CF_Security list...
Mark
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 29, 2000 6:32 PM
To: Fusebox
Subject: RE: Encrypting FuseActions
Encrypting fuseactions creates obscurity but little security. I grant you
that a curious party probably couldn't get anywhere by casually guessing
fuseactions. It seems, however, that if you are relying on 'undocumented'
fuseactions for security, you're deluding yourself.
If somebody _really_ wants to know how your site works, they will page
through and track changes to the URL string (at least that's how I'd
start). Whether a fuseaction is an easily decipherable word or an
encrypty-looking string, the site 'behavior' is the same. Not too tough to
figure that out and go from there. I'd start with security based on
sessions (cookies or URLToken), SSL encryption, and good user passwords
before I worried about encrypting fuseactions. If you've got a decent idea
of who your user is, then you protect your data at the application level.
Alan's suggestion isn't too bad as long as you don't expect anyone to link
to a 'page' with an expired fuseaction. No bookmarks, no search engines,
no outside links -- might be useful for an intranet application scenario.
I'm not suggesting that internet security is easy, I'm just not convinced
that the protection from encrypting fuseactions would be worth the effort.
regards,
Kevin
--------------------------
Kevin Marshall
Certified ColdFusion Developer
eCalton.com, Inc.
Vero Beach, FL
www.ecalton.com
[EMAIL PROTECTED]
561.569.4500
amccollough@a
nmc.org To: Fusebox
<[EMAIL PROTECTED]>
cc:
11/29/00 Subject: RE: Encrypting
FuseActions
04:56 PM
Please
respond to
fusebox
I think its a great idea! I've toyed with doing such a thing, but never got
off my duff and wrote it.
I was thinking of something where you'd have a db table storing clear
fuseaction names, and hashed names. Tie it to another app that would, on
nightly scheduled basis, generate new hashes, and go through every CF
template, doing a find/replace for the old hashes with the new hashes. This
way your window of vulnerability would be cut down to one day, were a
fuseaction to be compromised.
I think that with Fusebox, these types of security measures can be made
very
easy to implement, seeing how every client request passes through
index.cfm.
Something like this could be cleaned up into a very tight security model,
and included in a future Fusebox book, I think...
Alan McCollough
Web Programmer
Allaire Certified ColdFusion Developer
Alaska Native Medical Center
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, November 29, 2000 10:19 AM
> To: Fusebox
> Subject: Encrypting FuseActions
>
> A co-worker and I came up with this possible tool to conceal the names of
> FuseActions, for even heightened security for the paranoid. It consists
of
>
> a custom tag to create a structure containing FuseActions and their
> encrypted values, and a line to decrypt the passed FuseAction.
>
> I haven't tested this code yet, we just whipped it up real quick and I
> wanted to see what y'all thought of the idea - any merit?
>
> <!--- Source of CF_SETFUSEACTIONS: --->
>
> <CFPARAM NAME="Attributes.FuseActions" DEFAULT="">
> <CFPARAM NAME="Attributes.Key" DEFAULT="KermitTheFrog">
> <CFPARAM NAME="Attributes.Return" DEFAULT="S_FuseActions">
>
> <CFSET S_FuseActions = StructNew()>
>
> <CFLOOP LIST="#Attributes.FuseActions#" INDEX="FuseAction">
> <CFSET SetVariable("S_FuseActions.#FuseAction#",
Encrypt(FuseAction,
>
> Attributes.Key))>
> </CFLOOP>
>
> <CFSET SetVariable("Caller.#Attributes.Return#", S_FuseActions)>
>
> <!--- In the calling template: --->
>
> <CF_SETFUSEACTIONS FUSEACTIONS="Login,Logout,Display" KEY="MyKey">
>
> <CFOUTPUT><A
> HREF="default.cfm?F=#S_FuseActions.Login#">Login</A></CFOUTPUT>
>
> <!--- At the top of the FuseBox (index.cfm) or app_globals.cfm : --->
>
> <CFSET Attributes.FuseAction = Decrypt(Attributes.F,
> Application.FuseActionKey)>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
