Как установить начало сеанса в течение длительного времени? [Дубликат]

  1. Как это, ваше скомпилированное приложение содержит ключевые строки, но также имена констант APP_KEY и APP_SECRET. Извлечение ключей из такого самодокументирующего кода тривиально, например, со стандартным инструментом Android dx.
  2. Вы можете применить ProGuard. Он оставит ключевые строки нетронутыми, но он удалит постоянные имена. Он также переименует классы и методы с короткими бессмысленными именами, где это возможно. Извлечение ключей затем занимает больше времени, чтобы выяснить, какая строка служит для этой цели. Обратите внимание, что настройка ProGuard не должна быть такой сложной, как вы боитесь. Для начала вам нужно включить ProGuard, как описано в project.properties. Если есть проблемы с сторонними библиотеками, вам может потребоваться подавить некоторые предупреждения и / или предотвратить их запутывание в proguard-project.txt. Например:
    -dontwarn com.dropbox.**
    -keep class com.dropbox.** { *; }
    
    Это подход грубой силы; вы можете уточнить такую ​​конфигурацию, как только обработанное приложение будет работать.
  3. Вы можете запутать строки вручную в своем коде, например, с кодировкой Base64 или предпочтительно с чем-то более сложным; возможно, даже собственный код. Затем хакеру придется статически реконструировать вашу кодировку или динамически перехватить декодирование в нужном месте.
  4. Вы можете применить коммерческий обфускатор, например, специализированный sigling ProGuard DexGuard . Он может дополнительно шифровать / обфускации строк и классов для вас. Извлечение ключей потребует еще большего времени и опыта.
  5. Возможно, вы сможете запускать части своего приложения на своем собственном сервере. Если вы можете хранить ключи там, они безопасны.
  6. В конце концов, это экономический компромисс, который вы должны сделать: насколько важны ключи, сколько времени или программного обеспечения вы можете себе позволить, насколько изощренными являются хакеры, которые интересуются ключами, сколько времени они захотят потратить, сколько стоит задержка до взлома ключей, в каком масштабе будут успешными хакеры раздавать ключи и т. д. Небольшие фрагменты информации, такие как ключи, сложнее защитить, чем все приложения.

    (я разработчик ProGuard и DexGuard)

121
задан Jon 27 March 2014 в 16:25
поделиться

6 ответов

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

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

Удобство в расслабленной среде: как и почему

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

// server should keep session data for AT LEAST 1 hour
ini_set('session.gc_maxlifetime', 3600);

// each client should remember their session id for EXACTLY 1 hour
session_set_cookie_params(3600);

session_start(); // ready to go!

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

  • Если вы не сообщите клиентам, чтобы они забыли свой идентификатор сеанса через час (или если клиенты злонамерены и не хотят игнорировать ваши инструкции), они будут продолжать использовать один и тот же идентификатор сеанса, и его эффективная продолжительность будет недетерминированной. Это связано с тем, что сеансы, чье жизненное время истекло на стороне сервера, не собираются сразу же с мусором, а только всякий раз, когда сеанс GC запускается в . GC является потенциально дорогостоящим процессом, поэтому обычно вероятность будет небольшой или даже нулевой (веб-сайт, получающий огромное количество хитов, вероятно, будет полностью отказываться от вероятностного GC и планировать его в фоновом режиме каждые X минут). В обоих случаях (при условии отсутствия сотрудничающих клиентов) нижняя граница для эффективного времени жизни сеанса будет session.gc_maxlifetime, но верхняя граница будет непредсказуемой.
  • Если вы не установили session.gc_maxlifetime на тот же промежуток времени, тогда сервер может отбросить данные сеанса бездействия раньше этого; в этом случае клиент, который все еще помнит свой идентификатор сеанса, представит его, но сервер не найдет никаких данных, связанных с этим сеансом, эффективно ведет себя так, как будто сеанс только что начался.

Уверенность в критические среды

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

Сделайте это, сохранив верхнюю границу вместе с остальными данными сеанса:

session_start(); // ready to go!

$now = time();
if (isset($_SESSION['discard_after']) && $now > $_SESSION['discard_after']) {
    // this session has worn out its welcome; kill it and start a brand new one
    session_unset();
    session_destroy();
    session_start();
}

// either new or old, it should live at most for another hour
$_SESSION['discard_after'] = $now + 3600;

Сохранение идентификатора сеанса

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

264
ответ дан Greg 3 September 2018 в 13:44
поделиться

Вы можете переопределить значения в php.ini из вашего PHP-кода, используя ini_set().

0
ответ дан Nathan Q 3 September 2018 в 13:44
поделиться

Добавление комментария для любого пользователя Plesk, имеющего проблемы с любым из вышеперечисленных действий, поскольку это сводило меня с ума, установка session.gc_maxlifetime из вашего PHP-скрипта не будет работать, поскольку у Plesk есть собственный скрипт сборки мусора, выполняемый cron.

Я использовал решение, размещенное по ссылке ниже, чтобы перемещать задание cron с почасового на ежедневный, чтобы избежать этой проблемы, тогда верхний ответ выше должен работать:

mv /etc/cron.hourly/plesk-php-cleanuper /etc/cron.daily/

https: // websavers.ca/plesk-php-sessions-timing-earlier-expected

