Как вы мешаете нескольким клиентам использовать один и тот же идентификатор сеанса? Я спрашиваю об этом, потому что я хочу добавить дополнительный уровень безопасности, чтобы предотвратить захват сеанса на моем веб-сайте. Если хакер каким-то образом идентифицирует идентификатор сеанса другого пользователя и делает запросы с этим SID, как я могу обнаружить, что существуют разные клиенты, которые используют один SID на сервере, а затем отклоняют попытку захвата?
РЕДАКТИРОВАТЬ
Я принял ответ Gumbo после тщательного рассмотрения, потому что я пришел к осознанию того, что то, что я прошу, невозможно из-за ограничений HTTP-протокола без состояния . Я забыл о том, что является, пожалуй, самым основополагающим принципом HTTP, и теперь, когда я думаю об этом вопросе, кажется немного тривиальным.
Позвольте мне уточнить, что я имею в виду:
После того, как пользователь A войдет в систему на example.com, для его простоты присвоен случайный идентификатор сеанса, пусть это будет «abc123». Этот идентификатор сеанса хранится как файл cookie на стороне клиента и проверяется с помощью сеанса на стороне сервера, чтобы гарантировать, что пользователь, который вошел в систему, остается включенным при переходе с одной веб-страницы на другую. Конечно, этот куки-файл не должен существовать, если HTTP не был апатридом. По этой причине, если пользователь B ворует SID пользователя A и создает на своем компьютере файл cookie со значением «abc123», он успешно захватил сессию пользователя A, но сервер просто не может законно распознать, что пользовательский B запрос отличается от запросов пользователя А, и поэтому у сервера нет причин отклонять запрос. Даже если мы должны перечислить сеансы, которые уже были активны на сервере, и попытаться выяснить, имеет ли кто-либо доступ к уже активному сеансу, как мы можем определить, что это другой пользователь, который получает доступ к сеансу незаконно, а не тот же пользователь который уже вошел в систему с идентификатором сеанса, но просто пытается сделать с ним другой запрос (т. е. перейти на другую веб-страницу). Мы не можем. Проверка агента пользователя? Может быть подделано, но тем не менее хорошо, как защита в глубине. Айпи адрес? Может измениться по законным причинам – но вместо того, чтобы вообще не проверять IP-адрес, я предлагаю проверить что-то вроде первых двух октетов IP, так как даже пользователь в сети с данными, который постоянно меняет IP по совершенно законным причинам обычно будут иметь только два последних октета изменения IP-адресов.
В заключении, это HTTP-протокол без гражданства, который осуждает нас за то, что мы никогда не смогли полностью защитить наши сайты от захвата сеанса, но хорошие методы (например, предоставленные Gumbo) будут достаточно хороши, чтобы предотвратить хорошее большинство сеансовых атак. Попытка защитить сеансы от угона, отказавшись от нескольких запросов одного и того же SID, поэтому просто нелепо, и победит всю цель сеансов.
К сожалению, нет эффективного способа безошибочно идентифицировать запрос, исходящий от злоумышленника, в противоположность подлинному запросу. Поскольку большинство свойств, которые контролируют измерения, такие как характеристики IP-адреса или пользовательского агента, либо ненадежны (IP-адрес может меняться среди нескольких запросов), либо легко подделываться (например, заголовок запроса User-Agent ) и, следовательно, могут давать нежелательные ложные срабатывания (т. Е. подлинный пользовательский IP-адрес) или ложные негативы (т. е. злоумышленник смог успешно запросить запрос с тем же User-Agent ).
Вот почему лучший способ предотвратить захват сеанса – убедиться, что злоумышленник не может узнать идентификатор сеанса другого пользователя. Это означает, что вы должны разработать приложение и его управление сеансом, чтобы (1) злоумышленник не мог угадать действительный идентификатор сеанса, используя достаточную энтропию, и (2), что нет другого способа для злоумышленника получить действительный идентификатор сеанса с помощью известных атак / vulterabilities, например, обнюхивание сетевой связи, межсайтовый скриптинг, утечка через Referer и т. д.
Тем не менее, вы должны:
HttpOnly и Secure чтобы запретить доступ через JavaScript (в случае уязвимостей XSS) и запретить передачу через небезопасный канал (см. session.cookie_httponly и session.cookie_secure ) Кроме того, вы должны также восстановить идентификатор сеанса, недействив старый (см. Функцию session_regenerate_id ) после определенных изменений состояния сеанса (например, подтверждение подлинности после входа в систему или изменение авторизации / привилегий), и вы можете дополнительно делать это периодически, чтобы сократить время для успешного захвата атаки.
Можем ли мы сделать что-то подобное.
Сохранить идентификатор сеанса в базе данных. Также сохраните IP-адрес и HTTP_USER_AGENT для этого идентификатора сеанса. Теперь, когда на сервер приходит запрос, содержащий соответствующий идентификатор сеанса, проверьте, из какого агента и ip он поступает из вашего скрипта.
Можете сделать эту работу фундамента, сделав общую функцию или класс для сеанса, чтобы каждый запрос был проверен до его обработки. Это вряд ли займет несколько секунд. Но, если многие пользователи посещают ваш сайт, и у вас огромная база данных сеансов, то это может быть небольшой проблемой производительности. Но, безусловно, это было бы очень безопасно по сравнению с другими методами, такими как:> Использование регенерирующих сеансов.
При восстановлении идентификаторов сеанса снова появляется мало шансов захвата сеанса.
предположим, идентификатор сеанса пользователя скопирован и этот пользователь не работает или не работает какое-то время, и на сервер не запрашивается старый идентификатор сеанса, требующий регенерации нового. Затем, если идентификатор сеанса захвачен, хакер будет использовать этот идентификатор сеанса и сделать запрос на сервер с этим идентификатором, тогда сервер ответит регенерированным идентификатором сеанса и таким образом, чтобы хакер мог продолжать пользоваться услугами. Фактический пользователь больше не сможет работать, потому что он неизвестен, что такое регенерированный идентификатор, и какой идентификатор сеанса запроса должен передаваться по запросу. Полностью ушел.
Пожалуйста, поправьте меня, если я ошибаюсь где-то.
Существует множество стандартных средств защиты от захвата сессии. Один из них – сопоставление каждой сессии с одним IP-адресом.
Другие схемы могут использовать HMAC, созданный из:
Причина, по которой используется только сетевой адрес IP, заключается в том, что пользователь находится за общедоступным прокси, и в этом случае их IP-адрес может меняться с каждым запросом, но сетевой адрес остается неизменным.
Конечно, чтобы действительно быть в безопасности, вы действительно должны принудительно использовать SSL для всех запросов, чтобы SID не мог быть перехвачен потенциальными злоумышленниками в первую очередь. Но не все сайты делают это ( :: cough :: Stack Overflow :: cough ::) .
На мой взгляд, вы можете хранить идентификатор сеанса в базе данных, когда пользователи вступают в систему и проверяют всех на то же самое до входа в систему. Удалите тот же идентификатор сеанса, который вы сохранили в базе данных при выходе пользователей. Вы можете легко найти идентификатор сеанса для каждого пользователя или я могу вам помочь.
Одна из простых реализаций может быть выполнена путем создания таблицы в базе данных, как зарегистрированных пользователей, а затем при входе в систему, обновления этой таблицы с именем пользователя и его идентификатором SID, это предотвратит использование других логинов в качестве одного и того же пользователя во время выхода из системы, просто запустите простой запрос, который удаляет зарегистрированные данные в базе данных, это также можно использовать для отслеживания зарегистрированных пользователей на веб-сайте ur одновременно.
Очевидно, что когда вы установите cookie сеанса в браузере, этот файл cookie отправляется в запросе. Теперь, когда запрос приходит, сервер проверит идентификатор сеанса в базе данных и предоставит доступ. Чтобы предотвратить его сохранение только агента и ip, так что перед проверкой сервера убедитесь, что доступ к сеансам предоставляется уникальному клиенту, а не уникальный идентификатор сеанса, который может быть захвачен.
Я не очень хорошо знаю о кодирующей части. Поэтому я могу сказать, что это алгоритм. Настройка таких файлов, как SSL, или настройка cookie сеанса для защиты, а httpOnly не работает, если пользователь нюхает идентификатор сеанса из локальной сети (если пользователь и злоумышленник находятся в одной локальной сети).
Так что вы можете сделать, как только пользователь успешно войдет в приложение, установите уникальный токен на каждую страницу веб-приложения и сохраните его на стороне сервера. Таким образом, если действительный пользователь отправляет запрос для доступа к определенной странице, токен этой страницы также будет отправлен на сервер. Поскольку токены уникальны для пользователя для определенного сеанса, даже если злоумышленник может получить идентификатор сеанса, он не может захватить сеанс пользователей, поскольку он не может предоставить действительный токен для сервера.
@Anandu M Das:
Я считаю, что вы можете ссылаться на использование токенов сеанса с каждым идентификатором сеанса. Этот сайт может объяснить использование токенов с сеансами:
https://blog.whitehatsec.com/tag/session-token/
Хотя токены сеанса легко скомпрометированы атакой XSS, это не означает, что они никогда не должны использоваться. Я имею в виду, давайте посмотрим правде в глаза, если что-то было скомпрометировано уязвимостью безопасности на сервере, это не ошибка метода, это ошибка программиста, который ввел эту уязвимость (чтобы выделить точки, сделанные Hesson и Rook).
Если вы соблюдаете надлежащие соглашения и практику безопасности и защищаете свой сайт от SQL-инъекций, XSS и требуете управления всеми сеансами через HTTPS, вы можете легко управлять потенциальной атакой с CSRF с помощью токенов на стороне сервера, хранящихся в сеансе, и обновляется каждый раз, когда пользователь вызывает манипуляции с их сеансом (например, отправляемый $ _POST). Кроме того, НИКОГДА не храните сеансы или их содержимое в URL-адресе, независимо от того, насколько хорошо вы думаете, что они закодированы.
Когда безопасность ваших пользователей имеет первостепенное значение (что должно быть), использование токенов сеанса позволит обеспечить лучшую или более расширенную функциональность без ущерба для их безопасности сеанса.