Как лучше всего предотвратить захват сеанса?

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

Единственное реальное решение - это HTTPS. Если вы не хотите делать SSL на всем вашем сайте (возможно, у вас есть проблемы с производительностью), вам может сойти с рук только SSL, защищая чувствительные области. Для этого сначала убедитесь, что ваша страница входа HTTPS. Когда пользователь входит в систему, установите безопасный файл cookie (то есть браузер будет передавать его только по ссылке SSL) в дополнение к обычному файлу cookie сеанса. Затем, когда пользователь посещает одну из ваших областей "sensitive", перенаправьте их на HTTPS и проверьте наличие этого безопасного файла cookie. Реальный пользователь будет иметь его, а угонщик сессии-нет.

EDIT : этот ответ был первоначально написан в 2008 году. Сейчас 2016 год, и нет никаких причин, чтобы не иметь SSL на всем вашем сайте. Больше никакого открытого текста HTTP!

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

По крайней мере, убедитесь, что старые куки теряют свою ценность через некоторое время. Даже успешная атака угона будет сорвана, когда куки перестанет работать. Если у пользователя есть файл cookie от сеанса, который вошел в систему более месяца назад, заставьте его повторно ввести свой пароль. Убедитесь, что каждый раз, когда пользователь нажимает на ссылку "log out" вашего сайта, старый сеанс UUID никогда не может быть использован снова.

Я не уверен, что эта идея сработает, но вот что: добавьте серийный номер в свой файл cookie сеанса, возможно, такую строку:

SessionUUID, Порядковый Номер, Текущая Дата/Время

Зашифруйте эту строку и используйте ее в качестве файла cookie сеанса. Регулярно меняйте серийный номер-возможно, когда печенье будет 5 минут от роду, а затем переиздайте печенье. Вы даже можете переиздать его на каждой странице, если захотите. На стороне сервера сохраните запись последнего серийного номера, выданного для этого сеанса. Если кто-то когда-либо отправляет файл cookie с неправильным серийным номером, это означает, что злоумышленник может использовать файл cookie, который они перехватили ранее, поэтому аннулируйте сеанс UUID и попросите пользователя повторно ввести свой пароль, а затем повторно выпустить новый файл cookie.

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

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

У меня был большой успех со следующим методом для не сертифицированных сайтов SSL.

1. Dis-разрешить несколько сеансов под одной учетной записью, убедившись, что вы не проверяете это только по адресу IP. Скорее проверяйте по токену, сгенерированному при входе в систему, который хранится вместе с сессией пользователей в базе данных, а также по адресу IP, HTTP_USER_AGENT и так далее

2. Использование гиперссылок на основе отношений Генерирует ссылку ( напр. http://example.com/secure.php?знак=2349df98sdf98a9asdf8fas98df8 ) Ссылка добавляется с X-BYTE ( предпочтительный размер ) случайной соленой строкой MD5, на странице перенаправление случайно сгенерированный токен соответствует запрошенной странице.

   • После перезагрузки производится несколько проверок.
   • Исходный IP-адрес
   • HTTP_USER_AGENT
   • Токен Сеанса
   • вы понимаете, в чем дело.

3. Короткий срок службы файла cookie аутентификации сеанса. как было сказано выше, файл cookie, содержащий защищенную строку, которая является одной из прямых ссылок на валидность сеансов, является хорошей идеей. Сделайте так, чтобы он истекал каждые x минут, повторно выпуская этот маркер и повторно синхронизируя сеанс с новыми данными. Если в данных есть какие-либо несоответствия, либо выйдите из системы, либо попросите их повторно аутентифицировать свой сеанс.

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

// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();

// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);

// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
    end_session();
    header("Location: login.php");
    // add some fancy pants GET/POST var headers for login.php, that lets you
    // know in the login page to notify the user of why they're being challenged
    // for login again, etc.
}

Что это делает, так это захватывает 'contextual' информацию о сеансе пользователя, фрагменты информации, которые не должны изменяться в течение жизни одного сеанса. Пользователь не будет находиться за компьютером в 32-м и в Китае одновременно, верно? Таким образом, если адрес IP внезапно изменяется в пределах одного сеанса, что сильно подразумевает попытку захвата сеанса, поэтому вы защищаете сеанс, завершая сеанс и заставляя пользователя повторно аутентифицироваться. Это препятствует попытке взлома, злоумышленник также вынужден войти в систему вместо того, чтобы получить доступ к сеансу. Уведомите пользователя о попытке (ajax это немного вверх), и vola, слегка раздраженный+информированный пользователь и его сессия / информация защищены.

Мы включаем пользовательский агент и X-FORWARDED-FOR, чтобы сделать все возможное, чтобы захватить уникальность сеанса для систем за proxies/networks. вы можете использовать больше информации, чем это, не стесняйтесь быть творческим.

Это не 100%,, но это чертовски эффективно.

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

Истекают сеансы, не позволяйте им оставаться действительными бесконечно.

Не полагайтесь на cookies, Они могут быть украдены,это один из векторов атаки для захвата сеанса.

Попробуйте безопасный протокол Cookie, описанный в этой статье Лю, ковачом, Хуангом и гаудой:

Как указано в документе:

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

Что касается легкости deployment:

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

Короче говоря: он безопасный, легкий, работает для меня просто отлично.

Нет никакого способа предотвратить захват сеанса 100%,, но при некотором подходе мы можем сократить время, необходимое злоумышленнику для захвата сеанса.

Способ предотвращения захвата сеанса:

