Подводя итоги обсуждения отсюда — вещи, на которые следует обращать внимание при использовании сессий для системы входа на ваши сайты;
1. Общие веб-серверы — любой другой пользователь на сервере может читать ваши файлы сеансов (обычно в каталоге / tmp), если PHP работает как модуль Apache (поэтому файлы сеансов принадлежат веб-пользователю) и, возможно, когда PHP используется как CGI (в зависимости от того, как сеансы реализованы).
Кто-то, просматривающий файлы сеанса (вероятно), не будет знать сайт, к которому относится сервер, к которому применяются сеансы (поэтому он не сможет использовать найденную комбинацию имени пользователя и пароля), но вы все равно можете поместить конфиденциальную информацию (например, данные кредитной карты) где-нибудь на всеобщее обозрение. Кроме того, у них есть список действительных идентификаторов сеансов …
Если вы просто храните пароли в сеансе, вы можете избежать этого, используя md5 () (предпочтительно дважды) для одностороннего шифрования пароля. Это не поможет, хотя, если вам нужно восстановить значение переменной сеанса.
Использование собственного обработчика сеансов для хранения сеансов в базе данных, вероятно, является лучшим решением. Вы можете рассмотреть MySQL HEAP таблицы, если производительность является проблемой (предполагается, что MySQL работает на той же машине, что и Apache). Если он получает очень высокий трафик, самое время подумать о том, чтобы получить свой собственный сервер …
2. Эксплойты XSS (и перехват сеансов) — с помощью JavaScript пользователи могут обмануть себя, выдавая свои активные session_id.
Все, кому нужно «перехватить» сеанс, это уникальный идентификатор сеанса. Это как ключ к шкафчику на вокзале. Шкафчик не проверяет, являетесь ли вы действительным владельцем ключа, прежде чем разрешить вам открыть его, чтобы любой, у кого есть ключ, мог войти.
Исследование XSS и как его предотвратить.
Примите тот факт, что перехват сеанса не может быть полностью предотвращен (например, AOL проверяет проверку IP-адреса, который назначает новый IP-адрес клиента при более или менее каждом запросе страницы), поэтому дважды проверяйте «критические действия», которые пользователь может выполнять при входе в систему. например, при смене пароля — требуется старый пароль, который (надеюсь) не будет известен угонщику сеанса. Отображение информации о кредитной карте — делайте как Amazon и отображайте только последние четыре цифры. В основном ограничьте ущерб, который кто-то может нанести, если он захватывает сеанс.
3. Идентификаторы сеанса в URL (и перехват) — если вы используете идентификаторы сеанса в URL (в отличие от файла cookie сеанса), убедитесь, что внешние ссылки не содержат идентификатор сеанса (иначе удаленный сайт сможет перехватить) ) — PHP должен позаботиться об этом. Кроме того, ваши посетители могут выдавать идентификатор сеанса в поле реферера — в идеале, для облегчения реферера передавать ссылки на сайт через страницу перенаправления (хотя, к сожалению, некоторые браузеры сохраняют последние 3 просмотренные страницы, как мне кажется, неуверенными в фактах).
В идеале, не передавайте идентификаторы сессии в URL-адресе — требуйте, чтобы пользователи приняли cookie-файл, если им нужно «войти».
4. Фиксация сессии (предварительный захват) (см. Http://www.acros.si/papers/session_fixation.pdf ).
Если вы назначаете сеанс посетителю вашего сайта, прежде чем он войдет в систему (например, для анализа пути клика ), убедитесь, что вы назначаете им новый идентификатор сеанса при входе в систему, чтобы, если кто-то предварительно сгенерировал начальный сеанс идентификатор для них, они не получат новый идентификатор.
Для PHP 4.2.0+ см. Session_regenerate_id () (в частности, комментарии, отправленные пользователем). Для PHP <4.2.0 вам придется уничтожить сеанс и заново создать его, когда пользователь войдет в систему, перенеся любые сохраненные данные между ними. Функция session_id () также может быть полезна (я не изучал ее в этом контексте).
5. Sniffing Packets (используйте SSL [HTTPS]) — идентификатор сеанса может быть «прослушан» между клиентом и вашим сервером. Если это сайт, где деньги переходят из рук в руки или используется другая конфиденциальная личная информация, SSL является обязательным требованием.
В противном случае, без SSL вам придется мириться с риском (так же, как вы делаете это каждый раз, когда используете FTP-клиент…).
6. Куки-файлы не предназначены для данных сеанса — на заметку, не используйте куки-файлы для хранения конфиденциальной информации.
Данные cookie, в отличие от сеансов, хранятся на сайте клиента. Помимо «риска перехвата», подавляющее большинство пользователей Windows мало знают о безопасности и могут «принадлежать haxor».
В противном случае файлы cookie (кроме файлов cookie сеанса, которые создает для вас PHP), как правило, предназначены для долговременного (т.е. между посещениями) сохранения данных (например, «Запомнить меня»), а не «активного сеанса».
Есть, вероятно, больше вещей, которые нужно остерегаться (или факты, чтобы исправить) — предложения приветствуются.