терминология

• Пользователь: посетитель.
• Клиент: конкретное программное обеспечение, поддерживающее веб-интерфейс, установленное на конкретной машине.

Понимание сеансов

Чтобы понять, как сделать вашу сессию безопасной, вы должны сначала понять, как работают сессии.

Давайте посмотрим на этот фрагмент кода:

 session_start(); 

Как только вы это назовете, PHP будет искать cookie с именем PHPSESSID (по умолчанию). Если он не найден, он создаст один:

 PHPSESSID=h8p6eoh3djplmnum2f696e4vq3 

Если он найден, он принимает значение PHPSESSID а затем загружает соответствующий сеанс. Это значение называется session_id .

Это единственное, что узнает клиент. Все, что вы добавляете в переменную сеанса, остается на сервере и никогда не передается клиенту. Эта переменная не изменяется, если вы меняете содержимое $_SESSION . Он всегда остается неизменным до тех пор, пока вы не уничтожите его, или он не истечет. Поэтому бесполезно пытаться обфузировать содержимое $_SESSION путем его хэширования или другими способами, так как клиент никогда не получает или не отправляет эту информацию.

Затем, в случае нового сеанса, вы установите переменные:

 $_SESSION['user'] = 'someuser'; 

Клиент никогда не увидит эту информацию.

Проблема

Проблема с безопасностью может возникать, когда злоумышленник крадет session_id другого пользователя. Без какой-либо проверки он сможет свободно выдать себя за этого пользователя. Нам нужно найти способ уникальной идентификации клиента (а не пользователя).

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

 if(logging_in()) { $_SESSION['user'] = 'someuser'; $_SESSION['ip'] = $_SERVER['REMOTE_ADDR']; } // The Check on subsequent load if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) { die('Session MAY have been hijacked'); } 

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

Другая стратегия включает проверку пользовательского агента клиента:

 if(logging_in()) { $_SESSION['user'] = 'someuser'; $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT']; } // The Check on subsequent load if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) { die('Session MAY have been hijacked'); } 

Недостатком этой стратегии является то, что если клиент обновит браузер или установит аддон (некоторые добавят к пользовательскому агенту), строка пользовательского агента изменится, и это вызовет ложное предупреждение.

Другая стратегия – повернуть session_id на каждые 5 запросов. Таким образом, session_id теоретически не остается достаточно долго, чтобы быть захваченным.

 if(logging_in()) { $_SESSION['user'] = 'someuser'; $_SESSION['count'] = 5; } // The Check on subsequent load if(($_SESSION['count'] -= 1) == 0) { session_regenerate_id(); $_SESSION['count'] = 5; } 

Вы можете комбинировать каждую из этих стратегий по своему усмотрению, но вы также будете комбинировать недостатки.

К сожалению, ни одно решение не является безупречным. Если ваш session_id скомпрометирован, вы в значительной степени сделали это. Вышеупомянутые стратегии – это просто меры остановки.

Это нелепо.

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

Кто-то опубликовал это, например:

Поэтому, когда пользователь входит в систему:

// не самый безопасный хэш! $ _SESSION ['checksum'] = md5 ($ _ SESSION ['username']. $ Salt);

И перед тем, как войти в чувствительную область:

if (md5 ($ _ SESSION ['username']. $ salt)! = $ _SESSION ['checksum']) {
handleSessionError (); }

Давайте рассмотрим, что не так с этим

1. Соли – Не ошибаюсь, но бессмысленно. Никто не взламывает ваш проклятый md5, который заботится, если он солен
2. сравнивая md5 переменной SESSION с md5 той же переменной, хранящейся в SESSION, вы сравниваете сеанс с сеансом. Если вещь захвачена, это ничего не сделает.

 $_SESSION['logged_in'] = 1; $_SESSION['username'] = $username; // user's name $_SESSION['hash'] = md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT']); 

// имя пользователя хэшировано, чтобы избежать манипуляций

Избежать манипуляции кем? волшебные сеансовые феи? Ваши переменные сеанса не будут изменены, если ваш сервер не будет скомпрометирован. Хэш только на самом деле хорошенько сконденсирует вашу строку в строку из 48 символов (пользовательские агенты могут получить немного длинный).

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

Который был, вы дошли до печальной истины.

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

Здесь вы можете найти руководство по безопасности сеансов в PHP.

Вы можете сохранить IP-адрес, подпись браузера и т. Д., Чтобы идентифицировать пользователя. При каждом запросе проверьте его на текущие значения, чтобы узнать, произошло ли что-либо подозрительное.

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

Думаю, второй должен быть «logged_in»?

Некоторые ресурсы, касающиеся безопасности сеанса:

phpsec

Шифлетт

Вы можете украсть сеансы с помощью javascript (XSS-> crossside scripting attack). Вы должны всегда использовать соленое MD5 Hash для обеспечения безопасности сеанса.

Чтобы избежать захвата сеанса, вы должны поместить пользовательский агент

$ _SERVER [ 'HTTP_USER_AGENT']

в хэш.

В вашем примере:

 $_SESSION['logged_in'] = 1; $_SESSION['username'] = $username; // user's name $_SESSION['hash'] = md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT']); // user's name hashed to avoid manipulation 

Перед использованием сеанса убедитесь, что он использует правильный хеш:

 if (!$_SESSION['hash']==md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT'])){ die ('session hash not corrected') } 

Чтобы предотвратить фиксацию сеанса, которая в основном угадывает SID или крадет его с помощью различных методов. Независимо от того, насколько утончена ваша логика сеанса, она определенно будет уязвима для кражи sessid до некоторой степени. Вот почему вы должны восстанавливать идентификатор каждый раз, когда вы делаете что-то важное. Например, если вы собираетесь делать сообщение или изменять настройки в admin, сначала запустите session-restore-id. Затем хакер должен снова пройти процесс взлома. Это в основном дает хакеру одноразовый снимок с идентификатором все время, которое он потратил впустую.

http://us.php.net/manual/en/function.session-regenerate-id.php

Или вы можете каждый раз менять идентификатор

if ($ _ SESSION ['counter'] == 3) {session_regenerate_id (); $ _ SESSION ['counter'] == 0}

Кроме того, $ _SERVER ['HTTP_USER_AGENT'] не очень надежный. Попытайтесь избежать этого не только по этой причине, но и потому, что для хакеров bc они знают, что для этого широко используются агенты. Вместо этого попробуйте использовать $ _SESSION ['id_token'] = sha1 (некоторые сумасшедшие данные, такие как файловая память, имя файла, время).

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

Поэтому, когда пользователь входит в систему:

 // not the most secure hash! $_SESSION['checksum'] = md5($_SESSION['username'].$salt); 

И перед тем, как войти в чувствительную область:

 if (md5($_SESSION['username'].$salt) != $_SESSION['checksum']) { handleSessionError(); } 

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

Вы можете запрограммировать собственную обработку сеанса с использованием баз данных для дополнительной безопасности. Некоторые более строгие CMS, такие как Joomla, также регистрируют IP. Однако это вызывает проблемы для людей, использующих определенный интернет-провайдер

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

Пример: «###. ###. ### .—» Будет проверена только часть IP-адреса, помеченного знаком «#».

192.168.1.101
192.168.1.102
192.168.1.XXX

Все считаются равными.

Иаков