2012-06-06 2 views
2

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

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

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

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

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

+2

Не обижайтесь, но считайте, что используете только SSL ... это может стоить от $ 49 до $ 100 в год, но это намного дешевле, чем платить разработчикам за сохранение пользовательской «схемы безопасности» –

+0

+1. Кроме того, @ João Salada, как будет отправлен случайный пароль сеанса без SSL? –

+0

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

ответ

3

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

Если вы пишете 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-адрес становятся запрещенными - и продолжайте вести журнал.

+0

Я думал о втором варианте, и этот сайт - это то, что я хотел. ;) Проблема с общедоступным/частным ключом, который является частью схемы SSL и TLS, заключается в том, что для этого требуется подписанный сертификат, который является дорогостоящим. Если, с другой стороны, вы используете сертификат, не подписанный этими verisign, и т. Д. Браузер вернет вам большое предупреждение, и большинство людей уйдет. это для моего блога ... – Leaurus

+1

Сертификаты можно получить всего за $ 20 в год. Пример: http://www.hostnexus.com/solutions/certificates-compare.php. Единственная разница в ценах - это страховки и гарантии, которые идут с ними, действительно. Вы потратите намного больше, чем пытаетесь заставить работу, отличную от ssl, работать. Но, если я пойду в одиночку, я рад, что смогу помочь. – Robbie

2

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

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

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

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

+0

Да, MD5 уязвим для префиксных атак. В качестве примера я использовал MD5. Но спасибо вам в любом случае. Просто хотел знать, имеет ли схема какие-то преимущества. и о nonce вы абсолютно правы. Спасибо;) – Leaurus

Смежные вопросы