Здравствуйте уважаемый посетитель!

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

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

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

Данная статья представляет собой вводную часть нового радела "Авторизация пользователей", в котором предполагается рассмотреть все основные вопросы, связанные с созданием на сайте полноценного механизма авторизации.

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

Здравствуйте уважаемый посетитель!

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

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

Но это не единственная мера по защите конфиденциальности сессий, которые мы будем использовать в нашей системе авторизации. В следующей статье мы рассмотрим и другие способы защиты сессий от хакерских атак. Такие, как проверка браузера пользователя по HTTP-заголовку user-agent, привязка по IP-адресу, а также использование временных меток сессий.

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

Здравствуйте уважаемый посетитель!

В предыдущей статье мы создали систему авторизации пользователей с применением определенных мер по защите конфиденциальности сессии. Где использовали следующие методы защиты:

1. запрет доступа через скриптовые языки (JavaScript) к cookies, хранящим идентификатор сессии и одноразовый ключ;
2. установку определенного времени жизни, как для сессии, так и для относящихся к ней cookies;
3. настройку PHP на работы только с сессиями из cookies;
4. использование одноразового ключа, предназначенного для дополнительной проверки подлинности пользователя;

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

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

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

1. проверку подлинности пользователя по HTTP-заголовку User-Agent;
2. привязку по IP-адресу.

Кроме того, рассмотрим также некоторые варианты дополнений к работе механизма удаления устаревших сессий. Так как стандартное решение по удалению сессий из хранилища, так называемым "сборщиком мусора", имеет определенные недостатки (рассматривалось в предыдущей статье). И посмотрим, как можно изменить его работу, используя для этого:

1. временные метки сессий через переменную $_SESSION;
2. отдельный скрипт, который проверяет время последней сборки мусора и удаляет сессии с истекшим сроком жизни.

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

Здравствуйте уважаемый посетитель!

Сегодня рассмотрим еще один из возможных методов защиты сессий от хакерских атак, основанный на привязке к IP-адресу.

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

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

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

Здравствуйте уважаемый посетитель!

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

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

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

Здравствуйте уважаемый посетитель!

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

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

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

Однако, для более полного раскрытия темы работы с PHP-сессиями, думаю, стоит рассмотреть и этот, нестандартный способ, который при определенных условиях может быть весьма полезен.

Здравствуйте уважаемый посетитель!

Сегодня коснемся еще одного вопроса, относящегося к безопасности сессий, а именно: обеспечим доступ к сессионной cookie с использованием защищенного протокола HTTPS.

Но перед тем как это сделать, выполним определенные мероприятия. Такие, как:

Необходимость перевода сайта на защищенный протокол HTTPS обусловлена тем, что это не только обеспечивает безопасный обмен данными, до минимума снижая риск подмены и кражи мошенниками введённых данных, но и повышает доверие к сайту благотворно влияя на ранжирование при поисковой выдаче. И в настоящее время протокол HTTPS стал основным режимом работы для подавляющего большинства интернет-ресурсов.

Здравствуйте уважаемый посетитель!

В завершении рассмотрения вопросов по созданию системы авторизации создадим личный кабинет, который в нашем случае будет содержать 3 раздела, такие как:

1. Мои заказы;
2. Профиль;
3. Добавить заказ.

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

Однако, основные моменты, которые будут рассмотрены в статье, вполне возможно использовать и в других подобных случаях. Особенно это касается взаимодействия с базой данных MySQL, так как ее использование необходимо для работы любого личного кабинета.

Поэтому в данной статье на примере "Мои заказы" мы посмотрим, каким образом пользователь личного кабинета может получить интересующую его информацию, причем доступную только для него. И как он может в предназначенные для него данные внести свои изменения.

По остальным двум разделам: "Профиль" и "Добавить заказ" подробного рассмотрения приводить здесь не будем, так как они сформированы аналогичным образом. Непосредственно с их кодом можно ознакомиться в исходных файлах сайта в файлах "profile.php" и "add-order.php", расположенных в папке "user" каталога "articles".