Hi,
While it is a cool idea, (I will play devil's advocate for abit):
There are some browsers that do not use frames and many users (mostly Unix/Linux
users) who refuse to use browsers that force them. The same goes for cookies. Should
the security of
a fusebox application (or any application for that matter) *force* a user into a
specific mold? Isn't this what MS has been doing and now so many people are screaming
about it?
I would like to see a security mold that is flexible and can accomodate every user
using whichever browser they choose.
Also (and most importantly) I believe that since this is for Cold Fusion - CF should
be implementing it not JS or HTML frames - or anything else for that matter, otherwise
why don't
we write another application that runs on the server and call it fuseboxsecurityapp?
IMHO CF should handle it. HTML should be for displaying the content. JS should be
doing client side stuff.
Regards,
Nelson
Nat Papovich wrote:
> Ok here's an idea for max security, using frames. If you don't like it,
> don't use it.
>
> Set up the entire app in 2 frames. One frame is "hidden" i.e. 1 or 0 pixels
> tall (or wide, I prefer tall). The other one is the mack-daddy do-it-all
> frame. You have to keep this in mind throughout the rest of the application
> because some JavaScripties will hose you if you forget you're in a frame
> already.
>
> Now your hidden frame has a meta-refresh on it, set to oh, say, 3 minutes or
> less. This hidden frame just queries ANY client variable. It just asks for
> say, userid or URLToken or whatever. It's purpose is simply to guarantee
> that a session stays active, and to allow deletion of the client records
> after a certain timeframe has passed without a client var hit.
>
> You can query the CDATA/CGLOBAL tables for lasthit, and if it's less than
> your hidden frame's refresh rate, you know the user is still there (or was
> still there within the refresh rate time period). If it's older, you know
> they're gone.
>
> Good yah?
>
> NATTY
>
> -----Original Message-----
> From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 05, 2000 10:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: <CF_SECURE>
>
> Get more detailed. I wanna hear the yucky stuff that I'm missing.
> Although focus on the CF side of things, not the backdoor OS side, there
> are too many variations there.
>
> I think with my 4 things I've listed it'll cover 40% of applications.
> Here are a couple more ideas i've heard and thought up that might jump
> us up to 50% from 1-4:
>
> 5) use application.cfm to verify the user is going through index.cfm and
> not dsp_whatever.cfm
> 6) place users in groups, passing a list of allowed groups into some
> module in concepts 1-4
> 7) Use email address and password instead of username, password for
> better identity checking, (users are less likely to post their email
> address on a
> 8) when logging in, run the query to verify who they are, then set a
> client variable and after they are logged in only check for the client
> variable. If you need to logout a user you can do so by deleting the
> client variable from the database.
> 9) If a user belongs to one or more groups store a client variable
> called #client.user_groups# with this list. Then if you need to secure
> a 'section' of a page, the check to see if the user has this variable
> and has one of the groups that is allowed to view this section
> 10) Don't require cookies, use the URLtoken, and allow the user to
> decide at the login page whether they want the cookie set or not. Never
> store anything other than the user's token in a cookie, all sensitive
> information should be on the server in a client variable
> 11) Maintain user focus by using the <cf_returnfuseaction> tag. This
> will allow a user to view one page, login and be sent back to the page
> they were viewing.
>
> I'm rambling a little, and I need to summarize the multi-user login
> stuff from the porn discussion. I've got a better version of these
> ideas down on paper, but I'm not done by any means.
>
> Give me more ideas.
>
> Steve
>
> Nat Papovich wrote:
> >
> > Is there a difference between
> > >1. Securing every Fuseaction in one circuit applications
> > and securing access to an entire circuit application?
> >
> > In implementation, yes. In concept, maybe. The security model would be
> more
> > global in aspect, not modularized to the FA.
> >
> > Hmmm...
> >
> > There are many more security issues to think about, but they're on a very
> > different dimension than what you mentioned. I'm thinking of things like
> > multiple logins, use of application.cfm, telnets, click-paths, yucky
> stuff.
> >
> > Jah love,
> > NAT
> >
> > -----Original Message-----
> > From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, July 05, 2000 9:35 AM
> > To: Fusebox
> > Subject: <CF_SECURE>
> >
> > Minor topic change... let's get off the porn and flaming issues and talk
> > about security in general. It's an important topic that needs
> > discussing.
> >
> > I'm writing all the ideas that everyone has been giving me down, and
> > will publish them when I'm done. Here are the four main areas that I
> > see necessary to secure...
> >
> > 1. Securing every Fuseaction in one circuit applications
> > 2. Securing every Fuseaction in multiple circuit applications
> > 3. Securing some Fuseactions in a circuit application, but not all
> > 4. Securing certain areas of a single Fuseaction
> >
> > Does that sound about right to everyone? Am I missing anything? I want
> > to try and create a drop-dead easy open-source security module that will
> > work in 90% of all Fusebox applications.
> >
> > The best way I have found to make something work cross application is to
> > focus on the concepts, not the implementations. So if you've got
> > concepts about how to secure a Fusebox app let's hear them.
> >
> > Steve
> >
> ----------------------------------------------------------------------------
> > --
> > To Unsubscribe visit
> > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> > send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> > the body.
> >
> ----------------------------------------------------------------------------
> --
> > To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
> ----------------------------------------------------------------------------
> --
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
> ------------------------------------------------------------------------------
> To Unsubscribe visit
>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
>message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
