Защита идентификатора сессий в PHP

[DorBer]

Можно было бы добавить про session_regenerate_id().

[MarcusAurelius]

Не стоит при сохранении пароля в $_SESSION делать хешировани, но лишь потому, что паролю и даже его хешу в сессиях не место вовсе, не могу даже придумать случая, когда это нужно, ведь в $_SESSION можно хранить идентификатор пользователя из базы.
Еще бы добавил, что нужно стараться логин/пароль передавать по https.
А чтобы с одного IP вас не начали сканировать или досить или роботом кравлить ваш контент, то имеет смысл ограничить количество идентификаторов сессий, которые вы выдаете на один IP. Обычно роботы сессии не поддерживают, поэтому, если 100 раз в минуту обратились и ни разу не предъявили уже сгенерированный идентификатор сессии, то тут и подумаешь, генерить ли 101-ый.

[hostadmin]

А не подскажите, как ограничить кол-во сессий на один IP?

[MarcusAurelius]

Нужно где-то сделать счетчик, например в базе данных или memcached. Структура данных такая: таблица сессий (каждому выданному идентификатору сессии сопоставляется время выдачи и IP), можно ограничиться одной таблицей, а можно еще таблицу с IP адресами (счетчик выданных сессий и флаг, например, для организации блеклистов, можно еще время последнего обращения). Вопрос десяти-двадцати строчек кода, на самом деле.

[datacompboy]

Во-1х, md5 уже небезопасный. Из него можно получить как пароль (в случае простых паролей), так и просто сгенерировать строку, которая подойдёт под нужный md5 хеш.

Во-2х, безопасность хранения пароля в сессии не стоит просто потому, что ему там неоткуда взяться. Пароли сверяются с базой пользователей, в которой уже как раз пароли не должны храниться открытым текстом — именно поэтому это вообще не к месту.

В-3их, хранение любых данных в сессии относительно безопасно, если сессии хранятся только памяти и только на своём сервере, во всех остальных случаях следует учесть, что существуют способы «угадать» или пробраться к файлу сессии (особенно на shared хостингах неудачных) из другого проекта, и потому данным сессии доверять вообще не особо-то можно

В-4ых, Код вот этот:

if(!empty(array_search($_SERVER['REMOTE_ADDR'],$ip_white_list))) 
{
    header("Location: admin.php");
}
else 
{
    echo 'ACCESS DENY!';
}

решает какую-то несусветную фигню, чесслово. То есть если IP нормальный, то мы делаем redirect на другой файл.А что, тот файл не должен проверять? :) Если уж ограничиваем по IP, то так:

// in admin.php 
if(!in_array($_SERVER['REMOTE_ADDR'],$ip_white_list))
{
    die('ACCESS DENY!');
}

[freeeeez]

Вместо md5 можно использовать sha1, это не принципиально в этом примере. А в остальных случаях соглашусь с Вами.

[datacompboy]

sha256, и с солью. иначе rainbow tables по-прежнему рулят.

[freeeeez]

неплохо, но и sha1 до сих пор не взломан;)
да, про соль забыл написать, вот здесь написано про соль, но пример опять же с md5, если что.

[datacompboy]

www.schneier.com/blog/archives/2005/02/sha1_broken.html

[freeeeez]

извиняюсь, не знал. спасибо

[datacompboy]

Разница между заголовками и URL огромная:
1) При передаче в URL простой копипаст ссылки отдаёт SID
2) При передаче в URL в логах вебсервера, прокси, клиента, и различных трекерах текущего сайта SID светится
Поэтому да, передача только в куках лучше, чем передача в URL.

Не нужно взламывать сервер. Достаточно, например, иметь сайт на том же shared тазике, когда файлы сессий разных сайтов не изолированы друг от друга.
Зачастую файлы сайтов изолированы, а вот сессии нет.

[resurection]

Я бы сказал, что md5 там только что бы сократить длинную строку до 32 символов. Безопасность тут ни причём. Если злоумышленник уведёт SID из куков, то подделать USER-AGENT сможет без проблем. Тем более, что USER-AGENT — это не пароль и существует ограниченное кол-во различных вариантов. А если у жертвы стандартный браузер последней версии, то методом перебора можно угадать с 10 попыток.

[datacompboy]

Это в user-agent md5() для сокращения. А вот в пароле для недопущения утечки пароля из файла сессии.

[resurection]

Ну тогда зачем пароль хранить в том месте откуда его могут спереть? То что он зашифрован — не имеет значения. Если его могут украсть, то это уже плохо.
Неужели так сложно написать:
unset($user['password']);
прежде чем добавлять $user в $_SESSION? У меня unset вообще в модели выполняется, по этом никто кроме базы пароля никогда не знает.

[datacompboy]

Об этом я и говорил. Мне другое не нравится — использование md5($pass) уже давным-давно неэффективно (где-то с 2002 года), а его по-прежнему всюду пихают. Вот прямо как есть, даже без соли.
Люди начитываются и начинают так делать. За что потом платятся.

[mrMazai]

А если md5($ID + $USERAGENT + $SALT + [$IP]) — то подбор становится уже значительно сложнее.

[resurection]

А это уже стандартный алгоритм валидации сессий. Называется он «отпечатки пальцев» и описан в нормальных статьях про сессии. См. мой коммент ниже.

[KhanTengri]

Похоже, вы не знаете об этом: HttpOnly
(на wiki меньше букав)

[tzlom]

Если вы храните пароль сессии в переменной $_SESSION (все-таки лучше использовать sql)

угу, т.е. если вместо $_SESSION я буду использовать $session станет лучше?
Статья и так детская, так и пишите что есть различные варианты хранения сессий, часть реализована внутри РНР а остальные можно сделать самому — документация
так же как писали выше — пароль не нужен и к этому же — несолёный sha1 не лучше солёного md5
впрочем с бредом про «доверять сессии не особо можно» я не согласен — если можно пробиваться на чужие виртуалки это баг хостера, а не недочёт программиста не учевшего такой вариант

Ограничьте время жизни сессии

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

[resurection]

Статья для совсем новичков.
1. Фильтровать всех юзеров по IP — а причём тут сессии?
2. IP надо записывать в сессию и при повторном обращении проверять его так же как вы проверяете USER-AGENT. Это даст дополнительную степень надёжности если кто-то уведёт SID но будет находится в другой (под)сети.
3. Сверять USER-AGENT не очень надёжно, ведь если злоумышленник уведёт SID из куков, то user-agent подделает без проблем. Его даже красть не обязательно — можно перебором.
4. Конечно сравнение user-agent не будет лишним но так же стоит добавить, что иногда эта проверка косячит и мешает нормальной работе. Я, например, сталкивался с кривыми браузерами, которые слали рандомный user-agent в каждом запросе. Ещё флеш предыдущей версии может тупить при аплоаде файлов и посылать не тот заголовок, которые был до этого. В итоге на нескольких проектах мне пришлось выключать эту проверку.
5. Ну и конечно ничего не рассказано про «отпечатки пальцев».

В итоге, эта статья в подмётки не годится старой статье на пхп-клубе: phpclub.ru/detail/article/sessions

[MarcusAurelius]

Ну так есть раздел «Веб-разработка для начинающих», нужно ее туда и переместить: habrahabr.ru/blogs/webdev_for_dummies/

[MarcusAurelius]

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