Don Anderson
|
| Posted: 02/27/2003, 7:11 PM |
|
Hi People,
We've been looking at how to integrate CCS generated sessions with Gossamer
Threads LinksSQL (http://www.gossamer-threads.com). We have discovered
what might be a security issue with CSS session handling under PHP.
LinkSQL saves only the username in the session file. For example:
$SESSION = {
'username' => 'don'
};
CCS stores alot more user information in the session file including
username, group and password. .
For example:
UserID|s:1:"1";UserLogin|s:3:"don";UserPassword|s:2:"MyPassword";GroupID|s:1
3:"Administrator";
The session files for PHP are typically stored in a /tmp directory. Often
multiple virtuals will share the same /tmp session directory.
One of my co-workers pointed out that this is a major security issue because
many people with cgi or php access to the web server will be able to read
the various session files in the /tmp directory. They will have access to
usernames and passwords stored in the temporary session files.
Could someone at Yes Software please tell me whether this is correct? And,
if there is an easy way to modify CCS not to put the passwords in the
temporary session files (whilst retaining in-built user and group
authentication features)?
Many thanks,
Don Anderson
|
|
|
 |
DonB
|
| Posted: 02/27/2003, 8:25 PM |
|
Session info stored in a file? I'm no expert as far as php goes, but
sessions have always been memory-resident things in my experience. The
purpose is temporary data storage for the lifetime of your session. So
persisting to a file makes me very confused. The data is supposed to go
away when your session terminates.
What you describe sounds more like server-side cookies.
DonB
|
|
|
|
Don Anderson
|
| Posted: 02/27/2003, 8:56 PM |
|
The PHPSESSID cookie contains a random hex string such as
187329794b9b52a6cb02eb081aa16db3.
This string is the session id. It is the name of a temporary session file
typically stored in /tmp.
The session file contains username, group and password information for the
user the session refers to.
I'm concerned that having such information in an accessible file could be a
security risk.
Cheers,
Don Anderson
"DonB" <7432D63DBB01D03A196B1EDD80E8@comcast.net> wrote in message
news:b3mob4$qm0$1@news.codecharge.com...
> Session info stored in a file? I'm no expert as far as php goes, but
> sessions have always been memory-resident things in my experience. The
> purpose is temporary data storage for the lifetime of your session. So
> persisting to a file makes me very confused. The data is supposed to go
> away when your session terminates.
>
> What you describe sounds more like server-side cookies.
>
> DonB
>
>
|
|
|
|
Christoph Grottolo
|
| Posted: 02/28/2003, 12:19 PM |
|
>The session file contains username, group and password information for the
>user the session refers to.
>
>I'm concerned that having such information in an accessible file could be a
>security risk.
You're right. I didn't realize that before - but it's a real security
issue. I don't understand why there is a need to store even the
username in the session, the user id alone should be enough, the rest
could be retrieved from the db when needed. There is absolutely no
need to put a password as a session variable (and neither it's
reasonable to store passwords in plain text by default).
I think this is one of the big weak points in CCS, along with the
quite simplistic user management approach (no nested groups, no
roles). The session thing you're talking about is really bad.
I like CCS, btw.
Christoph
|
|
|
|
Maris Kalnins
|
| Posted: 03/02/2003, 11:07 PM |
|
Hi!
How about storing a password in MD5 format?
User inputs the login name and the password,
when pressing login button we transfer password using php function MD5
and pass the resulting string as a password. In db we have all passwords
already MD5ed.
If somebody will hack out the string of /tmp session directory, it will
not help a lot because MD5 is one way only encoding
The only bad thing around that is that we cannot return the real password
to user if he forgets it!
What do you think?
Maris
"Christoph Grottolo" <cg@gordimer.net> wrote in message
news:nggv5vs1i3dier0t37a9rfab9q8f1cvsor@4ax.com...
>
> >The session file contains username, group and password information for
the
> >user the session refers to.
> >
> >I'm concerned that having such information in an accessible file could be
a
> >security risk.
>
> You're right. I didn't realize that before - but it's a real security
> issue. I don't understand why there is a need to store even the
> username in the session, the user id alone should be enough, the rest
> could be retrieved from the db when needed. There is absolutely no
> need to put a password as a session variable (and neither it's
> reasonable to store passwords in plain text by default).
>
> I think this is one of the big weak points in CCS, along with the
> quite simplistic user management approach (no nested groups, no
> roles). The session thing you're talking about is really bad.
>
> I like CCS, btw.
>
> Christoph
|
|
|
|
Christoph Grottolo
|
| Posted: 03/03/2003, 2:09 PM |
|
"Maris Kalnins" <proximus@e-teliamtc.lv> wrote:
>Hi!
>
>How about storing a password in MD5 format?
>
>User inputs the login name and the password,
>when pressing login button we transfer password using php function MD5
>and pass the resulting string as a password. In db we have all passwords
>already MD5ed.
>
>If somebody will hack out the string of /tmp session directory, it will
>not help a lot because MD5 is one way only encoding
>
>The only bad thing around that is that we cannot return the real password
>to user if he forgets it!
>
>What do you think?
md5() or some other kind of encryption would be another idea (i've
been asking for that quite some time ago and we've implemented md5()
encription of passwords in our apps with custom code) - but even with
md5 - there's absolutely no need to store a password in the session.
At least I can't imagine a situation where it could be useful.
Christoph
|
|
|
|
Don Anderson
|
| Posted: 03/03/2003, 3:43 PM |
|
Hi People,
Storing the usernames and passwords encrypted in the session file is one
idea.
However, the challenge we face is integrating CodeChargeStudio user sessions
with sessions for another another web-based application. If we encrypt
information in the /tmp session files then it will be more difficult to
integrate with other systems' sessions.
In my opinion, it would be better only to store the UserID in the session
info and run db lookups to retrieve username and password info when it is
required.
Cheers,
Don Anderson
PS: I was hoping that Yes Software would pick up on this issue. Will
submit a support request and see what they have to say.
"Maris Kalnins" <proximus@e-teliamtc.lv> wrote in message
news:b3uuuv$dno$1@news.codecharge.com...
> Hi!
>
> How about storing a password in MD5 format?
>
> User inputs the login name and the password,
> when pressing login button we transfer password using php function MD5
> and pass the resulting string as a password. In db we have all passwords
> already MD5ed.
>
> If somebody will hack out the string of /tmp session directory, it will
> not help a lot because MD5 is one way only encoding
>
> The only bad thing around that is that we cannot return the real password
> to user if he forgets it!
>
> What do you think?
>
> Maris
>
> "Christoph Grottolo" <cg@gordimer.net> wrote in message
>news:nggv5vs1i3dier0t37a9rfab9q8f1cvsor@4ax.com...
> >
> > >The session file contains username, group and password information for
> the
> > >user the session refers to.
> > >
> > >I'm concerned that having such information in an accessible file could
be
> a
> > >security risk.
> >
> > You're right. I didn't realize that before - but it's a real security
> > issue. I don't understand why there is a need to store even the
> > username in the session, the user id alone should be enough, the rest
> > could be retrieved from the db when needed. There is absolutely no
> > need to put a password as a session variable (and neither it's
> > reasonable to store passwords in plain text by default).
> >
> > I think this is one of the big weak points in CCS, along with the
> > quite simplistic user management approach (no nested groups, no
> > roles). The session thing you're talking about is really bad.
> >
> > I like CCS, btw.
> >
> > Christoph
>
>
|
|
|
|
Don Anderson
|
| Posted: 03/04/2003, 11:17 AM |
|
Hi People,
I contacted Yes support. Alex gave the following response.
"This may happen when you convert older projects in the new beta.
Please delete UserPasswordVariable attribute and it's value from
projectname.ccs file.
Regards,
Alex"
After some stuffing around (doing the routine several times, resetting
variables, saving, closing and reopening the project) CCS started creating
session files without the password info.
Cheers,
Don
"Don Anderson" <don@ethos.co.nz> wrote in message
news:b3mk06$hhf$1@news.codecharge.com...
> Hi People,
>
> We've been looking at how to integrate CCS generated sessions with
Gossamer
> Threads LinksSQL (http://www.gossamer-threads.com). We have discovered
> what might be a security issue with CSS session handling under PHP.
>
> LinkSQL saves only the username in the session file. For example:
>
> $SESSION = {
> 'username' => 'don'
> };
>
> CCS stores alot more user information in the session file including
> username, group and password. .
> For example:
>
>
>
UserID|s:1:"1";UserLogin|s:3:"don";UserPassword|s:2:"MyPassword";GroupID|s:1
> 3:"Administrator";
>
> The session files for PHP are typically stored in a /tmp directory. Often
> multiple virtuals will share the same /tmp session directory.
>
> One of my co-workers pointed out that this is a major security issue
because
> many people with cgi or php access to the web server will be able to read
> the various session files in the /tmp directory. They will have access
to
> usernames and passwords stored in the temporary session files.
>
> Could someone at Yes Software please tell me whether this is correct?
And,
> if there is an easy way to modify CCS not to put the passwords in the
> temporary session files (whilst retaining in-built user and group
> authentication features)?
>
> Many thanks,
> Don Anderson
>
>
>
>
|
|
|
|
DAVID
|
| Posted: 03/14/2003, 12:02 PM |
|
Alex is a cool dude, he's always on top of the situation.
"Don Anderson" <don@ethos.co.nz> wrote in message
news:b42u3f$8em$1@news.codecharge.com...
> Hi People,
>
> I contacted Yes support. Alex gave the following response.
>
> "This may happen when you convert older projects in the new beta.
> Please delete UserPasswordVariable attribute and it's value from
> projectname.ccs file.
>
> Regards,
> Alex"
>
> After some stuffing around (doing the routine several times, resetting
> variables, saving, closing and reopening the project) CCS started creating
> session files without the password info.
>
> Cheers,
> Don
>
>
>
> "Don Anderson" <don@ethos.co.nz> wrote in message
>news:b3mk06$hhf$1@news.codecharge.com...
> > Hi People,
> >
> > We've been looking at how to integrate CCS generated sessions with
> Gossamer
> > Threads LinksSQL (http://www.gossamer-threads.com). We have discovered
> > what might be a security issue with CSS session handling under PHP.
> >
> > LinkSQL saves only the username in the session file. For example:
> >
> > $SESSION = {
> > 'username' => 'don'
> > };
> >
> > CCS stores alot more user information in the session file including
> > username, group and password. .
> > For example:
> >
> >
> >
>
UserID|s:1:"1";UserLogin|s:3:"don";UserPassword|s:2:"MyPassword";GroupID|s:1
> > 3:"Administrator";
> >
> > The session files for PHP are typically stored in a /tmp directory.
Often
> > multiple virtuals will share the same /tmp session directory.
> >
> > One of my co-workers pointed out that this is a major security issue
> because
> > many people with cgi or php access to the web server will be able to
read
> > the various session files in the /tmp directory. They will have access
> to
> > usernames and passwords stored in the temporary session files.
> >
> > Could someone at Yes Software please tell me whether this is correct?
> And,
> > if there is an easy way to modify CCS not to put the passwords in the
> > temporary session files (whilst retaining in-built user and group
> > authentication features)?
> >
> > Many thanks,
> > Don Anderson
> >
> >
> >
> >
>
>
|
|
|
|
|
