Patch to minimize session fixation (continued)

php.internals

inodes

22 years ago
I agree with all your arguments: the IP-base solution IS NOT perfect. It is not generic enough to be implemented in world-wide application, but it can be useuful for intranet or extranets. That's to say cases when you know the infrastructure used by the clients to connect to your server support this strategy. My goal is to minimize the risks for now, since I don't know yet what the perfect solution could be. Other tests could be made: - on the browser headers - on IP ranges rather that on the single client IP address - and so on... Jerome

Sascha Schumann

22 years ago
> It is not generic enough to be implemented in world-wide application, but it > can be useuful for intranet or extranets. That's to say cases when you know > the infrastructure used by the clients to connect to your server support > this strategy.
If you want this feature, implement it in your PHP script. - Sascha

Sean Coates

22 years ago
While I like that your patch can be turned on and off in the INI, this sounds much more like an application-level problem, and thus should be implemented at the application level. MHO. S inodes wrote:

Jochem Maas

22 years ago
Sean Coates wrote:
> While I like that your patch can be turned on and off in the INI, this > sounds much more like an application-level problem, and thus should be > implemented at the application level.
Loads of people have actually put stuff out that does this... ^ |
>> Other tests could be made: >> - on the browser headers >> - on IP ranges rather that on the single client IP address >> - and so on...
What about a scoring system (based on checks on the above and more?), a bit like that which is used in products like spamAssassin, the ini setting could be a threshold value (0 basically meaning attempt no checks and any value > 0 && =< 1 to be reject/accept* threshold). ...anyway the idea of being able to do some kind of sanity check on behalf 'beginners' (no offensive intended) is a nice idea. Advanced users tend to have specific environment requirements (and set them up accordingly) and perform decent checking anyway.

George Schlossnagle

22 years ago
On Apr 7, 2004, at 9:48 PM, Jochem Maas wrote:
> Sean Coates wrote: > >> While I like that your patch can be turned on and off in the INI, >> this sounds much more like an application-level problem, and thus >> should be implemented at the application level. > > Loads of people have actually put stuff out that does this... > ^ > | >>> Other tests could be made: >>> - on the browser headers >>> - on IP ranges rather that on the single client IP address >>> - and so on... > > What about a scoring system (based on checks on the above and more?), > a bit like that which is used in products like spamAssassin, the ini > setting could be a threshold value (0 basically meaning attempt no > checks and any value > 0 && =< 1 to be reject/accept* threshold). > > ...anyway the idea of being able to do some kind of sanity check on > behalf 'beginners' (no offensive intended) is a nice idea. Advanced > users tend to have specific environment requirements (and set them up > accordingly) and perform decent checking anyway.
All of the above methods have problems with proxy servers. As a robust solution to the problem doesn't exist, people should implement their own non-robust solutions in their own scripts. George

Hans Lellelid

22 years ago
I also would add that from experience using IP addresses to validate sessions does not work for any internet application.
> It is not generic enough to be implemented in world-wide application, but it > can be useuful for intranet or extranets. That's to say cases when you know > the infrastructure used by the clients to connect to your server support > this strategy.
Yes, I suppose this is true, but if you are building an intranet application you probably aren't going to need this additional security. I agree with the others -- this belongs in your application. In particular to prevent session fixation (rather than session hijacking) use the session_regenerate_id() after authentication happens. This should prevent fixation. Hans