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
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
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:
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
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.
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
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