Контрольный вопрос сеанса PHP

Я провел некоторое исследование StackOverflow о том, как правильно настроить сеансы и предотвратить захват и т. Д. Я нашел ответ, который кто-то опубликовал на один из вопросов, и он предоставил следующий код:

Когда пользователь входит в систему и имя пользователя и пароль совпадают

$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] .''. $_SERVER['REMOTE_ADDR']);

Проверка входа пользователя в систему для защищенных страниц:

if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] .''. $_SERVER['REMOTE_ADDR'])) {       
        session_destroy();
        header('Location: login.php');
        exit();     
    }

Вроде работает нормально, но у меня вопросы: насколько это безопасно, хороший ли это метод или стоит попробовать что-то другое? У поста не было голосов или чего-то еще, поэтому не уверен, что он хорош.

Также не уверен, как получить информацию о пользователе с этой сессией.. нужно ли что-то хранить в базе данных?

Благодарю вас!


php security session session-hijacking
person Drew    schedule 21.08.2011    source источник
comment
Использование IP-адреса имеет свои проблемы. Динамические IP-адреса могут часто меняться. Если вам нужны безопасные решения, я думаю, лучше использовать HTTPS.   -  person Karolis    schedule 21.08.2011

Ответы (3)


arrow_upward
3
arrow_downward

В этом коде есть две основные проблемы.

1) IP-адреса меняются по законным причинам. Если клиент находится за балансировщиком нагрузки, например, в корпоративной сети, он не сможет использовать ваше веб-приложение.

2) Проверка пользовательского агента очень похожа на переменную get, которая говорит ?is_hacker=false. Если у хакера есть идентификатор сеанса, у него есть пользовательский агент, и его подделка тривиальна.

Более того, я понятия не имею, почему вы хотите использовать md5 для этого, когда сравнение обычного текста на самом деле более безопасно. Поскольку пользовательский агент является первым, злоумышленник может использовать атаку с префиксом md5 для создания коллизии и тем самым обойти проверку REMOTE_ADDR. (Полезная атака столкновением md5 встречается не слишком часто, но эта забавная!)

Даже с этой проверкой CSRF и XSS все еще могут использоваться для влияния на сеанс. XSS можно использовать для чтения токена CSRF, а затем использовать XHR для выполнения любого запроса, который пожелает злоумышленник. Можно было бы возразить, что это попытка смягчить OWASP a9, но действительно вам нужно использовать SSL для защиты идентификатора сеанса.

person rook    schedule 21.08.2011
comment
Последнее не обязательно верно: идентификатор сеанса мог быть получен из URL-адреса, который жертва опубликовала где-то без идентификатора пользовательского агента. И CSRF-атаки не зависят от сессий, они также могут возникать при использовании других методов аутентификации. - person Gumbo; 21.08.2011
comment
@Gumbo♦ для одного он использует $_SESSION, поэтому где-то есть идентификатор сеанса. По умолчанию php использует cookie для идентификатора сеанса, но нет гарантии, что он использует значения по умолчанию. Кроме того, пользовательский агент также легче взломать, чем пароль. Если это хром, то это всегда будет последняя версия и т. Д. - person rook; 21.08.2011
comment
@Gumbo♦ Кстати, я разговаривал со службой поддержки крупной американской компании, и они распечатали для меня кое-какую информацию. Внизу страницы был URL-адрес, потому что он был напечатан из браузера, включая jsessionid. Расскажите о плохом дизайне приложения. - person rook; 21.08.2011
comment
Вы говорите, что «если у хакера есть идентификатор сеанса, у него есть пользовательский агент». И это неправильно. Потому что вы не можете вывести идентификатор пользовательского агента из идентификатора сеанса, что подразумевает ваше утверждение. - person Gumbo; 21.08.2011
comment
@Gumbo♦ Извините, но я по-прежнему придерживаюсь своего утверждения, оно ни хрена не делает для безопасности, если только у вашего приложения нет других более серьезных проблем. - person rook; 21.08.2011
comment
Я согласен с вашим утверждением, что многие не обрабатывают идентификатор сеанса так, как следует. Также верно и то, что некоторые атаки для получения действительного идентификатора сеанса также раскрывают идентификатор пользовательского агента. А так как IP-адрес действительно не подходит, так как может измениться во время сеанса, отпечаток пальца не предотвратит атаку (хотя и снизит вероятность). Но тем не менее, вычисление идентификатора пользовательского агента из идентификатора сеанса по-прежнему невозможно (по крайней мере, не с генератором идентификатора сеанса PHP по умолчанию). - person Gumbo; 22.08.2011

arrow_upward
0
arrow_downward

Это выглядит как хороший метод, однако хэш отпечатка генерируется данными клиента, которые можно подделать. Хорошим методом для формы входа является создание случайного токена, который сохраняется в сеансе и передается через форму. После того, как токен проверен (или нет), он должен быть отключен только для одноразового использования.

Сеанс также должен хранить идентификатор пользователя после того, как пользователь вошел в систему, чтобы получить информацию о пользователе, хранящуюся в базе данных.

person mgraphic    schedule 21.08.2011
comment
Вы говорите о распространенном методе защиты от CSRF. Вы сравниваете яблоки и апельсины. - person rook; 21.08.2011

arrow_upward
0
arrow_downward

Я согласен с комментариями Rook, это довольно хороший анализ вашего кода.

Есть много вещей, которые нужно учитывать для защиты сеансов PHP, но с актуальной версией PHP этого нетрудно достичь, некоторые вещи, о которых следует подумать: - Где файлы сеанса хранятся на вашем сервере (в основном проблема, если это общий сервер) - Использование безопасного соединения для всех конфиденциальных данных и файлов cookie, передаваемых между клиентом и сервером. Делайте все возможное, чтобы сделать идентификатор сеанса cookie на клиенте безопасным. Не храните конфиденциальные данные в переменной сеанса.

Что касается хранения вещей в базе данных, это зависит от ваших потребностей, но я бы сказал, что вам это, вероятно, не нужно, и хранение данных в переменной сеанса подходит для безопасности, просто (как я уже сказал) ничего не храните чувствительный там. Получить конфиденциальные данные из другого места, скорее всего, из базы данных.

Если вам нужно больше узнать о безопасности сеанса PHP, я у меня есть серия сообщений в блоге на эту тему.

person Neil Nand    schedule 14.01.2013