Безопасность $_SESSION
- Автор темы GEN2009
- Дата начала
chisto_tolyan
Враг народа
такой вопрос уже задавали 100 раз...
Зачем хранить в сессии сам пароль?нельзя чтоли сделать флаг, мол авторизирован и проверять уже флаг?
Зачем хранить в сессии сам пароль?нельзя чтоли сделать флаг, мол авторизирован и проверять уже флаг?
AndreyKl
Новичок
Если сессии хранятся в файлах. Файлы сессий хранятся обычно в темповой директории на сервере. Это значит, что любой, кто имеет доступ на чтение к темповой директории на сервере ( а это обычно любой, кто имеет доступ серверу (я говорю о linux, freebsd, не знаю, как в виндовс, думаю, что так же)) может, посмотреть название файла. Обыччно права ставятся (и должны) так, что никто кроме владельца (веб-сервер или пхп-процесс) не может ни открыть файл в любом режиме, ни удалить его (исключение - root). Т.е. исключая дыры в системе, узанть содержимое файла невозможно.
Если сессии хранятся в бд, то это вопрос безопасности БД (но если БД плохо наствоена, то я думаю, никто не полезет смотреть сессии, а скорее полезут в более интересные места).
Подобрать идентификатор сессии так же на практике очень сложно (только если ты не можешь посмотреть название файла в темповой директории на сервере... или прослушать сеть(но в этом случае, проблеммы будут не в сессиях
)).
Я думаю - безопасно. Другой вопрос - если юзер был,например, "заморожен"(если система позволяет это делать), то без обращений к бд ты не сможешь сменить его статус и он будет ходить по сайту как ни в чём не бывало, пока не залогинится снова...
Если сессии хранятся в бд, то это вопрос безопасности БД (но если БД плохо наствоена, то я думаю, никто не полезет смотреть сессии, а скорее полезут в более интересные места).
Подобрать идентификатор сессии так же на практике очень сложно (только если ты не можешь посмотреть название файла в темповой директории на сервере... или прослушать сеть(но в этом случае, проблеммы будут не в сессиях
)).Я думаю - безопасно. Другой вопрос - если юзер был,например, "заморожен"(если система позволяет это делать), то без обращений к бд ты не сможешь сменить его статус и он будет ходить по сайту как ни в чём не бывало, пока не залогинится снова...
chisto_tolyan
Враг народа
Пароли надо хранить в базе а не в сессии, хотя это твое дело.
По поводу безопасности сессий писалось уже много раз:
Или соседи по дырявому хостингу tmp-файлы сессии прочитают
Или кто-то узнает идентификатор сессии и выдаст себя "за того, кого надо", кстати в этом случае полезно проверять пароль из БД а не из сессии.
Но это в теории, а вообще сессии штука безопасная =)
По поводу безопасности сессий писалось уже много раз:
Или соседи по дырявому хостингу tmp-файлы сессии прочитают
Или кто-то узнает идентификатор сессии и выдаст себя "за того, кого надо", кстати в этом случае полезно проверять пароль из БД а не из сессии.
Но это в теории, а вообще сессии штука безопасная =)
dr-sm
Новичок
всмысле пароль? ну так в базу новый хеш запишем и куку выставим новую если есть "ремембер ми". у меня хешь только при юзер лоджин проверяется.
или ты имеешь ввиду случай, когда пхп не на выделенном серваке стоит, те возможность извне записать в сессию юзерайди? тогда да, в качестве last resort, возможно поможет. но если есть доступ к сессиям, с учетом того, что пункт 2. мы уже применили, то как тогда быть с паролями доступа к базе?
-~{}~ 03.09.06 18:06:
сейчас подумал, и вспомнил гениальную фразу про то, что "Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев" (С) не помню кто.
Можно ограничить доступ пользователю базы каким-нибудь интерфейсом типа:
sp_login_user(login, hash)
sp_get_user_info(uid, hash)
sp_get_ch_pwd(uid, hash, new_pass)
sp_add_user(...)
и тп. а самих таблиц видно ему не будет.
вобщем, полностью согласен с твоим решением. все получается относительно секьюрно, даже если пхп доступ хакнут.
PLUR
или ты имеешь ввиду случай, когда пхп не на выделенном серваке стоит, те возможность извне записать в сессию юзерайди? тогда да, в качестве last resort, возможно поможет. но если есть доступ к сессиям, с учетом того, что пункт 2. мы уже применили, то как тогда быть с паролями доступа к базе?
-~{}~ 03.09.06 18:06:
сейчас подумал, и вспомнил гениальную фразу про то, что "Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев" (С) не помню кто.Можно ограничить доступ пользователю базы каким-нибудь интерфейсом типа:
sp_login_user(login, hash)
sp_get_user_info(uid, hash)
sp_get_ch_pwd(uid, hash, new_pass)
sp_add_user(...)
и тп. а самих таблиц видно ему не будет.
вобщем, полностью согласен с твоим решением. все получается относительно секьюрно, даже если пхп доступ хакнут.
PLUR