Forum OpenACS Q&A: Re: Strange cross-caching of users

3: Re: Strange cross-caching of users (response to 1)

Posted by Matthew Geddert on 11/27/02 10:23 AM

I've convinced the client that OpenACS is reliable and secure, and that we don't need to worry about security issues.

This is a scary thing to say, especially if you are dealing with financial documents. It is true that aolserver is relatively secure (in part because of obscurity)... but you should ALWAYS worry about security, and it is irresponsible to tell somebody they don't need to worry about it. For this type of application i would disable the cookies after 10-15 minutes of inactivity or so and disable the feature to permanently store somebodies username/password in cookies... just like online banks do it.

If the information is cached in "work offline" or something like that in internet explorer it has nothing to do with the web server security per say, it has to do with training employees to do one of two things clear their cache (or entirely disable caching of browsing information), or more likely to get them to log off of their computer when not in use (you are using an OS with multi user capability if you are doing finacial work right?). Then each time a user uses a comptuer they log in seperately and get their cache from the previous time they themselves had been logged in. Win95/98/Me doesnt' do this securely. Win NT4, 2k, XP does do this okay, linux/unix are fine, and Mac OS X or higher is fine for multiple users using the same computer with sensitive information.

Although not breakable, it would help to put

in your pages...

4: Re: Strange cross-caching of users (response to 3)

Posted by Reuven Lerner on 11/27/02 11:11 AM

Matthew, you're 100 percent right in what you're saying. At the same time:

I slightly overstated the need for security. The financial data is about aid requests that potential particpiants have submitted. If the information is released, then there will be a heckuva lot of embarrassment, and my head will be served up on a silver platter, but the organization won't go under, and no one will lose any money.
That said, the financial information is protected by a set of permissions that only we (the developers) can assign manually via the OpenACS site map. If we haven't explicitly given you permission to view the data, you won't see it.
The client's current security system is laughably bad. The financial data was passed around in cleartext e-mail several times per week for the last few years. And the computer on which the data is located sits in the middle of an office (without any password, of course) through which more than 100 people pass each day. I take computer and network security quite seriously, but I also have to be realistic -- and for this particular non-profit, the security that we've set up is so far beyond what they've had before that there's no comparison.
All this being true, we're being pretty vigilant about testing and double-checking ourselves.
You're probably right to have cookies expire on a regular basis. At the same time, I have a feeling that the client will be rather annoyed by having to log in again every so often. I'll run it by them later today, and will see what they say.

Finally: From the other thread that Jeff pointed me to, it looks like the pages are cached but the permissions and logins are not. This is a major relief, and means that I simply need to set the caching properties on personalized pages. The underlying security mechanism remains unchanged. I wouldn't mind setting a meta tag, as Matthew suggests, but doing these things in .tcl strikes me as a more elegant solution.

Thanks for the rapid and useful comments!

5: Re: Strange cross-caching of users (response to 4)

Posted by Jeff Davis on 11/27/02 11:41 AM

Two other possibilities for circumventing bad
caching proxies (beyond setting cache-control, etc headers) are to have sensitive pages
be https or to add a "sessionid" to the url (which will prevent cache hits since every url
would then be unique to the given session). I think
both of those will work no matter how broken your proxy is.

Also, even if the pages are cached you cannot carry out
any operation that does a permissions check since the
session_id in the cookie will be correct even if the page
presented to the browser is wrong.