PHP Session Security: usefulness of checking $_SESSION['HTTP_USER_AGENT']

Threads such as PHP Session Fixation / Hijacking and some people like Chris Shiflett recommend checking the user agent ( $_SESSION['HTTP_USER_AGENT'] ) to help check for session validity. Some resources even recommend something like this:

<?php

$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'SHIFLETT';

/* Add any other data that is consistent */

$fingerprint = md5($string);

?>

However, Chris Snyder says that "the universe of browser agents is miniscule in comparison to the universe of users, so it is impossible for each user to have an individual user agent. Furthermore, it isn't hard to spoof a user agent. And so there is little real point in checking this metric as a proof of session validity" (Chapter 7, pg 103).

It's very difficult to know what to do when one encounters conflicting advice, and when some of the advice may be out-of-date (such as the Shiflett/PHPSec example above, whose timestamp seems to be Friday, March 18, 2005). Newer advice such as Snyder's (date of publication: December 9, 2010) would seem to be better, but is this always so? (For example, in spite of spending a lot of time recommending the use of mysqli, Snyder completely ignores what Stack Overflow users seem to agree is the better choice -- PDO -- so I'm not totally sold on Snyder as the ultimate Trustworthy Expert).

So I guess my question has two parts, one specific (should I bother examining the user agent?) and one more general (whose advice should I trust when it comes to the latest thinking in PHP Security?), with my obvious bias being "trust the people on Stack Overflow!" -- or I wouldn't be asking in the first place, because crowd-sourcing the most current thinking is often the best idea.

Following useful discussion in the comments w/ @Radu, to clarify the HTTPS question --

Snyder seems to be saying two things: 1.) HTTPS makes other tools less necessary or 开发者_如何学Gounnecessary. 2.) In situations where one cannot use HTTPS, it is still not really useful to check the user agent (and this seems to be the point where he disagrees with some possibly older advice).

If the man in the middle can hijack the session ID, then he should have absolutely no problem in sending the same user agent, so I don't think this will get you anywhere. This is security by obscurity.

If you want real protection, use HTTPS.

The user agent is not totally fool proof by itself but it adds thin layer on top of other security. There is debate on what should go to fingerprint. But nonetheless it adds to defense-on-depth principle. You can set a cookie and use that in combination with user agent and specific word to make fingerprint. My point is, it adds to security though little!

The problem with sessions is that you just need the session ID to use that session. If you know a valid session ID, you can use that session. That’s how sessions work.

Now some suggest to use an additional datum to verify the validity to use a certain session by a certain client. The user agent ID is such a suggested datum as it is some kind of unique (see Panoptoclick to test your own) and doesn’t change during the session (in opposite to some other informations provided by the client).

But this only lowers the likelihood of Session Fixation and prevents the accidental use of a foreign session in case of Session Hijacking. Because an attacker could try to obtain the victim’s user agent ID and spoof it when fixing or hijacking the session. And here it doesn’t matter whether you store the user agent ID in plain or as a (salted) hash.

Better use the already proven protection measures.