Хеширование отпечатка пальца сеанса действительно необходимо?

Ответ 1

Большая часть этого имеет смысл, но хеширование и соление не имеют никакого смысла.

Если вы привязываете сеанс к IP-адресу, становится намного сложнее захватить сессию. Это то, что я рекомендую делать, но вам не нужно быть абсолютно строгим. Вы можете просто привязать к первым трем частям IPv4 или около того. Выбор ваш. Чем более строгий IP-контроль, тем он более безопасен, но он менее удобен для пользователей.

А что касается привязки сеанса на основе пользовательского агента, это также может помочь. Должно быть понятно, что если вы работаете с незашифрованным каналом (например, HTTP), проверка агента пользователя менее полезна, так как она может быть воспроизведена также злоумышленником.

Когда дело доходит до соления и хеширования, это бесполезно. Они не добавляют силы для проверки вашей личности. Единственное, что они делают, это усложнить ваш дизайн. По этому вопросу я считаю, что они снижают уровень безопасности.

Как всегда, нужно иметь в виду несколько правил:

• Используйте сильные идентификаторы сеанса. Это означает использование хороших случайных источников и убедитесь, что их достаточно.
• Свяжите сеанс с IP, по крайней мере в некоторой степени.
• Свяжите сеанс с пользовательским агентом, если это возможно.
• Использовать SSL/TLS. Без этого теоретически все сеансовые системы небезопасны.
• Защитите хранилище сеансов. Независимо от того, основана ли база данных на базе файловой системы или базы данных.

Ответ 2

Я могу думать о двух случаях, когда это было бы полезно:

• Когда данные сеанса хранятся на стороне клиента. (Как в cookie.) Таким образом, мне не удастся взять мой файл cookie на другой компьютер, и мне не удастся составить собственное содержимое cookie. (Хорошо, так что это не очень вероятный сценарий...)
• Когда данные сеанса хранятся в некотором общем ресурсе на стороне сервера (т.е./tmp) и уязвимы для отслеживания. В этом случае, если snooper может видеть содержимое сеанса, они все равно не смогут подделать соединение с этим сеансом, потому что они не знают, какие данные вошли в отпечаток.

Ответ 3

В дополнение к ответу @Kai Sellgren (+1), в котором содержатся некоторые полезные советы о том, как защитить хранилище сеансов, я бы добавил несколько идей, чем мог бы объяснить хэш и соль в некоторых конкретных приложениях.

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

Ключевым моментом является многоуровневая защита и глубокая защита:

Компромиссы никогда не являются логическими, а ваши "не скомпрометированы" или "полностью защищены". Одна из реальной истории, которую мне нравится в этом, - это описание mySpace worm, она показывает реальную атаку и как защитные шаги должны быть разбиты. Там всегда новая стена. Только один пример, я использую тот же IP-адрес, что и мой босс, когда я нахожусь в офисе, и, возможно, тот же браузер, это может сломать защиту, основанную только на пользовательском-агенте IP +.

Таким образом, в хеше и соли тимпинга сессии мы явно действуем после того, как несколько стен упали. И кай показывает нам некоторые из этих стен. Когда он расскажет о защите хранилища сеансов, я добавлю две вещи:

• Это действительно хорошая идея, чтобы изменить session.save_path и open_basedir каждого приложения PHP (и получить отдельный Virtualhost для каждого). Редко сделано.
• Если ваше приложение установлено на пути (например,/myapp), добавьте prefix_path в файл cookie сеанса (и исправьте его для любого другого приложения на том же сервере).

Теперь представьте себе реалистичное расследование. У вас есть несколько способов скомпрометировать сеанс на стороне сервера:

• Приложение выполняется на веб-сайте с некоторыми другими приложениями, запущенными на других путях (или в других доменах на одном сервере). И, по крайней мере, на приложениях тезисы совершенно небезопасны. В худшем случае код сервера может быть добавлен в это приложение, но некоторые из стен безопасности (например, open_basedir или другие методы chrooting) могут помешать этому введенному коду влиять на ваше отдельное приложение (или данные).
• В некоторых библиотеках javascript есть несколько подкаталогов тестов, содержащих очень небезопасные скрипты, с не только приятным раскрытием сеанса, но, возможно, доступной фиксацией сеанса или предсказанием.
• Приложение является общим, и, говоря о soft-программах, подобных Wordpress, вы можете представить себе, как некоторые платформы используют множество разных установок, с различными модулями и, возможно, с каким-то специальным кодом. На таких платформах вы найдете настройки, позволяющие изменять соль для каждого потребителя, и есть причина для этого. Один из веб-сайтов может повлиять на безопасность других, и очистить разделение может быть сложнее, если приложения хотят управлять сайтами "все-в-одном".

