Вопросы Теги

Что я должен сохранить на php сессии, когда пользователь вошел в систему?

Самый легкий метод должен использовать sys.path.append ().

Однако можно также интересоваться импорт модуль. Это обеспечивает доступ к внутренним функциям импорта. 

# mod_name is the filename without the .py/.pyc extention
py_mod = imp.load_source(mod_name,filename_path) # Loads .py file
py_mod = imp.load_compiled(mod_name,filename_path) # Loads .pyc file

Это может привыкнуть к загрузочным модулям динамично, когда Вы не знаете имя модуля.

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

кроме того, эти функции могут быть полезными: 

imp.find_module(name[, path])
imp.load_module(name, file, pathname, description)

18
задан bbtang 4 August 2009 в 03:19
поделиться

9 ответов

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

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

Общие сведения о сеансах

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

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

session_start();

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

PHPSESSID=h8p6eoh3djplmnum2f696e4vq3

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

Это единственное, что будет знать клиент. Все, что вы добавляете в переменную сеанса, остается на сервере и никогда не передается клиенту. Эта переменная не t изменится, если вы измените содержимое $ _ 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 скомпрометирован, с вами почти все кончено.

45
ответ дан 30 November 2019 в 05:57
поделиться

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

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

1
ответ дан 30 November 2019 в 05:57
поделиться

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

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

$ _ 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')
}
1
ответ дан 30 November 2019 в 05:57
поделиться

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

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

phpsec

shiftlett

1
ответ дан 30 November 2019 в 05:57
поделиться

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

1
ответ дан 30 November 2019 в 05:57
поделиться

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

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

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

И перед входом в конфиденциальную область: 

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

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

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

0
ответ дан 30 November 2019 в 05:57
поделиться

Это смешно.

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

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

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

// не самый безопасный хеш! $ _SESSION ['контрольная сумма'] = md5 ($ _ SESSION ['username']. $ salt);

И перед входом в конфиденциальную область:

if (md5 ($ _ SESSION ['username']. $ salt) ! = $ _SESSION ['контрольная сумма']) {
handleSessionError (); }

Давайте разберемся, что не так с этой

  1. солью - не неправильно, но бессмысленно. Никто не взламывает ваш чертов md5, кого волнует, если он соленый
  2. , сравнивая md5 переменной SESSION с md5 той же переменной, хранящейся в SESSION - вы сравниваете сеанс с сеансом. Если вещь угнана, это ничего не даст. 
 $ _ SESSION ['logged_in'] = 1;
$ _SESSION ['имя пользователя'] = $ имя пользователя; // имя пользователя
$ _SESSION ['hash'] = md5 ($ YOUR_SALT. $ Username. $ _ SERVER ['HTTP_USER_AGENT']);

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

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

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

Вот и вы попали в печальную правду.

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

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

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

13
ответ дан 30 November 2019 в 05:57
поделиться

Чтобы предотвратить фиксацию сеанса, которая заключается в угадывании SID или его краже с использованием различных методов. Независимо от того, насколько сложна логика вашей сессии, она определенно будет в некоторой степени уязвима для систематического воровства. Вот почему вам нужно восстанавливать идентификатор каждый раз, когда вы делаете что-то важное. Например, если вы собираетесь опубликовать сообщение или изменить настройку в админке, сначала запустите session-redurate-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 '] не очень надежен. Старайтесь избегать этого не только по этой причине, но и потому, что это удобно для хакеров, так как они знают, что для этого широко используются агенты. Вместо этого попробуйте использовать $ _SESSION ['id_token'] = sha1 (какая-то сумасшедшая информация, такая как файловая память, имя файла, время).

1
ответ дан 30 November 2019 в 05:57
поделиться

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

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

192.168.1.101
192.168.1.102
192.168.1.XXX

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

Джейкоб

0
ответ дан 30 November 2019 в 05:57
поделиться
Другие вопросы по тегам:

Похожие вопросы: