Защита аутентифицированного сеанса PHP от перехвата сеанса с помощью перехвата пакетов

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

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

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

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

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

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

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

Поэтому вам нужно добавить в протокол nonce.

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