Таким образом, все говорят, что на сеансах есть риски для безопасности, я хочу знать, какие это риски? Что могут делать хакеры с сеансами?
Это не о том, как избежать атак, я хочу знать, как это делают хакеры, и что они делают.
Я говорю о PHP SESSIONS.
В основном это риски:
Рассмотрите возможность использования OWASP.
Также посмотрите:
Ответ sAc очень хороший. Однако из-за этого не исключайте "сеансы".
Я успешно развернул пользовательские сеансы, которые, в частности, устраняют угон, отмену пароля (md5/rainbow) и (если используются правильно) фиксацию сеанса.
Под "успешно развернутым" я подразумеваю прохождение тестирования на проникновение и (конечно) на самом деле лучше, чем традиционный.
Нет "секретной" или неясной безопасности; в основном, он генерирует случайный (и уникальный по базе данных) номер (фактически, ориентир в моем случае) на учетную запись пользователя и сохраняет имя guid + как обычный метод (вместо имени пользователя + хэшированный/соленый пароль). Затем он связывает этот указатель с IP-адресом пользователя. Не безошибочно, но использование guid и per-ip уже является улучшением по сравнению с текущей системой сеансов. Конечно, есть недостатки, которые открываются после определенного таргетинга (например, ip spoofing + hijacked guid и имя пользователя). Но в целом, это лучший вариант.
Вот хорошее обсуждение по теме: http://phpsec.org/projects/guide/4.html
Самый большой риск заключается в том, что IP-адреса не связаны с сеансом, а идентификаторы сеансов принимаются без проверки того, что они исходят от IP-адреса, который их запускал (или, по крайней мере, IP-адрес в той же подсети). Это позволяет кому-то отправить ссылку на уже запущенный сеанс, где может возникнуть необходимость войти в невольный обман. После этого SESSION считается зарегистрированным - и хакер, который отправил ссылку (у кого уже есть идентификатор сеанса ) имеет доступ к нашему счету rube. Или это может произойти наоборот, когда пользователь уже вошел в систему и не имеет файлов cookie, поэтому значение PHPSESSID сохраняется в каждой ссылке. Если пользователь вставляет ссылку кому-то, они также эффективно вставляют свой доступ к сайту.
Чтобы предотвратить это, достойный сайт избежит запуска сеанса, чтобы там что-то хранить в нем, и отслеживать, на какой IP-адрес был предназначен сеанс. И чтобы использовать его, злоумышленник будет искать сайт, который отправляет значение строки запроса PHPSESSID в каждой ссылке с домашней страницы или отправляет аналогичную куки файл на индексной странице.
Сессии PHP используют идентификаторы сеанса, и haxxors могут использовать все возможные идентификаторы с небольшим изменением, которое они получили. Кроме того, эти идентификаторы хранятся в файлах cookie и могут быть перехвачены. Третья возможность заключается в том, что PHP может быть ошибкой и создавать два сеанса с одинаковым идентификатором. Кроме того, данные сеанса хранятся в файлах на диске, который не является защищенным. Вместо этого базам данных нужен пароль.
На самом деле невозможно предотвратить первые две причины, но могут быть и третьи и четвертые. Например, сохраните данные сеанса в базе данных.