Anonymous85966
@Anonymous85966
Насколько защищены файлы Cookie от кражи?
На сайте имеется система авторизации. От паролей я решил отказаться в угоду безопасности. На странице авторизации имеется поле для ввода email. При вводе email и отправке запроса на сервер на этот email отправляется код подтверждения, который представляет собой 6 значное число. Пользователя перебрасывает на страницу с полем ввода, где требуется ввести код подтверждения. Если пользователь вводит неверный код, то ключ авторизации ему не выдается и страница просит ввести код заново. Если кто-то вводит неверный код больше 10 раз, то аккаунт блокируется. Если код введен верно, возможны две ситуации. Если пользователь на странице авторизации не поставил галочку в поле Запомнить меня, то в сессию сохраняется объект класса User, через который можно получать все данные пользователя, которые нужны для пользования сайтом(id, email и тд). В общем, пользователь авторизирован, но после закрытия браузера сессия будет уничтожена. Если пользователь на странице с авторизацией поставил галочку в поле Запомнить меня, то помимо сессии в куки файл сохраняется дополнительный ключ авторизации. Зачем он нужен? Он нужен для авторизации после уничтожения сессии. Ключ авторизации представляет собой код подтверждения(отправленный на почту), который при помощи конкантенации склеивается со строкой-солью(хранится не сервере, никто не знает значение). Соль нужна для того, чтобы сторонний пользователь вручную не создал куки с ключом авторизации, который просто подобрал(без соли ключ-это просто число, уйдут секунды на его подбор). Далее склеенная строка зашифровывается при помощи необратимого шифрования. Этот ключ сохраняется в базу данных(в ячейку пользователя) и в куки файл. Теперь, после закрытия браузера сессия уничтожится, а куки с ключом останется. Далее, при входе на сайт, на каждой странице сайта происходит извлечение хэша из куки файла и сравнения его с хэшем в базе данных каждого пользователя. Если у кого-то из пользователей хэши идентичен, то устройству с куки файлом выдается сессия с данными пользователя, после чего пользователь авторизован. Также куки файл нужен для функции Выйти со всех устройств, при активации которой из базы данных удаляется ключ авторизации. После этого, как только пользователь с куки файлом, в котором находится ключ доступа, обновляет страницу, активируется функция сравнения ключа в базе данных и ключа в куки. Если ключи не совпадают, то сессия пользователя удаляется(произведен выход из аккаунта). Требуется повторная авторизация. Проблема системы в том, что если сторонний пользователь получит куки с ключом авторизации, то он получит доступ к аккаунту. В связи с этим возникает вопрос, насколько защищены файлы cookie от воровства?
- Вопрос задан
- 287 просмотров
3
комментария
Нинасколько не защищены. Любой стиллер, даже за 10$ имеет функцию стыривания кукисов.
Не совсем понятно зачем такие костыли с ключом из кода, который придет на почту. Разве нельзя просто генерить рандомные байты соответствующей функция в php?
Необратимое шифрование - это не шифрование, а хеширование.
Зачем лочить акк из-за 10 неверных кодов? Тогда любой школьник, чухнувший это сможет забанить любой акк на твоем сайте. Как этого избежать? 1. Не давать информации о том зареган ли юзер с таким мылом или нет. 2. Вешать капчу на ввод кода. Это практически полностью защищает от автоподбора. А лучше делать код не только из 6 цифр. Можно увеличить его длину. Хотя бы до 8 цифр. А еще лучше писать туда и буквы тоже.
Чтобы избежать кражу кукисов нужно сделать пару простых вещей.
1. Начать использовать хотя бы самописное подобие нормальной системы токенов. Посмотри на JWT. Там есть refresh и access токен. Время жизни access токена нужно ставить небольшое. Лучше чтобы это было не более 5 минут. Так как логи со стиллеров и прочей дряни чекаются не сразу.
2. Хранить токены не только в куки. Есть еще и localstorage. Но тут уже кто на что горазд. Кто-то делает не 2 токена, а 3 или больше. Рассмотрим пример с 4 токенами. 2 токена на refresh и 2 токена на access. Один из пары храниться в куки на httponly, а второй токен хранится в localstorage. При операциях предъявляются оба токена. Таким образом стыриванием только куков злоумышленник ничего не добьется. А так же желательно смотреть не только на токены, но еще и на другие детали. Например, user-agent и IP-адрес. Резкая смена того и другого в одной сессии довольно странно. Да, это легко обходится, но не в каждом вредоносном ПО такое предусмотренно. Не каждый рядовой ратник способен организовать какое-то подобие прокси через комп жертвы.
Вообще эта тема довольно непростая и лучше придерживаться то, что уже было придумано и успешно используется.
Почитай про JWT. Можешь посмотреть вот это https://deworker.pro/edu/series/http-basics/authen...
Также можно использовать уже готовые решения в фреймворках на твоем языке.
Не совсем понятно зачем такие костыли с ключом из кода, который придет на почту. Разве нельзя просто генерить рандомные байты соответствующей функция в php?
Необратимое шифрование - это не шифрование, а хеширование.
Зачем лочить акк из-за 10 неверных кодов? Тогда любой школьник, чухнувший это сможет забанить любой акк на твоем сайте. Как этого избежать? 1. Не давать информации о том зареган ли юзер с таким мылом или нет. 2. Вешать капчу на ввод кода. Это практически полностью защищает от автоподбора. А лучше делать код не только из 6 цифр. Можно увеличить его длину. Хотя бы до 8 цифр. А еще лучше писать туда и буквы тоже.
Чтобы избежать кражу кукисов нужно сделать пару простых вещей.
1. Начать использовать хотя бы самописное подобие нормальной системы токенов. Посмотри на JWT. Там есть refresh и access токен. Время жизни access токена нужно ставить небольшое. Лучше чтобы это было не более 5 минут. Так как логи со стиллеров и прочей дряни чекаются не сразу.
2. Хранить токены не только в куки. Есть еще и localstorage. Но тут уже кто на что горазд. Кто-то делает не 2 токена, а 3 или больше. Рассмотрим пример с 4 токенами. 2 токена на refresh и 2 токена на access. Один из пары храниться в куки на httponly, а второй токен хранится в localstorage. При операциях предъявляются оба токена. Таким образом стыриванием только куков злоумышленник ничего не добьется. А так же желательно смотреть не только на токены, но еще и на другие детали. Например, user-agent и IP-адрес. Резкая смена того и другого в одной сессии довольно странно. Да, это легко обходится, но не в каждом вредоносном ПО такое предусмотренно. Не каждый рядовой ратник способен организовать какое-то подобие прокси через комп жертвы.
Вообще эта тема довольно непростая и лучше придерживаться то, что уже было придумано и успешно используется.
Почитай про JWT. Можешь посмотреть вот это https://deworker.pro/edu/series/http-basics/authen...
Также можно использовать уже готовые решения в фреймворках на твоем языке.
Ranwise
@Ranwise
изобрели этакую 2х факторную авторизацию, только теперь юзеру нужно сходить на почту и скопировать ваш пароль, на мобилке это очень удобно, или еще раз вбивать пасс к почте
Войдите, чтобы написать ответ
Войти через центр авторизации-
-
-
-
-
Простой
Пользователю user1 запрещён доступ в ssh, но в процессах висит sshd от user1. Почему?
- 2 подписчика
- 164 просмотра
-
Простой
Найдена опасная уязвимость в очень популярном мобильном приложении. Что делать?
- 10 подписчиков
- 945 просмотров
-
-
-
-
- Показать ещё Загружается…
