Каковы риски сессий PHP? - PullRequest
30 голосов
/ 11 июля 2010

Итак, все говорят, что у сеансов есть риски безопасности, я хочу знать, что это за риски? Что хакеры могут делать с сессиями?

Речь идет не о том, как избежать атак, я хочу знать, как хакеры это делают и что они делают.

Я говорю о PHP SESSIONS.

Ответы [ 5 ]

18 голосов
/ 11 июля 2010

В основном это риски:

Рассмотримиспользуя OWASP , чтобы сделать против него.

Также взгляните на:

Руководство по безопасности PHP

4 голосов
/ 11 июля 2010

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

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

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

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

2 голосов
/ 11 июля 2010

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

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

2 голосов
/ 11 июля 2010

Вот хорошая дискуссия на эту тему: http://phpsec.org/projects/guide/4.html

0 голосов
/ 11 июля 2010

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

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

...