Поэтому все говорят, что на сессиях есть риски для безопасности, я хочу знать, какие это риски? Что могут делать хакеры с сеансами?
Это не значит знать, как избежать атак, я хочу знать, как это делают хакеры, и что они делают.
Я говорю о PHP SESSIONS .
В основном здесь есть риски:
Подумайте о том, как использовать OWASP для этого.
Также посмотрите:
Руководство по безопасности PHP
Ответ 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 в каждой ссылке с домашней страницы или отправляет аналогично названный файл cookie на индексной странице.
Сеансы PHP используют идентификаторы сеанса, и haxxors могут использовать все возможные идентификаторы с небольшим изменением, которое они получили. Кроме того, эти идентификаторы хранятся в файлах cookie и могут быть перехвачены. Третья возможность заключается в том, что PHP может быть ошибкой и создавать два сеанса с одинаковым идентификатором. Кроме того, данные сеанса хранятся в файлах на диске, который не является защищенным. Вместо этого базам данных нужен пароль.
На самом деле невозможно предотвратить первые две причины, но третья и четвертая. Например, сохраните данные сеанса в базе данных.