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 [email protected] 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.




Thread (29 messages)

« previous php.internals (#71597) next »