Правильный способ управления сессиями в PHP? - PullRequest
38 голосов
/ 08 июня 2009

Я сейчас настраиваю систему аутентификации. Мой текущий макет состоит в том, чтобы получить его электронную почту от $_POST, md5 его пароль, и проверить базу данных по его электронной почте и его паролю. Если оно совпадает, я использую session_start и начинаю хранить данные в переменной $_SESSION, например:

 $_SESSION['uid'] = $uid;
 $_SESSION['first_name'] = $first_name;

И на каждой странице сайта я бы предварительно проверил простую проверку

isset($_SESSION['uid']);

если нет, перенаправить на страницу индекса, если есть, загрузить страницу.

Я делаю это правильно? Это достаточно безопасно? Насколько легко кому-то подделать эти данные?

Кто-то сказал мне, что я должен создать таблицу с электронной почтой пользователя и его идентификатором сеанса и использовать его для управления вещами ... Я немного запутался - как это поможет?

Может ли кто-нибудь уточнить это? Как правильно управлять аутентификацией с помощью сеансов PHP?

Спасибо.

Ответы [ 4 ]

43 голосов
/ 08 июня 2009

Обновление безопасности : по состоянию на 2017-10-23: рекомендации в этом ответе, хотя и имеют историческое значение, совершенно небезопасны. Никогда не следует использовать md5 для хеширования пароля, потому что он так легко взломан. См. этот ответ о том, как использовать встроенный пароль_ * api для хеширования и проверки паролей.


Ранее я имел дело с системами входа в систему / аутентификации и обнаружил несколько недостатков в этом методе:

  • Вы «md5 его пароль, и проверьте базу данных» - это означает, что если человек имеет доступ к базе данных, он может разобрать, кто имеет те же пароли!

ADDENDUM (19 сентября 2015 г.) * Посмотрите на эту ссылку . Он объясняет все основы, подходы, которые вы можете использовать, почему вы должны использовать эти подходы, а также дает пример PHP-кода. Если читать слишком долго, просто зайдите в конец, возьмите код и получите!

ЛУЧШИЙ ПОДХОД : для хранения md5 из username+password+email+salt в базе данных, salt является случайным и хранится вместе с записью пользователя.

  • использование 'uid' непосредственно в переменных сеанса может быть очень рискованным. Подумайте об этом: мой друг вошел в систему из моего браузера, и он уходит на утечку. Я быстро проверяю, какие куки установлены в его браузере, и расшифровываю его 'uid'. Теперь я им владею!

BETTER APPROACH : генерировать случайный идентификатор сеанса при успешном входе пользователя в систему и сохранять этот идентификатор сеанса в массиве $_SESSION[]. Вам также нужно будет связать sessionid с его uid (используя базу данных или memcached). Преимущества:

  1. Вы даже можете привязать sessionid к определенному IP, чтобы сессионный не мог быть использован, даже если он захвачен
  2. Вы можете сделать недействительным старый идентификатор сессии, если пользователь входит в систему из другого места. Поэтому, если мой друг входит в систему со своего компьютера, идентификатор сеанса на моем компьютере автоматически становится недействительным.

РЕДАКТИРОВАТЬ: я всегда использовал куки вручную для моих вещей обработки сеанса. Это помогает мне легче интегрировать компоненты javascript моих веб-приложений. В будущем вам может понадобиться то же самое в ваших приложениях.

26 голосов
/ 08 июня 2009

В этом нет ничего плохого

isset($_SESSION['uid']);

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

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

То, что мы сейчас обсуждаем, это перехват сеанса , вы можете подумать, что вы можете просто сохранить IP-адрес в сеансе и проверить это с помощью IP-адреса, полученного из запроса, и покончить с ним. Однако зачастую это не так просто, я с этим сгорел совсем недавно, когда в большом веб-приложении мы хранили хэш пользовательского агента + IP-адрес в сеансе, а затем проверяли, совпадают ли они в каждом случае, для 99% пользователей. это работало нормально. Тем не менее, мы начали получать звонки от людей, которые обнаружили, что они постоянно выходили из системы без объяснения причин. Мы включили регистрацию проверок перехвата сеанса, чтобы увидеть, что происходит, и обнаружили, что эти люди будут заходить на один IP, а их сеанс будет продолжаться на другом, это не была попытка перехвата, однако это было связано с тем, как их прокси-сервер сработало, в результате мы изменили наш код перехвата сеанса, чтобы определить класс IP-адреса и оттуда выяснить сетевую часть IP-адреса и сохранить только те части IP-адреса, это немного менее безопасный в этом сеансе угон теоретически может происходить из одной и той же сети, но приводит к исчезновению всех наших ложных срабатываний.

4 голосов
/ 17 сентября 2013

Я должен добавить к этому. Если вы используете метод «MD5 пароль, а затем проверьте базу данных», это означает, что пароль хранится в одном хеше md5. Это больше не стандартный способ хранения хешированных паролей.

Я нашел эту ссылку очень информативной: http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard

0 голосов
/ 08 июня 2009

Я не на 100% в этом, но я думаю, что возможно подделать сессию, если кто-то действительно хотел!

Я думаю, что сохранение идентификатора сеанса в таблице является наиболее безопасным способом сделать это.

Я немного разбирался в этом недавно, но, опять же, я не уверен, интересно услышать, что лучше всего делать!

Вот несколько ресурсов для просмотра

http://www.sitepoint.com/article/php-security-blunders/

http://www.phpeasystep.com/workshopview.php?id=6

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...