Подтвердить что ты не робот

Предотвращение захвата сеанса

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

ИЗМЕНИТЬ

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Вот почему лучший способ предотвратить захват сеанса - убедиться, что злоумышленник не может узнать другой идентификатор сеанса пользователя. Это означает, что вы должны разработать приложение и его управление сеансом, чтобы (1) злоумышленник не мог угадать действительный идентификатор сеанса, используя достаточную энтропию, и (2), что нет другого способа для злоумышленника получить действительный идентификатор сеанса с помощью известных атак /vulterabilities, такие как обнюхивание сетевой связи, межсайтовый скриптинг, утечка через Referer и т.д.

Тем не менее, вы должны:

  • используйте достаточно случайный ввод для генерации идентификатора сеанса (см. session.entropy_file, session.entropy_length и session.hash_function)
  • используйте HTTPS для защиты идентификатора сеанса во время передачи.
  • сохранить идентификатор сеанса в файле cookie, а не в URL-адресе, чтобы избежать утечки, хотя Referer (см. session.use_only_cookies)
  • установить cookie с атрибутами HttpOnly и Secure, чтобы запретить доступ через JavaScript (в случае уязвимостей XSS) и запретить передачу по небезопасному каналу (см. session.cookie_httponly и session.cookie_secure)

Кроме того, вы должны также восстановить идентификатор сеанса, недействительно старого (см. session_regenerate_id function) после изменения состояния сеанса ( например, подтверждение подлинности после входа в систему или изменение авторизации/привилегий), и вы можете дополнительно делать это периодически, чтобы сократить промежуток времени для успешной атаки на захват сеанса.

Ответ 2

Можем ли мы сделать что-то вроде этого.

Сохранить идентификатор сеанса в базе данных. Также сохраните IP-адрес и HTTP_USER_AGENT для этого идентификатора сеанса. Теперь, когда запрос приходит на сервер, содержащий соответствующий идентификатор сеанса, проверьте, из какого агента и ip он поступает из вашего script.

Можно заставить эту работу работать, делая общую функцию или класс для сеанса, чтобы каждый запрос был проверен до его обработки. Это вряд ли займет несколько секунд. Но, если многие пользователи посещают ваш сайт, и у вас огромная база данных сеансов, то это может быть небольшой проблемой производительности. Но, конечно, это было бы очень безопасно по сравнению с другими методами, такими как = > Использование регенерирующих сеансов.

При восстановлении идентификаторов сеанса снова появляется мало шансов захвата сеанса.

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

Пожалуйста, поправьте меня, если я где-то ошибаюсь.

Ответ 3

Существует множество стандартных средств защиты от захвата сессии. Один из них - сопоставить каждый сеанс с одним IP-адресом.

Другие схемы могут использовать HMAC, сгенерированный из:

  • сетевой адрес клиента IP
  • заголовок пользовательского агента, отправленный клиентом
  • SID
  • секретный ключ, хранящийся на сервере

Причина, по которой используется только сетевой адрес IP, заключается в том, что пользователь находится за общедоступным прокси, и в этом случае их IP-адрес может меняться с каждым запросом, но сетевой адрес остается тем же.

Конечно, чтобы действительно быть безопасным, вы действительно должны принудительно использовать SSL для всех запросов, чтобы SID не мог быть перехвачен потенциальными злоумышленниками в первую очередь. Но не все сайты делают это (:: cough:: Переполнение стека:: cough::).

Ответ 4

По моему мнению, вы можете хранить идентификатор сеанса в базе данных, когда пользователи вступают в систему и проверяют всех на то же самое до входа в систему. Удалите тот же идентификатор сеанса, который вы сохранили в базе данных при выходе пользователей. Вы можете легко найти идентификатор сеанса для каждого пользователя или я могу вам помочь.

Ответ 5

Одна из простых реализаций может быть выполнена путем создания таблицы в базе данных, как зарегистрированных пользователей, а затем при входе в систему, обновления этой таблицы с именем пользователя и его идентификатором SID, это предотвратит использование других логинов в качестве одного и того же пользователя, выйдите из системы, просто запустите простой запрос, который удаляет зарегистрированные данные в базе данных, это также можно использовать для отслеживания входа в систему на сайте пользователя на веб-сайте одновременно.

Ответ 6

Очевидно, что когда вы установите cookie сеанса в браузере, этот файл cookie отправляется в запросе. Теперь, когда запрос приходит, сервер проверит идентификатор сеанса в базе данных и предоставит доступ. Чтобы предотвратить его сохранение только агента и ip, чтобы перед проверкой сервера удостоверился, что доступ к сеансам предоставляется уникальному клиенту, а не уникальный идентификатор сеанса, который может быть захвачен.

Ответ 7

Я хорошо знаю о кодирующей части. Поэтому я могу сказать, что это алгоритм. Настройка таких файлов, как SSL, или настройка cookie сеанса для защиты, а httpOnly не работает, если пользователь нюхает идентификатор сеанса из локальной сети (если пользователь и злоумышленник находятся в одной локальной сети).

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

Ответ 8

@Anandu M Das:

Я считаю, что вы можете ссылаться на использование токенов сеанса с каждым идентификатором сеанса. Этот сайт может объяснить использование токенов с сеансами:

https://blog.whitehatsec.com/tag/session-token/

Хотя токены сеанса легко скомпрометированы атакой XSS, это не означает, что они никогда не должны использоваться. Я хочу сказать, что если что-то было компрометировано уязвимостью безопасности на сервере, это не ошибка метода, это ошибка программиста, который ввел эту уязвимость (чтобы выделить точки, сделанные Hesson и Rook).

Если вы соблюдаете надлежащие соглашения и практики безопасности и защищаете свой сайт от SQL-инъекций, XSS и требуете управления всеми сеансами через HTTPS, вы можете легко управлять потенциальной атакой из CSRF с помощью токенов на стороне сервера, хранящихся в сеанс и обновляться каждый раз, когда пользователь вызывает манипуляции с их сеансом (например, отправляемый $_POST). Кроме того, НИКОГДА не храните сеансы или их содержимое в URL-адресе, независимо от того, насколько хорошо вы думаете, что они закодированы.

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

Ответ 9

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

  • Подслушивание сети
  • Невольная экспозиция
  • Переадресация, Прокси и Фишинг
  • Обратные Прокси

Всегда рекомендуем SSL Secure Sockets Layer
Используйте куки также для следования директивам ini_set() в начале ваших скриптов, чтобы переопределить любые глобальные настройки в php.ini:

ini_set( 'session.use_only_cookies', TRUE );                
ini_set( 'session.use_trans_sid', FALSE );

Используйте тайм-ауты сессии и идентификатор регенерации сессии

<?php
// regenerate session on successful login
if ( !empty( $_POST['password'] ) && $_POST['password'] === $password )         
{       
 // if authenticated, generate a new random session ID
  session_regenerate_id();

 // set session to authenticated
  $_SESSION['auth'] = TRUE;

 // redirect to make the new session ID live

 header( 'Location: ' . $_SERVER['SCRIPT_NAME'] );
}                   
// take some action
?>