Вход в личный кабинет Что делать дальше?
И вот мы подбираемся к самому интересному: а где хранить пароли и в каком виде? Давайте сначала подумаем, где их хранить.
Что такое сессии?
Попробую рассказать в паре абзацев.
Сессии – это механизм, который позволяет однозначно идентифицировать пользователя.
По-человечески это значит, что для каждого посетителя сайта можно создать уникальное “хранилище”, к которому будет доступ только у этого самого посетителя.
Хранилище это хранится в файле на сервере.
На самом деле сессии хранятся не обязательно в файлах. Например, cms Modx хранит их базе данных.
Но сейчас нам это не важно, главное, что сессии предоставляют удобный способ работать с данными, уникальными для пользователя.
Для нас сессия выглядит как обычный ассоциативный массив под названием $_SESSION, в разные поля которого можно записать хоть число, хоть строку, хоть сериализованный объект.
Что такое хеширование
Отпечаток (хэш) — это результат работы функции хэширования, которая вернёт для любого значения строку фиксированной длины.Используя специальный математический алгоритм, такая функция умеет преобразовывать любую переданную информацию к строке фиксированной длины (например, 32 или 64 символа).
Причём любому массиву информации, будь это все статьи из Википедии, или одно слово, всегда будет соответствовать уникальный отпечаток. Повторный вызов функции для одного и того же исходника всегда возвращает один и тот же хэш.Обратная операция (получить из отпечатка оригинал) невозможна.
Возьмём простой пример. У нас есть информация, для которой мы хотим получить отпечаток. Пусть такой информацией будет следующая строка:
«Я знаю только то, что ничего не знаю, но другие не знают и этого»
Результат обработки этой строки хэширующей функцией SHA-1 будет таким:6b3cb0df50fe814dee886b4e1c747dda6ce88b37
Хэширующие функции часто используются для контроля целостности информации при передачи по сети. Например, чтобы убедиться в том, что загруженный файл не был повреждён, достаточно получить его хэш и сравнить данный хэш с опубликованным на сайте. Если в файле поменялся хоть один байт, то эти отпечатки будут совершенно разными.Нам же функции хэширования помогут для сравнения паролей.
Cookies
Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру.Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя, идентифицировать его.
Автоматическая авторизация
Допустим, вы хотите парсить страницы,
доступные только авторизованному пользователю.
В этом случае алгоритм действий такой: первый запрос
отправляется на страницу авторизации сразу с POST данными,
при этом автоматически сессионные куки пишутся в файл,
а все остальные запросы отправляются на страницы, которые вы хотите парсить.
При этом на форму авторизацию шлется только первый запрос,
а потом можно спокойно парсить нужные страницы, отправляя
и получая при этом куки – так вы будете поддерживать сессию.
Учтите только, что сессия живет около 20 минут, если не обращаться к сайту.
То есть, если после последнего обращения к сайту пройдет больше времени,
то нужно авторизовываться заново.
Автоматическая запись и получение кук
Уже имеющиеся куки, это хорошо, но бывает очень редко.
Чаще всего нам нужно автоматически принимать и отправлять куки.
Это делается с помощью двух опций: CURLOPT_COOKIEFILE
командует принимать и сохранять куки в файл,
а CURLOPT_COOKIEJAR командует отправлять сохраненные куки на сервер:
Параметром эти опции принимают путь к файлу в который будут писаться куки.
Учтите нюанс: автоматическая отправка куки CURLOPT_COOKIEJAR работает
только при включенной опции CURLOPT_COOKIEFILE.
Аутентификация
Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов.Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.
Процедура проверки возможности доступа пользователя к определенной части сайта и называется аутентификацией.Весь процесс аутентификации всегда состоит из нескольких шагов:
Безопасный метод авторизации на php
Давайте посмотрим вокруг: форумы, интернет магазины, гостевые книги и т.д. используют регистрацию и последующую авторизацию пользователей. Можно даже сказать, что это почти необходимая функция каждого сайта (только если это не домашняя страничка Васи Пупкина или не визитная карточка, какой-нибудь небольшой компании). Сегодня я хочу поделиться со всеми новичками информацией, о том, как лучше это все реализовать.
1. Модель (клиент)
Регистрация
— логин (a-z0-9)
— пароль
Вход
— логин
— пароль
Cookie
— уникальный идентификатор юзера
— хэш
Модель (сервер)
MySQL
Таблица users
user_id (int(11))
user_login (Varchar(30))
user_password (varchar(32))
user_hash (varchar(32))
user_ip (int(10)) по умолчанию 0
При регистрации в базу данных записываеться логин пользователя и пароль(в двойном md5 шифровании)
При авторизация, сравниваеться логин и пароль, если они верны, то генерируеться случайная строка, которая хешируеться и добавляеться в БД в строку user_hash. Также записываеться IP адрес пользователя(но это у нас будет опциональным, так как кто-то сидит через Proxy, а у кого-то IP динамический… тут уже пользователь сам будет выбирать безопасность или удобство). В куки пользователя мы записываем его уникальный индетификатор и сгенерированный hash.
Почему надо хранить в куках хеш случайно сгенерированной строки, а не хеш пароля?
1. Из-за невнимательности программиста, во всей системе могут быть дырки, воспользовавшийсь этими дырками, злоумышленик может вытащить хеш пароля из БД и подставить его в свои куки, тем самым получить доступ к закрытым данным. В нашем же случае, двойной хеш пароля не чем не сможет помочь хакеру, так как расшифровать он его не сможет(теоретически это возможно, но на это он потратит не один месяц, а может быть и год) а воспользоваться этим хешем ему негде, ведь у нас при авторизации свой уникальный хеш прикрепленный к IP пользователя.
2. Если злоумышленик вытащит трояном у пользователя уникальный хеш, воспользовать им он также не сможет(разве если только, пользователь решил принебречь своей безопастностью и выключил привязку к IP при авторизации).
2. Практика-- <br>
-- Структура таблицы `users` <br>
-- <br>
CREATE TABLE `users` ( <br>
`user_id` int(11) unsigned NOT NULL auto_increment, <br>
`user_login` varchar(30) NOT NULL, <br>
`user_password` varchar(32) NOT NULL, <br>
`user_hash` varchar(32) NOT NULL, <br>
`user_ip` int(10) unsigned NOT NULL default '0', <br>
PRIMARY KEY (`user_id`) <br>
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1 ; <br>
register.php
<?
// Страница регситрации нового пользователя
# Соединямся с БД
mysql_connect(“localhost”, “myhost”, “myhost”);
mysql_select_db(“testtable”);
if(isset($_POST[‘submit’]))
{
$err = array();
# проверям логин
if(!preg_match(“/^[a-zA-Z0-9] $/”,$_POST[‘login’]))
{
$err[] = “Логин может состоять только из букв английского алфавита и цифр”;
}
if(strlen($_POST[‘login’]) < 3 or strlen($_POST[‘login’]) > 30)
{
$err[] = “Логин должен быть не меньше 3-х символов и не больше 30”;
}
# проверяем, не сущестует ли пользователя с таким именем
$query = mysql_query(“SELECT COUNT(user_id) FROM users WHERE user_login='”.mysql_real_escape_string($_POST[‘login’]).“‘”);
if(mysql_result($query, 0) > 0)
{
$err[] = “Пользователь с таким логином уже существует в базе данных”;
}
# Если нет ошибок, то добавляем в БД нового пользователя
if(count($err) == 0)
{
$login = $_POST[‘login’];
# Убераем лишние пробелы и делаем двойное шифрование
$password = md5(md5(trim($_POST[‘password’])));
mysql_query(“INSERT INTO users SET user_login='”.$login.“‘, user_password='”.$password.“‘”);
header(“Location: login.php”); exit();
}
else
{
print “<b>При регистрации произошли следующие ошибки:</b><br>”;
foreach($err AS $error)
{
print $error.“<br>”;
}
}
}
?>
<form method=”POST”>
Логин <input name=”login” type=”text”><br>
Пароль <input name=”password” type=”password”><br>
<input name=”submit” type=”submit” value=”Зарегистрироваться”>
</form>
login.php
<?
// Страница авторизации
# Функция для генерации случайной строки
function generateCode($length=6) {
$chars = “abcdefghijklmnopqrstuvwxyzABCDEFGHI JKLMNOPRQSTUVWXYZ0123456789”;
$code = “”;
$clen = strlen($chars) – 1;
while (strlen($code) < $length) {
$code .= $chars[mt_rand(0,$clen)];
}
return $code;
}
# Соединямся с БД
mysql_connect(“localhost”, “myhost”, “myhost”);
mysql_select_db(“testtable”);
if(isset($_POST[‘submit’]))
{
# Вытаскиваем из БД запись, у которой логин равняеться введенному
$query = mysql_query(“SELECT user_id, user_password FROM users WHERE user_login='”.mysql_real_escape_string($_POST[‘login’]).“‘ LIMIT 1”);
$data = mysql_fetch_assoc($query);
# Соавниваем пароли
if($data[‘user_password’] === md5(md5($_POST[‘password’])))
{
# Генерируем случайное число и шифруем его
$hash = md5(generateCode(10));
if(!@$_POST[‘not_attach_ip’])
{
# Если пользователя выбрал привязку к IP
# Переводим IP в строку
$insip = “, user_ip=INET_ATON(‘”.$_SERVER[‘REMOTE_ADDR’].“‘)”;
}
# Записываем в БД новый хеш авторизации и IP
mysql_query(“UPDATE users SET user_hash='”.$hash.“‘ “.$insip.” WHERE user_id='”.$data[‘user_id’].“‘”);
# Ставим куки
setcookie(“id”, $data[‘user_id’], time() 60*60*24*30);
setcookie(“hash”, $hash, time() 60*60*24*30);
# Переадресовываем браузер на страницу проверки нашего скрипта
header(“Location: check.php”); exit();
}
else
{
print “Вы ввели неправильный логин/пароль”;
}
}
?>
<form method=”POST”>
Логин <input name=”login” type=”text”><br>
Пароль <input name=”password” type=”password”><br>
Не прикреплять к IP(не безопасно) <input type=”checkbox” name=”not_attach_ip”><br>
<input name=”submit” type=”submit” value=”Войти”>
</form>
check.php
<?
// Скрипт проверки
# Соединямся с БД
mysql_connect(“localhost”, “myhost”, “myhost”);
mysql_select_db(“testtable”);
if (isset($_COOKIE[‘id’]) and isset($_COOKIE[‘hash’]))
{
$query = mysql_query(“SELECT *,INET_NTOA(user_ip) FROM users WHERE user_id = ‘”.intval($_COOKIE[‘id’]).“‘ LIMIT 1”);
$userdata = mysql_fetch_assoc($query);
if(($userdata[‘user_hash’] !== $_COOKIE[‘hash’]) or ($userdata[‘user_id’] !== $_COOKIE[‘id’])<br> or (($userdata[‘user_ip’] !== $_SERVER[‘REMOTE_ADDR’]) and ($userdata[‘user_ip’] !== “0”)))
{
setcookie(“id”, “”, time() – 3600*24*30*12, “/”);
setcookie(“hash”, “”, time() – 3600*24*30*12, “/”);
print “Хм, что-то не получилось”;
}
else
{
print “Привет, “.$userdata[‘user_login’].“. Всё работает!”;
}
}
else
{
print “Включите куки”;
}
?>
Для защиты формы логина от перебора, можно использовать <a href=«captcha.ru target=»_blank”>капчу.
Хочу отметить, что здесь я рассматривал авторизацию основоную на cookies, не стоит в комментариях кричать, что сессии лучше/удобнее и т.д. Спасибо.
Всё хорошо?
Почти. Данная система по-прежнему не защищает от кражи хэша из кук при открытом канале и отсутствии SSL. Кроме того, сложно обеспечить своевременную блокировку, если доступ к аккаунту утерян (особенно если взломщик уже сменил пароль). В этом случае очень помог бы сброс пароля через смс-команду с привязанного телефона — но для этого уже нужна возможность принимать и отправлять смс.
А если она есть — то можно сразу внедрить двухфакторную авторизацию, которая снимет массу проблем. Но не проблему с необходимостью в SSL — поскольку всё равно результатом любой авторизации является получение некого токена доступа, работающего ограниченное время. И этого времени может быть достаточно, чтобы сделать от нашего имени что-то, что нам не понравится.
Выбираем правильное хэширование
Идею хранения паролей нашли, то есть хранения не паролей, а их хэшей. А вот какой алгоритм хэширования выбрать?
Давайте посмотрим на то, что пробовали выше – простая функция md5. Алгоритма его расшифровки нет, но тем не менее md5 не рекомендуется для использования. Почему?
Помимо сложности самого алгоритма, есть и другой момент. Да, расшифровать пароль по хэшу нельзя, но его можно подобрать. Простым брутфорсом.
К тому же существуют многочисленные базы паролей md5, где всевозможные варианты хранятся тупо списком.
И подбор вашего пароля по известному хэшу займет столько времени, сколько понадобится для выполнения sql-запроса
select password from passwords where hash='e10adc3949ba59abbe56e057f20f883e';
Конечно, вы сами не будете использовать пароль 123456, но как насчет ваших пользователей? Да, 123456 можно подобрать и руками, но в таком случае никакие алгоритмы не помогут.
Наша же задача максимально позаботиться о юзерах, которые выбирают пароли сложнее qwerty. Думаем дальше, гуглим.
Помимо md5 есть множество алгоритмов хэширования, sha256, sha512 и еще целая толпа. Их сложность выше, но это не отменяет опять-таки существования таблиц с готовыми паролями.
Нужно что-то хитрее.
Выход с сайта
Если на сайте есть вход, то должен быть и выход. Таким выходом будет специальный сценарий, который очистит сессию и переадресует на главную страницу.Чтобы очистить сессию, достаточно очистить массив $_SESSION:$_SESSION = []
Делегирование полномочий
Давайте попробуем создать отдельный модуль. Назовём его совершенно бесхитростно — security.php, и оформим как отдельный скрипт. Будем подключать его ко всем закрытым страницам нашего проекта в самом начале. Внутри этого файла будем анализировать некие условия, а по итогам его работы выставлять специальный флаг в 0 или 1. Пусть этот флаг будет храниться в переменных сессии (массив $_SESSION в PHP).
Что нам это даёт? Мы можем запихать в этот скрипт сколь угодно хитрую логику, вплоть до анализа последних действий пользователя и добавления его в бан-лист по IP, либо блокировки его аккаунта на тот или иной срок. Но сперва реализуем очень базовую функциональность: будем сверять значение хэша, пришедшего из куки, с тем, что должно было бы получиться, если хэш не был искажён. Сервер знает IP, знает юзер-агент, знает пароль текущего пользователя… Кажется, всё готово!
Ещё немного терминологии
Следует различать два термина: аутентификация и авторизация.
Заглушка для авторизации
Функции, связанные с авторизацией, будут лежать в отдельном файле и своем пространстве имен. Создадим файл auth.php в api/v1/common – там, где уже лежит helpers.php.
Если вы разбирали уроки админки, особенно третий, про серверную часть, то эти пути вам будут знакомы. Если у вас свой проект, то кладите auth.php куда удобно.
Главное, потом правильно указать пути.
Содержимое auth.php
Как быть?
Очевидно, с этим надо что-то делать. Да, можно сразу бежать покупать сертификат и подключать SSL. Но можно сделать кое-что ещё до этого, и существенно снизить тем самым необходимость в нём. В конце концов, в том же ВКонтакте SSL стал принудительным всего полгода назад, а до этого как-то ведь жили.
Первое, что приходит на ум — хранить вместо пароля хэш от него. Это не особо поможет, если кто-то перехватит трафик, и не поможет при краже кук. Но вот в ситуации «кто-то открыл настройки и прошёлся по кукам, пытаясь запомнить значения» — сильно усложнит жизнь злоумышленнику.
Можно пойти дальше, и при создании хэша использовать юзер-агент. Теперь взломщику придётся использовать браузер той же версии, что и у нас (а в случае с IE ещё и с тем же набором плагинов тех же самых версий, что выходит уж очень маловероятно, особенно если взломщик не догадался подсмотреть юзер-агент).
Как прочитать куки
В PHP максимально упрощён процесс чтения информации из кукисов. Все переданные сервером куки становятся автоматически доступны в специальном глобальном массиве $_COOKIEТак, чтобы получить содержимое куки с именем «visit_count», достаточно обратиться к одноимённому элементу массива $_COOKIE, например вот так:
Обратите внимание: установив в сценарии куку через setcookie, прочитать её можно будет только при следующем посещении страницы.
Как установить куки: функция setcookie
Являясь серверным языком программирования, PHP может управлять заголовками, которые отправляет сервер, а значит может устанавливать и читать куки.Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:
- Название этой куки (может состоять только из символов латинского алфавита и цифр);
- Значение, которое предполагается хранить;
- Срок жизни куки — это обязательное условие.
За установку куки в PHP отвечает функция setcookie, ей нужно передать как минимум три параметра, описанных выше. Пример:
Обратите внимание, что срок жизни указывается в относительной величине. В этом примере кука будет существовать ровно 30 дней с момента установки.
Как устроены сессии
- PHP генерирует уникальный идентификатор браузера.
- Идентификатор сохраняется в специальную куку и передаётся с каждым запросом.
- Все данные, которые записываются в сессию, PHP автоматически сохраняет в специальном файле на сервере.
Благодаря существованию сессий в PHP, мы можем сохранять любые данные так же просто, как присваивать их переменным. Но, в отличие от переменных, эти данные будут сохраняться для пользователя между запросами в пределах сеанса.
Перепишем сценарий для подсчета посещений, но теперь используем сессии:
Отправка куки на сервер
Предположим у вас уже есть название куки и ее значение.
В этом случае ее можно отправить на сервер с помощью
опции CURLOPT_COOKIE.
Давайте установим куку с именем name и значением ‘Дима’:
Предыстория
Осень 2022-ого. Примерно полтора года назад, когда мне случилось стать участником разработки проекта, где пользователей существенно больше пары десятков человек, я наконец-то впервые в своей жизни задумался о надёжности авторизации.
По сути, авторизация — это то, с чего начинается процесс взаимодействия зарегистрированного пользователя с системой (для незарегистрированного пользователя всё начинается с регистрации, и эти два процесса, как вы уже догадались, очень сильно взаимосвязаны). Я внезапно осознал, что во всех проектах, что я делал до этого, с безопасностью всё очень плохо.
Пример
Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.
Проверяем работоспособность vue
Вроде бы, чего там может сломаться? Нам же практически не пришлось лезть в код vue, за исключением добавления кнопки Выйти в шапке админки.
Но попробуем пересобрать админку, чтобы убедиться, что все хорошо. Сначала в production режиме
npm run build
Работа с сессией
Зачем нам нужно уметь работать с сессиями через CURL?
Затем, что авторизация на сайтах реализуется с помощью сессий.
Соответственно, умея работать с сессиями, можно реализовать автоматическую
авторизацию и парсить контент, доступный только авторизованному пользователю.
Сессии в PHP работают на основе кук. При старте
сессии в куку пишется переменная sessionid,
которая будет иметь что-то вроде такого значения 27za9c2lel3tk4zhhm7lmtzt6bbm3atj.
Поэтому, для работы сессий всего лишь необходимо получать
и отправлять куки на сайт, что мы и разобрали чуть выше.
Реализация регистрации пользователя
Вернёмся к форме регистрации.Выше говорилось, что вместо пароля лучше хранить его отпечаток. Для получения отпечатка существуют множество хэшируюших функций. К счастью, нам не надо разбираться в их многообразии, потому что в PHP есть стандартная функция, которая делает ровно то, что нужно.Вот пример как из пароля получить отпечаток, пригодный для хранения в базе:
$passwordHash = password_hash('iloveponies', PASSWORD_DEFAULT);Вызов этой функции вернёт следующую строку: $2y$10$a1pgDBerBsqD24D7qOAsl.QFTvwxQQGe4r1oWhD7f9yEnDvx4i7tWИменно это значение и следует хранить в БД, вместо пароля.
Регистрация на сайте
Перед тем, как мы начнем добавлять аутентификацию на своем сайте, придётся добавить форму для регистрации нового аккаунта.Аккаунт — это учётная запись пользователя.Чтобы завести аккаунт, требуется пройти регистрацию — это заполнение специальной формы, где пользователь указывает свою почту, пароль, и, возможно, дополнительную информацию.
Собираем всё вместе
Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:
Хранение паролей
Пароль пользователя — это секретный набор символов, который используется в дальнейшем в ходе аутентификации. Зная пароль пользователя, злоумышленник может войти на сайт под его именем. По этой причине пароль нельзя хранить в базе в открытом виде. Ведь если информацию из БД сайта украдут, то
данные всех пользователей станут скомпрометированными.Вместо самого пароля, в базе будут храниться их отпечатки — хэши.
Вместо заключения
Проблемы с dev режимом во vue – это неприятный момент. Мы хотим и апишечку подергать, и все удобства vue-cli использовать. И на елку влезть, и ничего не ободрать.
Возможно, есть более изящный способ обойти эти проблемы в dev режиме, но я их пока не нашел. Поэтому приходится подпирать код лишними условиями.