|
|
Posted by Mark Haase on 10/20/53 11:19
In article <11bm9s5sv0kjnec@corp.supernews.com>,
gordonb.3v3t0@burditt.org (Gordon Burditt) wrote:
> Session IDs are normally stored in cookies. A cookie in the XYZ
> domain shouldn't be passed to you in the DEF domain. However, you
> can't count on users not manually inserting cookies into their
> browsers.
I didn't make it clear: other users are able to post websites on our
intranet server (in other directories, of course). Thus they would be
writing cookies on the same domain.
> You can make the name of the "authenticated" flag configurable.
> That's not a very good or secure solution.
>
> This is a problem. It is possible to write a session handler which
> stores session variables in your database rather than in a common
> directory of files. Now, how do you keep your DB password secret
> in such an environment, such that YOUR scripts can use it, but the
> other guy's scripts can't, both running on the same instance of
> Apache and PHP? The DB password issue is relevant even if you
> don't use sessions or don't put sessions in the DB - anyone who
> can write to your DB can add themselves to the user list.
Youch, sounds rough. I guess the real answer is that one must administer
one's own server if they want airtight security? Although this isn't
possible for the project I'm working on I think the level of security I
have reached already is good enough.
> If you were concerned before, you should be really frightened now.
>
> About the only semi-good answer I've heard for multiple potentially
> mutually-hostile customers on the same box involves (a) you have
Hopefully nobody in our IT department will be hostile towards me!
Thanks for the advice, Gordon.
--
|\/| /| |2 |<
mehaase(at)sas(dot)upenn(dot)edu
Navigation:
[Reply to this message]
|