Каковы риски сессий PHP?

Ответ sAc очень хороший. Однако не исключайте «сессий» из-за этого.

Я успешно развернул пользовательские сеансы, которые, среди прочего, исправляют захват, смену пароля (md5/rainbow) и (при правильном использовании) фиксацию сеанса.

Под «успешно развернутым» я подразумеваю прохождение тестирования на проникновение и (конечно) на самом деле лучше, чем традиционное.

Нет никакой «секретной» или неясной безопасности; по сути, он генерирует случайный (и уникальный по базе данных) номер (на самом деле, guid в моем случае) для учетной записи пользователя и сохраняет guid + username как обычный метод (вместо username + hashed / salted password). Затем он связывает этот идентификатор GUID с IP-адресом пользователя. Не является непогрешимым,но использование идентификатора GUID и per-ip уже является улучшением по сравнению с текущей системой сеансов. Конечно, есть недостатки, которые открываются после конкретного таргетинга (например, ip-спуфинг + захваченный guid и имя пользователя). Но в целом, это лучшая альтернатива.

Вот хорошее обсуждение темы: http://phpsec.org/projects/guide/4.html

Самый большой риск возникает, если IP-адреса не связаны с сеансом, а идентификаторы сеанса принимаются без проверки, что они поступают с IP-адреса, с которого они были запущены (или, по крайней мере, с IP-адреса в той же подсети) . Это позволяет кому-то отправить ссылку на уже начатый сеанс, где невольному обманщику может потребоваться войти в систему. После этого СЕССИЯ считается зарегистрированной, а хакер, отправивший ссылку (у которого уже есть идентификатор сеанса ) имеет доступ к аккаунту нашего rube. Или может произойти наоборот, когда пользователь уже вошел в систему и не имеет файлов cookie, поэтому значение PHPSESSID сохраняется в каждой ссылке. Если пользователь вставляет ссылку на кого-то, он также эффективно вставляет свой доступ к сайту.

Чтобы предотвратить это, приличный сайт будет избегать запуска сеанса до тех пор, пока в нем не будет что-то хранить, и будет отслеживать, для какого IP-адреса был предназначен сеанс.И чтобы воспользоваться им, злоумышленник будет искать сайт, который отправляет значение строки запроса PHPSESSID в каждой ссылке с домашней страницы или отправляет файл cookie с аналогичным именем на страницу индекса.

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

На самом деле невозможно предотвратить первые две причины, но третью и четвертую можно. Например, хранить данные сеанса в базе данных.