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

Question

Пожалуйста, ПРОЧИТАЙТЕ это ТРОГОВОЕ перед голосованием ...

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

Генерация этого отпечатка обычно происходит при каждом запросе, чтобы убедиться, что текущий пользователь сеанса находится в исходном сеансе.пользователь.Вот почему мне интересно, действительно ли salt и hash действительно необходимы для чего-то подобного?

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

Любая информация с благодарностью.

Answer 1

В большинстве случаев это имеет смысл, но хеширование и засоление не имеют смысла.

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Теперь давайте представим реалистичный компромисс.Существует несколько способов скомпрометировать сеанс на стороне сервера:

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

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

На этом первом этапе компрометации злоумышленник может потенциально (и с возрастающей степенью серьезности):

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

действительно ли нужна соль и хэш для чего-то вроде этого [отпечаток клиента http]?

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

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

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

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

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