Это касается двух отдельных вопросов.
Во-первых, угон сеанса . Именно здесь третья сторона обнаруживает, скажем, аутентифицированный файл cookie и получает доступ к чужим данным.
Во-вторых, безопасность данных сеанса . Под этим я подразумеваю, что вы храните данные в куки (например, имя пользователя). Это не очень хорошая идея. Любые такие данные принципиально ненадежны, так же как данные форм HTML ненадежны (независимо от того, какие проверки Javascript и / или ограничения длины HTML вы используете, если таковые имеются), потому что клиент может свободно отправлять то, что он хочет.
Вы часто будете находить людей (справедливо) выступающих за дезинфекцию данных HTML-форм, но данные cookie будут приниматься вслепую по номинальной стоимости. Большая ошибка. На самом деле, я никогда не храню информацию в куки. Я рассматриваю это как ключ сеанса, и это все.
Если вы намереваетесь сохранить данные в cookie-файле, я настоятельно рекомендую вам пересмотреть.
Шифрование этих данных не делает информацию более надежной, поскольку симметричное шифрование подвержено атаке методом перебора. Очевидно, что AES-256 лучше, чем, скажем, DES (хех), но 256-битная защита не обязательно означает столько, сколько вы думаете.
С одной стороны, СОЛЬ, как правило, генерируются в соответствии с алгоритмом или иным образом подвержены атакам.
С другой стороны, данные cookie являются основным кандидатом для атак crib . Если известно или подозревается, что имя пользователя находится в зашифрованных данных, то это будет ваша кроватка.
Это возвращает нас к первому пункту: угон.
Следует отметить, что в средах общего хостинга в PHP (в качестве одного примера) ваши данные сеанса просто хранятся в файловой системе и могут быть прочитаны кем-либо еще на этом же хосте, хотя они не обязательно знают, какой сайт это для. Поэтому никогда не храните незашифрованные пароли, номера кредитных карт, обширные личные данные или что-либо, что могло бы считаться конфиденциальным в данных сеанса в таких средах без какой-либо формы шифрования или, что еще лучше, просто сохраняя ключ в сеансе и сохраняя фактический конфиденциальный данные в базе данных.
Примечание: вышеописанное не является уникальным для PHP.
Но это шифрование на стороне сервера.
Теперь вы можете утверждать, что шифрование сеанса с некоторыми дополнительными данными сделает его более безопасным от угона. Типичным примером является IP-адрес пользователя. Проблема в том, что многие люди используют один и тот же ПК / ноутбук в разных местах (например, в точках доступа Wi-Fi, на работе, дома). Также многие среды будут использовать различные IP-адреса в качестве адреса источника, особенно в корпоративных средах.
Вы также можете использовать пользовательский агент, но это предположительно.
Так что, насколько я могу судить, нет никакой реальной причины использовать шифрование cookie вообще. Я никогда не думал, что был, но в свете этого вопроса я пошел, чтобы быть доказанным, правильно или неправильно. Я обнаружил несколько потоков о людях, предлагающих способы шифрования данных cookie, прозрачного выполнения этого с помощью модулей Apache и т. Д., Но все это, кажется, мотивировано защитой данных, хранящихся в cookie (что, я думаю, не следует делать).
Мне еще предстоит увидеть аргумент безопасности для шифрования файла cookie, который представляет собой не что иное, как сеансовый ключ.
Я с радостью ошибусь, если кто-то укажет на что-то обратное.