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

В частности, это касается использования cookie сеанса клиента для идентификации сеанса на сервере.

Является ли лучший ответ - использовать шифрование SSL / HTTPS для всего веб-сайта, и у вас есть лучшая гарантия, что ни один человек, участвующий в атаке посередине, не сможет прослушать существующий файл cookie сеанса клиента?

И, возможно, лучше всего использовать какое-то шифрование самого значения сеанса, которое хранится в вашем cookie сеанса?

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

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

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

РЕДАКТИРОВАТЬ : этот ответ был первоначально написан в 2008 году. Сейчас 2016 год, и нет причин не использовать SSL на всем вашем сайте. Нет больше открытого текста HTTP!

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

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

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

SessionUUID, серийный номер, текущая дата / время

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

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

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

Я добился большого успеха со следующим методом для сайтов, не имеющих сертификата SSL.

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

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

   • При перезагрузке выполняется несколько проверок.
   • Исходный 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.
}

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

Мы добавляем User Agent и X-FORWARDED-FOR, чтобы сделать все возможное, чтобы зафиксировать уникальность сеанса для систем, находящихся за прокси / сетями. Возможно, вы сможете использовать больше информации, не стесняйтесь проявлять творческий подход.

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

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

Сессии с истекшим сроком действия, не позволяйте им оставаться в силе бесконечно.

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

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

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

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

Что касается простоты развертывания:

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

Вкратце: он безопасный, легкий, у меня работает просто отлично.

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

Метод предотвращения перехвата сеанса:

1 - всегда использовать сессию с ssl-сертификатом;

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

2 - используйте идентификатор регенерации сеанса при входе в систему и выходе из системы (примечание: не используйте регенерацию сеанса при каждом запросе, потому что, если у вас есть последовательный запрос 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 - лично я храню данные сеанса в базе данных, выбор метода зависит от вас.

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

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

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

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

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

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

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

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

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

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

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

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

@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 для хеширования значения, используя пример, приведенный в разделе Хеширование SHA-256 на baeldung.

Жду ваших комментариев.

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

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

Защищать:

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