Как запретить нескольким клиентам использовать один и тот же идентификатор сеанса? Я спрашиваю об этом, потому что я хочу добавить дополнительный уровень безопасности, чтобы предотвратить перехват сеансов на моем веб-сайте. Если хакер каким-то образом определяет идентификатор сеанса другого пользователя и делает запросы с этим SID, как я могу обнаружить, что существуют разные клиенты, совместно использующие один SID на сервере, и затем отклонить попытку угона?

EDIT

Я принял ответ Гамбо после тщательного рассмотрения, потому что я пришел к выводу, что то, о чем я прошу, невозможно из-за ограниченийstateless HTTP protocol, Я забыл о том, что является, возможно, самым фундаментальным принципом HTTP, и теперь, когда я думаю об этом вопросе, это кажется немного тривиальным.

Позвольте мне уточнить, что я имею в виду:

После того как пользователь A входит в систему на example.com, ему дается некоторый случайный идентификатор сеанса, для простоты, пусть он будет «abc123». Этот идентификатор сеанса хранится в виде файла cookie на стороне клиента и проверяется сеансом на стороне сервера, чтобы гарантировать, что вошедший в систему пользователь остается в системе при переходе с одной веб-страницы на другую. Этот cookie, конечно, не должен существовать, если бы HTTP не был без сохранения состояния. По этой причине, если пользователь B украдет SID пользователя A и создаст на своем компьютере файл cookie со значением «abc123», он успешно угонит сеанс пользователя A, но у сервера просто нет возможности законно признать, что запрос пользователя B отличается от запросов пользователя A, и, следовательно, у сервера нет оснований отклонять любой запрос. Даже если бы мы перечислили сеансы, которые уже были активны на сервере, и попытались выяснить, имеет ли кто-то доступ к сеансу, который уже активен, как мы можем определить, что это другой пользователь, который обращается к сеансу незаконно, а не тот же пользователь? который уже вошел в систему с идентификатором сеанса, но просто пытается сделать еще один запрос с его помощью (т. е. перейти на другую веб-страницу). Мы не можем. Проверка пользовательского агента? Может быть подделан - но, тем не менее, хорош как защита глубины. Айпи адрес? Может меняться по законным причинам - но вместо того, чтобы вообще не проверять IP-адрес, я предлагаю проверить что-то вроде первых двух октетов IP, как даже пользователя в сети тарифного плана, который постоянно имеет изменяющийся IP по совершенно законным причинам обычно только последние два октета их изменения IP.

В сущности, именно HTTP без сохранения состояния обрекает нас на то, что мы никогда не сможем полностью защитить наши веб-сайты от перехвата сеансов, но передовой опыт (подобный тому, который предоставил Gumbo) будет достаточно хорош для предотвращения подавляющего большинства сеансовых атак. Поэтому попытка защитить сеансы от перехвата путем отказа от нескольких запросов одного и того же идентификатора безопасности просто нелепа и может нанести ущерб всей цели сеансов.