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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

действительно ли соль и хэш необходимы на что-то вроде этого [отпечаток пальца клиента http]?

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

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

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

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

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