Everything

php

Re: Patch to minimize session fixation (continued)

php.internals

inodes

22 years ago

Sasha suggests me to implement these checkings in my script: IMHO that's not
the good strategy.

You guys are probably good programmers, but my experience shows me that the
"standard" PHP developper is not aware of security problems or he/she has
not the time to finalize the scripts (time is money...).

So I would like to provide a way to ensure some basic tests are made by PHP
itself !

As an analogy I could talk about "mod_security" Apache module: it globalizes
some tests before Apache calls the scripts and so minimizes the effort of
the developpers that would always take care of user's input...

Of course, good programmers always filter entries, but adding another
security level is a good practive too...

I could also say that my patch is a bit like the "safe mode": it is not
perfect at all but, nertheless, it can be useful !

So,  I will enhance the "patch" to make it less restrictive when testing the
IP addresses and think about a strategy to handle AOL-like ISP...

Cheers,

Jerome

Christian Schneider

22 years ago

Inodes wrote:

> You guys are probably good programmers, but my experience shows me that the
> "standard" PHP developper is not aware of security problems or he/she has
> not the time to finalize the scripts (time is money...).

The problem with your patch is twofold:
1) It breaks for some users under rare circumstances which leads to very
hard to reproduce bug reports. Trust me. I tried to use IP tracking and
similar stuff and had to remove it because of user complaints.
2) It gives a false sense of security which leads to people spending
less thoughts on the security concept of application because they rely
on the session mechanism. Take proxies as an example: You'd have to also
check for X-Forwarded-For headers to get the address behind a large ISPs
proxy which opens up a whole new can of worms: How do you know that it
wasn't the hacker sending X-Forwarded-For with the user's IP?

I decided to say "If X knows the session ID of User A then he _is_ A".
(Side note: I use my own random/MD5-based session IDs which should be
hard to guess). If I think sniffing a session ID is a problem then my
application probably needs a higher security level anyway and I switch
to SSL.

> So,  I will enhance the "patch" to make it less restrictive when testing the
> IP addresses and think about a strategy to handle AOL-like ISP...

Speaking from my own experience I should warn you that it is quite hard
to convince this list to accept such patches. Don't be too disappointed
in that case ;-)

I agree with other posts that this belongs in either
a) the application
b) PEAR (I'm pretty sure PEAR already offers something like this,
haven't checked though)
and not core PHP.

- Chris

Chris Shiflett

22 years ago

--- Christian Schneider <cschneid@cschneid.com> wrote:

> I decided to say "If X knows the session ID of User A then he _is_ A".

This isn't a good approach, but you can bring this up on php-general to
discuss why. I'm sure plenty of people will be happy to discuss it.

> (Side note: I use my own random/MD5-based session IDs which should be
> hard to guess).

Do you think it's better than the existing session ID generation code? I
always trust the level of entropy provided by the native mechanism. If you
think you have a better solution, maybe you can submit a patch...

Chris

=====
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
Coming Fall 2004
HTTP Developer's Handbook - Sams
http://httphandbook.org/
PHP Community Site
http://phpcommunity.org/

Derick Rethans

22 years ago

On Wed, 7 Apr 2004, Chris Shiflett wrote:

> --- Christian Schneider <cschneid@cschneid.com> wrote:
> > I decided to say "If X knows the session ID of User A then he _is_ A".
>
> This isn't a good approach, but you can bring this up on php-general to
> discuss why. I'm sure plenty of people will be happy to discuss it.
>
> > (Side note: I use my own random/MD5-based session IDs which should be
> > hard to guess).

PHP's generated from remote ID, process id, time and some randomness;
and then MD5'ed. That's 'better' then your random/MD5 based approach as
it's even less likely to result in collisions.

regards,
Derick

Christian Schneider

22 years ago

Derick Rethans wrote:

> PHP's generated from remote ID, process id, time and some randomness;
> and then MD5'ed. That's 'better' then your random/MD5 based approach as
> it's even less likely to result in collisions.

How can you tell without knowing what my source of random data is? And
no, I'm not worried about an MD5 collision. I'm paranoid but not _that_
paranoid (and I'm not going to get into a discussion there either ;-))

I realize that I should have skipped the part about my own code as it
was confusing and beside the point. I simply wanted to avoid people
pointing out how they can guess PHP session IDs which might or might not
be possible, I wouldn't know :-)

My point was: Don't give people a false sense of security and that's why
I consider it a bad idea to put the patch into the PHP core.

- Chris