Защитить аутентифицированный сеанс PHP с сеанса Увлечение пакетом sniffing

Question

Я заинтересован в вопросе обеспечения безопасности сеансов PHP без использования SSL.

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

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

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

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

Answer 1

Предлагаемое решение для «подписания» требует поведения на стороне клиента - для этого вам необходимо приложение на стороне клиента, которое может выполнять подписку.

Если вы пишете Flash/Java-апплет/Unity или любой из этих плагинов, вы можете следить за своим планом, так как вы можете более точно контролировать клиента и добавлять подпрограммы для подписи.

Но я предполагаю, что вы отлаживаете HTML-страницы в браузере без использования плагина? Если это так, у вас есть два варианта. Кулак - это SSL (который вы исключаете), поскольку он встроен в браузер. Второй - Javascript. Для максимальной безопасности вам нужно как-то имитировать SSL, в том числе с клиентским хранилищем ключа шифрования (общедоступного)/algorythm (чтобы они никогда не путешествовали вместе с сообщениями). Вы бы хотели как можно ближе подойти к общедоступному/закрытому ключу + квитирование SSL, что не является чем-то вроде подвига. Как предложил sarnold, вам нужен сильный ключ encyption. Посмотрите на http://www.jcryption.org/ для примера - другие появляются с поисковой системой.

Если это немного над чем-то, ваше наиболее жизнеспособное решение, вероятно, должно было бы обсудить более простой encyption algorthym с помощью JS: вы отправляете «ключ», сохраняете «ключ» в файле cookie в браузере, все коммуникации через AJAX и вы создаете более простой маханизм подписи на основе этого ключа (плюс, возможно, другую переменную, которую клиент поделился с вами во время первоначального рукопожатия).Все, что не расшифровывает или не соответствует ключу, а затем убивает весь сеанс и запускается снова.

---

sarnold имеет хорошие моменты в своем ответе, что следует избегать md5 и SHA-1; и некоторые даже считают SHA256 получать wesk для сегодняшних компьютеров, но, учитывая, что вам нужно внедрить решение в JS, для скорости вы можете быть привязаны к чему-то вроде «piddly» (моя аналогия) как md5. Таким образом, ваша лучшая защита для этого - точная регистрация и грубая сила/обнаружение ошибок. Любые сообщения, поступающие искаженные (и вы можете проверить на обоих концах), должны регистрироваться и контролироваться. Слишком много сбоев и IP-адрес становятся запрещенными - и продолжайте вести журнал.

Answer 2

Вы бы хотели использовать что-то вроде HMAC вместо вашего более простого MD5 - и вы бы хотели использовать SHA256 или больше, поскольку MD5, как известно, имеет слабые места, и SHA-1 тоже начинает слабеть.

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

Для этого вам необходимо добавить nonce к протоколу.

Существуют другие проблемы - в конце концов, TLS теперь находится на версии 1.2 после трех итераций SSL. Просто придерживайтесь TLS и будьте счастливы.