Re: Session IP address matching

From: Date: Sun, 26 Jan 2014 20:27:20 +0000
Subject: Re: Session IP address matching
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.internals 
Request: Send a blank email to internals+get-71597@lists.php.net to get a copy of this message
> I think somebody already pointed out that this would be useful for > admin interfaces. How many applications don't have that? If you force this measure on /wp-admin or equivalent, you'll never retain customers. (Some frameworks offer this option in userland anyway -- plus the absolutely _vital_ ability for the user to turn it off him/herself.) Admin screens for a bank, maybe. But then I hope you have so many other restrictions (such as not allowing connections except over multi-factor VPN) that checking the IP is just a formality. A special case where the feature might do more good than harm is when both server and clients are on the same LAN with static IPs. If the organization is computing/scientific in nature it might be reasonable to expect inside jobs using network taps, bespoke interception boxes -- or whatever -- to intercept SSL and also hijack per-request session IDs (perhaps by timing for end-of-day or something). The extra IP check might then be practical protection. But unless the internal systems saw seriously high traffic surely a userland implementation would work just fine. (My) bottom line is that putting this feature in core is a clear recipe for disaster. Most PHP users, let alone the "app deployer" type of users, don't know s**t about HTTP or TCP/IP. The moment turning on this feature gets mistakenly documented as a best practice on some excited newbie's blog, or somebody's downvoted-but-not-deleted StackOverflow post, you've caused way more harm than good. Look at it this way: if even *Stefan* (Suhosin) recommends conservative use, take that caveat very seriously. -- S.

« previous php.internals (#71597) next »