note 50288 deleted from features.cookies by salathe
| From: | salathe@php.net | Date: | Mon, 21 Sep 2020 14:34:47 +0000 |
| Subject: | note 50288 deleted from features.cookies by salathe | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-215205@lists.php.net to get a copy of this message | ||
Note Submitter: mega-squall at caramail dot com
----
I found a solution for protecting session ID without tying them to client's IP. Each session ID
gives access for only ONE querry. On the next querry, another session ID is generated and stored. If
somebody hacks the cookie (or the session ID), the first one of the user and the pirate that will
use the cookie will get the second disconnected, because the session ID has been used.
If the user gets disconnected, he will reconnect : as my policy is not to have more than one session
ID for each user (sessions entries have a UNIQUE key on the collomn in which is stored user login),
every entries for that user gets wiped, a new session ID is generated and stored on users dirve :
the pirate gets disconnected. This lets the pirate usually just a few seconds to act. The slower
visitors are browsing, the longer is the time pirates get for hacking. Also, if users forget to
explicitly end their sessions .... some of my users set timeout longer than 20 minutes !
IMPORTANT NOTE : This disables the ability of using the back button if you send the session ID via
POST or GET.