Форум PHP

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

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

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

А что лучше использовать для авторизации с хорошей посещаемостью, куки или сессии? Куки вроде как быстрей работают...

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

а если злоумышленник увидит id, то он же и сможет получит доступ?

Вообще говоря да, однако, SID сессии сейчас не передается через GET-параметры, а передается через cookie - увидеть и воспользоваться ими значительно труднее (хотя это тоже возможно).

а можно ли, взять еще случайное число закешировать его и проверять вместе с ID пользователем, которое будет создаваться при авторизации и заноситься в базу на время жизни сессии, а по истечении удаляться? Можно ли назначить время жизни сессии и как можно удалять это число?

Можно, только что это даст?

>Можно ли назначить время жизни сессии и как можно удалять это число?
Время жизни сессии и так ограничено параметром session.gc_maxlifetime в php.ini, лучше на него и ориентироваться. Если же вы хотите хранить данные сессии в базе данных, то лучше вообще переопределить механизм сессии при помощи функции session_set_save_handler() и все относящееся к сессии хранить в базе данных. Тогда вы получаете полный контроль над ней и возможность удалять все что вам захочется в нужный момент времени.

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


>все относящееся к сессии хранить в базе данных.
а что это все, что относится к сессии? Мы же и так все данные храним в базе

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

функция session_set_save_handler() сильно сложная получается...

будит ли безопасно, если мы хешировать будем пароль в md5 и проверять в течении работы пользователя в сессии его ip адрес на изменение? Вот и вся защита...или подвергаться будет взлому?

Да, будет довольно безопасно (насколько вообще можно добиться безопасности).

>или подвергаться будет взлому?
Подвергаться взлому система может по разным причинам. Если вы исключаете возможность XSS-инъекции, то и обычные сессии будут безопасны (так как для воровства cookie придется по сути устанавливать контроль над машиной клиента).

а функция mysql_real_escape_string исключит возможность XSS-инъекции?

при использовании сессии в кукисах хранится только SID?

Нет, XSS-инъекция - это вставка JavaScript-выражений для отправки данных на сторонний хост. Тут скорее приходится функция htmlspecialchars().

они вставляются в поля формы заполняемые пользователем?

если все поля, вводимые пользователем буду проверятся через функцию htmlspecialchars() можно исключить возможность XSS-инъекции?

Скорее не проверяться, а выводиться. Да, это значительно снизить вероятность XSS-инъекции, однако.

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

У вас текст исказится, его потом нельзя будет редактировать - будут артефакты от повторного использования htmlspecialchars(). Эту функцию лучше применять один раз и при выводе из базы данных.

а при занесении данных в базу применять mysql_real_escape_string?

Да.