Ответ 1

Нет, сеанс хранится на сервере и не может быть доступен пользователю. Он используется для хранения информации на сайте, например, сеансов входа в систему.

Вот пример использования:

<?php
session_start();
if (password_verify($_POST['password'], $hash)) {
    $_SESSION['auth'] = true;
}
?>

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

<?php
session_start();
if ($_SESSION['auth']) {
    echo "You are logged in!";
}
?>

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

Ответ 2

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

Что делать

Эта информация взята из "Основы управления сессиями" в руководстве по PHP, но немного упрощена. Некоторые вещи, возможно, были пропущены. Обязательно прочитайте это также.

1. Всегда используйте HTTPS

   • Запрещает злоумышленникам читать куки с идентификатором сессии

2. Включить session.use_strict_mode:

   • Отклоняет неинициализированные идентификаторы сеанса
   • Гарантирует, что любые созданные сеансы действительно действительны, поэтому вы можете доверять префиксу (например, если префикс $userId-)

3. Включите sessions.use_only_cookies и отключите session.use_trans_sid

   • Предотвращает случайное совместное использование идентификатора сеанса, предоставляя URL-адрес с идентификатором сеанса в нем
   • Предотвращает появление идентификатора сеанса в заголовке Referer

4. Периодически обновлять идентификатор сеанса и аннулировать старые идентификаторы сеанса вскоре после восстановления

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

5. При желании можно отслеживать дополнительную информацию в $_SESSION которая относится к запросу (IP-адрес, строка агента пользователя и т.д.)

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

Ответ 3

Ответ на этот вопрос требует 2 подхода:

• Идентификаторы сеанса PHP достаточно сложны, чтобы угадывать для большинства случаев использования. Не намного сложнее или менее сложно, чем другие широко используемые системы.

• Доверяя только cookie сеанса (и только существование сеансового файла cookie), похоже, для меня не очень-то безопасно, независимо от того, откуда этот куки файл сеанса - PHP или в другом месте.

Итак, вкратце: сеансы PHP столь же безопасны, как и их использование ими. Это верно для любой системы на основе cookie на основе сеанса, о которой я знаю.

Ответ 4

Если это сделать:

$_SESSION['user'] = $username;

Тогда $username не будет непосредственно храниться в файле cookie. Вместо этого создается уникальный идентификатор сеанса и сохраняется внутри файла cookie.

Информация, которую вы храните в $_SESSION, хранится только на сервере и никогда не отправляется клиенту. При последующем запросе клиентом сервер загружает данные сеанса по идентификатору, хранящемуся в файле cookie, когда вы выполняете session_start().

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

Ответ 5

Каким бы ни был ответ на эту тему, вы, скорее всего, не будете удовлетворены, потому что существует очень много разных мнений по этой теме. Есть даже целые книги, написанные о сеансах и безопасности PHP в целом.

Лучший ответ, который вы можете надеяться получить здесь, - это, вероятно, "сеансы настолько же безопасны, насколько вы хотите, чтобы они были". Большая работа и большее количество мер предосторожности, очевидно, сделают их более безопасными для использования, но сама реализация потребует больше времени. Как и все, что вы делаете, вы можете измерить, насколько безопасно безопасно для ваших нужд.

Ответ 6

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

Ответ 7

Это зависит от того, как вы их используете, но сами по себе они не очень безопасны.
Например, если вы используете их для создания системы входа в систему, после того, как пользователь правильно вошел в систему, на сервере будет создан сеанс (связанный с его идентификатором базы данных в качестве примера), но также будет создан и сохранен файл cookie в компьютер (большая и случайная строка), который отправляется на сервер в каждом http-запросе, чтобы связать пользовательское устройство с сеансом (вместо того, чтобы каждый раз отправлять учетные данные пользователя).
Таким образом, проблема заключается в том, что если другой пользователь реплицирует тот же файл cookie, сохраненный на вашем устройстве, сервер подумает, что он также вошел в вашу учетную запись.
Таким образом, вам нужно реализовать более безопасный способ решения этой проблемы, возможно, разрешить идентификацию сеанса только в том случае, если запрос http поступает с того же IP-адреса, с которого пользователь первоначально вошел в систему, или чего-то подобного.