Ответ 1

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

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

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

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

Посмотрите на этот фрагмент кода:

session_start();

Как только вы это назовете, PHP будет искать куки файл под названием 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 взломан, вы в значительной степени готовы. Вышеупомянутые стратегии - это просто меры остановки.

Ответ 2

Это смешно.

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

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

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

//не самый безопасный хэш! $_SESSION ['checksum'] = md5 ($ _ SESSION [ 'имя пользователя'] $соль.);

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

$_ SERVER [ 'HTTP_USER_AGENT']

в хэш также.

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

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

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

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

Ответ 5

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

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

Ответ 6

Я предполагаю, что второй должен быть "logged_in"?

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

phpsec

shiflett

Ответ 7

Чтобы предотвратить фиксацию сеанса, которая в основном угадывает 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 (некоторые сумасшедшие данные, такие как файловая память, имя файла, время).

Ответ 8

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

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

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

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

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

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

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

Ответ 9

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

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

192.168.1.101
192.168.1.102
192.168.1.XXX

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

Jacob