Предотвращение перехвата файлов cookie сеанса БЕЗ SSL

Question

Чтобы предотвратить перехват сеанса, я попытался назначить конкретное имя файла cookie каждому пользователю на основе этих переменных: User-agent и IP Address.

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

static function getSessionName(){
    $id= @md5(base64_encode(self::$secretToken.$_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"]));
    while(is_numeric($id{0})){
        $id = substr($id, 1).$id{0};
    }
    return $id;
}

Это означает, что у каждого пользователя, который посещает мой веб-сайт, будет свое имя файла cookie сеанса. Он заблокирует угонщику использование файлов cookie кого-либо другого, если только он не сменит своего пользовательского агента на пользовательский агент жертвы; и пытается каким-то образом появиться в сети, используя IP-адрес жертвы, например, используя интернет-модем пользователя, маршрутизатор, NAT и т. д.

Позвольте мне объяснить это на примере. Таким образом, если два пользователя используют один и тот же браузер и подключаются с одного IP-адреса, они получают одинаковые имена файлов cookie (предположим, f5e30acc605e938b097dee73c0272470).

Теперь скрипт будет искать идентификатор сессии в файле cookie с именем f5e30acc605e938b097dee73c0272470 на этих двух клиентах. В этом случае один из клиентов может захватить cookie другого пользователя. Тот же IP, тот же User-Agent и то же имя cookie!

Этот метод хорош, но не совсем безопасен. Изменить user-agent не так сложно, и жертва и угонщик могут иметь равные IP-адреса, если они подключаются из общедоступных сетей, таких как Coffenets, Public hotspots и т. Д.

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

У кого-нибудь есть предложения по этой проблеме?

Как я выяснил, одним из решений было использование SSL и безопасных файлов cookie. Но я ищу решение без использования SSL.

Answer 1

Если вы основываете свой Senario на предположении, что

1) Злоумышленник может иметь один и тот же IP-адрес и 2) Злоумышленник может притвориться, что имеет того же агента пользователя, что и доступ к любой информации, передаваемой по сети.

Тогда вы не сможете проверить личность этого куки. Это потому, что вы предположили, что вся эта информация доступна.

У вас есть два решения: а) использовать SSL; б) полагать, что ваши пользователи не будут находиться в той же кофейне, что и злоумышленник, что IP-адрес действителен, и что ваш сайт еще не настолько важен, чтобы заслуживать крупномасштабную атаку., Что они еще могут сделать - делать оскорбительные сообщения и спам? Они могли бы сделать это в любом случае со своими собственными счетами.

Исходя из своего опыта и прочитанного, я согласен с утверждением о том, что "преждевременная оптимизация - это [одно из величайших зол программирования]". Сконцентрируйте свое время на создании сайта, который работает и будет полезен для людей, а затем, если что-то пойдет не так, подумайте о получении сертификата SSL. У вас просто нет денег на сертификат, и у вас нет денег, потому что ваш сайт еще не был успешным (сделайте это сначала).

"Преждевременная оптимизация" и параноидальные меры безопасности являются соблазном для программистов, потому что нам нравится думать о себе как о работе над крупными, очень важными проектами, когда мы еще не [еще].