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.
