note 22986 deleted from ref.session by sniper

I think I've come up with a practical "session intrusion/hijack detector" (where someone discovers a Session ID and tries to gain access). 1. create a session var called "sreqs" (server requests) 2. create a cookie called "creqs" (client requests) 3. On each page you: a: increment sreqs using PHP b: increment creqs using JavaScript c: compare sreqs to creqs with JavaScript in client or PHP in server. d: if they are not equal, some else is tugging your chain! As creqs is a cookie, it is returned to the server, so it could issue the warning. The key point here is that the client and server keep separate counts. A second broswer will ALWAYS cause sreqs to go out of sync - even if they "sniff" the count value, they can't stop sreqs incrementing and they can't change the owner's creqs cookie. They can look but the cannot touch (and where's the fun in that!). If the warning is server based (the creqs cookie from the intruder will almost certainly be wrong), it could log the new IP and send the details to the owner and service provider. I've tested it on my prototype site and it certainly works using a test "URL settable" session ID to simulate an intrusion using 2 browsers. It can be thrown out of sync by partial page loads or STOPs but I put the JavaScript in the HEAD section to reduce the chances of this. Can anyone see any flaws in my logic or could this be a solution? Neil Munro. Catalyse Networks Limited.