1-Всегда используйте сеанс с сертификатом ssl;

2-отправка файлов cookie сеанса только с httponly, установленным в true(запретить javascript доступ к файлам cookie сеанса)

2-Используйте Session regenerate id при входе и выходе из системы(примечание: не используйте session regenerate при каждом запросе, потому что если у вас есть последовательный запрос ajax, то у вас есть шанс создать несколько сеансов.)

3-Установите тайм-аут сеанса

4-хранить агент пользователя браузера в переменной $_SESSION и сравнивать с $_SERVER['HTTP_USER_AGENT'] при каждом запросе

5-Установите маркерный файл cookie и установите время истечения срока действия этого файла cookie равным 0(до тех пор, пока браузер не будет закрыт). Восстановите значение файла cookie для каждого запроса.(Для запроса ajax не восстанавливайте маркер cookie). EX:

    //set a token cookie if one not exist
    if(!isset($_COOKIE['user_token'])){
                    //generate a random string for cookie value
        $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

        //set a session variable with that random string
        $_SESSION['user_token'] = $cookie_token;
        //set cookie with rand value
        setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
    }

    //set a sesison variable with request of www.example.com
    if(!isset($_SESSION['request'])){
        $_SESSION['request'] = -1;
    }
    //increment $_SESSION['request'] with 1 for each request at www.example.com
    $_SESSION['request']++;

    //verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
    if($_SESSION['request'] > 0){

        // if it's equal then regenerete value of token cookie if not then destroy_session
        if($_SESSION['user_token'] === $_COOKIE['user_token']){
            $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

            $_SESSION['user_token'] = $cookie_token;

            setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
        }else{
            //code for session_destroy
        }

    }

            //prevent session hijaking with browser user agent
    if(!isset($_SESSION['user_agent'])){
        $_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
    }

    if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
      die('session hijaking - user agent');
    }

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

6 - это не очень хороший подход, чтобы использовать ip-адрес пользователя для предотвращения захвата сеанса, потому что некоторые пользователи ip-адреса меняются с каждым запросом. КОТОРЫЕ ВЛИЯЮТ НА ДОПУСТИМЫХ ПОЛЬЗОВАТЕЛЕЙ

7-лично я храню данные сеанса в базе данных , это зависит от вас, какой метод вы принимаете

Если вы обнаружите ошибку в моем подходе, пожалуйста, поправьте меня. Если у вас есть еще способы предотвратить сеанс хиджакинга, пожалуйста, скажите мне.

Убедитесь, что вы не используете инкрементные целые числа для сеанса IDs. Гораздо лучше использовать GUID или другую длинную произвольно сгенерированную символьную строку.

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

• IP и / или X-FORWARDED-FOR чеков. Они работают, и довольно надежно... но представьте себе боль пользователей. Они приходят в офис с WiFi, получают новый IP адрес и теряют сеанс. Нужно снова войти в систему.

• Проверка агента пользователя. Как и выше, новая версия браузера вышла, и вы теряете сеанс. Кроме того, они действительно легко "hack". Для хакеров тривиально отправлять поддельные строки UA.

• localStorage жетон. При входе в систему создайте маркер, сохраните его в хранилище браузера и сохраните его в зашифрованном файле cookie (зашифрованном на стороне сервера). Это не имеет никаких побочных эффектов для пользователя (localStorage сохраняется через обновления браузера). Это не так безопасно , как просто безопасность через неизвестность. Кроме того, вы можете добавить некоторую логику от (encryption/decryption) до JS, чтобы еще больше затуманить ее.

• Переиздание печенья. Это, вероятно, правильный способ сделать это. Хитрость заключается в том, чтобы позволить только одному клиенту использовать куки одновременно. Таким образом, активный пользователь будет иметь куки-файлы повторно выдаются каждый час или меньше. Старый файл cookie аннулируется, если выдается новый. Хаки все еще возможны, но гораздо сложнее сделать - либо хакер, либо действительный пользователь получит отказ в доступе.

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

AFAIK объект сеанса недоступен на клиенте, так как он хранится на веб-сервере. Однако идентификатор сеанса хранится в виде файла Cookie, и он позволяет веб-серверу отслеживать сеанс пользователя.

Чтобы предотвратить захват сеанса с помощью идентификатора сеанса, вы можете хранить хэшированную строку внутри объекта сеанса, созданную с помощью комбинации двух атрибутов, удаленного addr и удаленного порта, доступ к которым можно получить на веб-сервере внутри объекта запроса. Эти атрибуты привязывают сеанс пользователя к браузеру, в котором он вошел в систему.

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

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

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    HttpSession session = request.getSession();
    String sessionKey = (String) session.getAttribute("sessionkey");
    String remoteAddr = request.getRemoteAddr();
    int remotePort = request.getRemotePort();
    String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
    if (sessionKey == null || sessionKey.isEmpty()) {
        session.setAttribute("sessionkey", sha256Hex);
        // save mapping to memory to track which user attempted
        Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
    } else if (!sha256Hex.equals(sessionKey)) {
        session.invalidate();
        response.getWriter().append(Application.userSessionMap.get(sessionKey));
        response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId()); 
        response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
        return;
    }
    response.getWriter().append("Valid Session\n");
}

Я использовал алгоритм SHA-2 для hash значения, используя пример, приведенный при хэшировании SHA-256 в baeldung

С нетерпением ждем ваших комментариев.

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

Проверка заголовков рефереров также может быть опцией, но их легче подделать.

Защитите путем:

$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;