2
ответ дан Neil Walden 3 September 2018 в 13:44
поделиться

Поместите $_SESSION['login_time'] = time(); на предыдущую страницу аутентификации. И снимок внизу на каждой другой странице, где вы хотите проверить тайм-аут сеанса.

if(time() - $_SESSION['login_time'] >= 1800){        
    header("Location: logout.php");
    //redirect if the page is inactive for 30 minutes
}
else {        
   $_SESSION['login_time'] = time();
   // update value of session
}
1
ответ дан Noel Widmer 3 September 2018 в 13:44
поделиться

Если вы используете обработку сеанса по умолчанию PHP, единственный способ надежно изменить продолжительность сеанса на всех платформах - изменить php.ini . Это связано с тем, что на некоторых платформах сбор мусора реализуется через скрипт, который запускается каждое определенное время (скрипт cron ), который читается непосредственно из php.ini , и поэтому любые попытки изменение его во время выполнения, например через ini_set(), ненадежны и, скорее всего, не сработают.

Например, в системах Debian Linux сбор мусора производится через /etc/cron.d/php5, который выполняется в XX: 09 и XX: 39 (т. Е. Каждые полчаса), и если он найдет сеанс старше, чем session.gc_maxlifetime, указанный в php.ini , то этот сеанс удаляется без пощады. Это также объясняет, почему в этом вопросе: Сроки PHP слишком быстро выходят из строя , у ОП были проблемы на одном хосте, но проблемы прекратились при переключении на другой хост.

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

Доступные альтернативные методы включают в себя:

  1. Установите другой сеансовый (save) обработчик в PHP, чтобы сохранить ваши сеансы в другом каталоге или в базе данных, как указано в PHP: пользовательские обработчики сеансов (руководство по PHP) , так что задание cron не доходит до него, и только внутренняя сборка мусора PHP выполняется. Этот параметр, вероятно, может использовать ini_set() для установки session.gc_maxlifetime, но я предпочитаю просто игнорировать параметр maxlifetime в моем обратном вызове gc() и определять максимальный срок службы самостоятельно.
  2. Полностью забыть о внутренней обработке сессий PHP и реализовать собственное управление сеансом. Этот метод имеет два основных недостатка: вам понадобятся ваши собственные глобальные переменные сеанса, так что вы потеряете преимущество супер-локула $_SESSION, и ему нужен больше кода, поэтому есть больше возможностей для ошибок и недостатков безопасности. Самое главное, идентификатор сеанса должен быть сформирован из криптографически безопасных случайных или псевдослучайных чисел, чтобы избежать предсказуемости идентификатора сеанса (что приводит к возможному захвату сеанса), и это не так просто сделать с PHP портативно. Главное преимущество заключается в том, что он будет работать последовательно на всех платформах, и вы полностью контролируете код. Это подход, принятый, например, phpBB форум (по крайней мере, версия 1, я не уверен в более поздних версиях).

Пример (1) в для session_set_save_handler() . Пример длинный, но я воспроизведу его здесь, с соответствующими изменениями, необходимыми для продления продолжительности сеанса. Обратите внимание на включение session_set_cookie_params(), чтобы увеличить время жизни файла cookie.

<?php
class FileSessionHandler
{

    private $savePath;
    private $lifetime;

    function open($savePath, $sessionName)
    {
        $this->savePath = 'my_savepath'; // Ignore savepath and use our own to keep it safe from automatic GC
        $this->lifetime = 3600; // 1 hour minimum session duration
        if (!is_dir($this->savePath)) {
            mkdir($this->savePath, 0777);
        }

        return true;
    }

    function close()
    {
        return true;
    }

    function read($id)
    {
        return (string)@file_get_contents("$this->savePath/sess_$id");
    }

    function write($id, $data)
    {
        return file_put_contents("$this->savePath/sess_$id", $data) === false ? false : true;
    }

    function destroy($id)
    {
        $file = "$this->savePath/sess_$id";
        if (file_exists($file)) {
            unlink($file);
        }

        return true;
    }

    function gc($maxlifetime)
    {
        foreach (glob("$this->savePath/sess_*") as $file) {
            if (filemtime($file) + $this->lifetime < time() && file_exists($file)) { // Use our own lifetime
                unlink($file);
            }
        }

        return true;
    }
}

$handler = new FileSessionHandler();
session_set_save_handler(
    array($handler, 'open'),
    array($handler, 'close'),
    array($handler, 'read'),
    array($handler, 'write'),
    array($handler, 'destroy'),
    array($handler, 'gc')
    );

// the following prevents unexpected effects when using objects as save handlers
register_shutdown_function('session_write_close');

session_set_cookie_params(3600); // Set session cookie duration to 1 hour
session_start();
// proceed to set and retrieve values by key from $_SESSION

Подход (2) более сложный; в основном, вам необходимо повторно реализовать все функции сеанса самостоятельно. Я не буду вдаваться в подробности здесь.

25
ответ дан Pedro Gimeno 3 September 2018 в 13:44
поделиться

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

Я сомневаюсь, что вам нужно продлить время сеанса. На данный момент у него довольно разумный тайм-аут, и нет причин его продлевать.

0
ответ дан Your Common Sense 3 September 2018 в 13:44
поделиться
Другие вопросы по тегам:

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