Ваше целевое приложение может пострадать от среды, если хранилище сеансов может быть совместно использовано некоторыми сценариями из другого приложения или из script в вашем собственном приложении, которое вы даже не заметили (например, эти f ** * примеры в javascript libs, почему вы не приостановили выполнение php в статических файловых каталогах!)

Из этого первого шага сглаживания злоумышленник может потенциально (и при увеличении степени тяжести):

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

Простой хэш штампа сделает его жизнь более трудной, но просто сломать стену, соль сделает эту стену действительно труднее сломать.

Одним из важных моментов является ваш вопрос: , если парень может что-то изменить в хранилище сеансов, я уже в плохом настроении?. Ну, может быть, не полностью. Если это единственное, что хрут/разделение/закрепление приложений позволяет ему делать эту соль, это будет для него кошмаром.

И второй важный момент: должен ли я выполнять этот уровень глубинной безопасности для каждого веб-приложения?. Ответ - нет. переустройстваэто плохая вещь и может снизить безопасность вашего приложения по простому факту стало сложнее понять и maitin. Вам не нужно усложнять ваше приложение, если:

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

Ответ 4

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

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

Ответ 5

Вы можете найти правдоподобное решение здесь: http://shiflett.org/articles/the-truth-about-sessions

Фингерпринт сражается с захватом сеанса. Злоумышленнику нужен не только ваш session_id, он также нуждается в любых секретных HTTP-заголовках. Это добавляет еще один барьер для злоумышленника, хотя тот, который можно легко преодолеть.

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

Если хакер находится в вашей файловой системе, у вас больше проблем: D

Ответ 6

Многие люди, которые не очень разбираются в безопасности, объединяют кусочки советов, плавающих по интернету, в надежде, что то, что они в конечном итоге, будет "достаточно хорошим". Привязка идентификатора сеанса к U-A ​​прерывает обновления браузера (что делает Chrome довольно часто), а привязка к IP-адресу ломает мобильность (у кого есть ноутбук, использующий Wi-Fi), и многие интернет-провайдеры не имеют смежных распределений. Любой, кто может обнюхивать куки файлы, также может нюхать U-A и, вероятно, будет иметь доступ к одному и тому же IP-адресу, потому что они получили cookie от небезопасного Wi-Fi за NAT.

То, что вы, вероятно, хотите сделать, это изменить идентификатор сеанса при попытке входа в систему, что является надежным способом предотвращения атак типа "фиксация сеанса" (где злоумышленник делает жертву нагрузкой http://example.com/?SESSIONID=foo, например, через <img>, ждет входа в систему и теперь знает идентификатор сеанса жертвы). Существует мало оснований для сохранения сеанса во время входа в систему, и вы можете скопировать несколько вещей, которые необходимо сохранить (например, в корзине покупок).

Ответ 7

Если хакер может попасть на вас файловой системы для просмотра файла сеанса содержимое, вы уже не были эта точка?

Если вы используете PHP как CGI (как в случае с nginx), то я думаю, что нет. Если вы установите права доступа, то ваши файлы сеансов должны иметь права на чтение и запись для пользователя PHP, в то время как ваши файлы PHP должны иметь только разрешения на чтение. Итак, если вы передаете соль с веб-сервера на PHP, тогда пользователь PHP не сможет получить к нему доступ (он не может создавать какие-либо новые/изменять существующие файлы PHP, которые могут запускаться вашим веб-сервером, и он не может доступ к веб-серверу, поскольку он запущен на другом пользователе), поэтому он не может реально взломать (изменить) файлы cookie (удалить их только), потому что он не может получить соль. Конечно, вам также придется передавать настройки базы данных с веб-сервера.

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

Ответ 8

- это соль и хеш, действительно необходимые для чего-то вроде этого [http client fingerprint]?

Хэш может быть полезен для уменьшения количества байтов, потребляемых отпечатком пальца внутри данных сеанса. Таким образом, пока хешированный отпечаток пальца имеет меньший размер, чем сам отпечаток пальца, это может иметь смысл с точки зрения сокращения пространства. Цена - это потребление системных ресурсов для генерации хэша.

Это действительно имеет смысл? Вам нужно было бы сравнить это, чтобы сказать это.

Как соль может быть полезной? Должен признаться, я не вижу причины для соли. Было бы разумно усложнить угадание отпечатка пальца из хэша. Но поскольку я не вижу преимуществ безопасности при хэшировании отпечатка пальца (он хранится только на стороне сервера и уже значительно безопасен), соление ничего не добавляет.

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

Так что, особенно для отпечатка пальца, я не вижу большого использования в хешировании и засовывании его.