http client one comes along and acquires a legitimate session, abc123. along with generating this session, the server records something unique about http client one, or about the communication itself, such as http client one’s remote ip address (not a good idea, keep reading). this can be anything at all, not necessarily limited to an http context, and this is stored as session_key. all subsequent requests from http client one will contain the session abc123. the idea is that session_key should be something determined by the server, on the server-side, not provided by the client (i.e., javascript or hidden form-field or whathaveyou), as this is trivial for an attacker to spoof.

now, sitting across the coffee shop, http client two has been watching http client one’s tcp packets and knows exactly what that session_id is. therefore, http client two does not need to poke around for usernames or passwords. no need for a phishing site. no trojan horse, spyware, keystroke logger, fraudulent phone calls, or anything else. http client two needs only to make a request to the same domain with the same session_id, while http client one is logged in. http client two now has immediate access to anything and everything available to http client one, and nobody even knows about it. that’s right, a simple, untraceable attack. this works, by my testing, with yahoo! mail, gmail, hotmail, and probably about every web site i could try it on, though ssl makes things more cumbersome – i should say, not very much more cumbersome, if the attacker can see the underlying tcp.

…however, since the server is also using session_key to store and retrieve it’s sessions, http client two must appear to the server as identical to http client one. for example, say the server stores http_client_id (”mozilla” or “ie” or whathaveyou) in the session_key. now, http client two must make it’s request to the server not only with the same session as http client one, but also with the same browsing software. or, say, session_key is remote_addr: now http client two must also spoof his victim’s ip.

the obvious argument to this is that, in our scenario, http client two sees the whole http request made by his victim. therefore, it is entirely probable that he will spoof his request to match his victims to the greatest extent possible, in trying to make his hijack. therefore, the server would see the same http_client_id (or accept_charset or whatever else you could think of). and using the client-provided ip address or any function of the underlying ip connection as a session_key would be stupid on the server’s part since the server may not know about http tunnels, proxy servers, ip-masquerading firewalls, or anything else which could (and inevitably would) obfuscate the reliability of such a method.

so, here is my post in a nutshell: what would serve as a good spoof-proof session_key? that is, what can a web server (or the system running a web server) see about a web client that is not likely (even better, not possible) to be reproduced in an attacker’s hijack request? answer that, and you’ll have a secure, unbreakable session management implementation. you will no longer need ssl, even when dealing out credit card numbers and social security numbers and the like.

it’s not a rhetorical question. i don’t expect anybody to be able to answer, or else yahoo! and hotmail, gmail at least, would not be quite so easy to break into. if you can answer, though, you would be well-advised to seek a patent.

There is absolutely no need to carry around a password in a session.

And since it a unknow firewall, and probably not professional, we can’t even know it is not a virus or a trojan itself so it is not reporting as is.

Thanks for your patience and NOT TRYING armor2net…

I have some resources that might help elaborate on some of these things.

Session Hijacking:
http://shiflett.org/articles/the-truth-about-sessions

Session Fixation:
Security Corner in the current issue of php|architect. Unforunately, this is not yet available for free.

XSS:
http://www.phparch.com/issuedata/articles/article_66.pdf

Shared Hosts:
I’m finishing up an article about this (and safe_mode) for the next Security Corner, and here is a script that developers can use to better illustrate how open a shared server is (when safe_mode is disabled, which is common):
http://shiflett.org/code/browse.phps

Perhaps one phpcommunity “deliverable” might be to compile the various documents on PHP Security out there and submit it to http://www.owasp.org – I notice thier Guidelines document has a blank PHP section and, in general, is almost entirely focused on J2EE and .NET.