slavchickalpha
@slavchickalpha

Как защитить php сессию?

Как защитить php сессию от кражи?
Способ с IP адресом использовать нельзя, ибо у многих он динамический, а будет неудобно, когда сессия будет каждые 10-15 минут слетать.
  • Вопрос задан
  • 835 просмотров
Решения вопроса 1
@fso
1) Использовать https.
2) Генерировать стойкий к подбору session id
3) Ставить куку с атрибутом httpOnly - доступ через document.cookie будет закрыт.
Этих пунктов более чем достаточно.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
alex-1917
@alex-1917
Если ответ помог, отметь решением
Последнее, что надо защищать, это сессия.
Донесите уже это до всех криворучек, клепающих дырявые плагины для вордпресс, модули-решето для джумла, компоненты-костыли для битрикса.
Ответ написан
Комментировать
@cpanelhostig
hosting, php dev
Вопрос устарел лет на 20....
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Варианта 2 (можно использовать как по-отдельности, так и все сразу):
1. Самый простой (и лучше не забывать!) вариант:
Всегда ставить флаги HttpOnly и Secure в http-заголовки, когда устанавливаете данные, которые не должны быть доступны из JS-скриптов.
Ссылки:
1. https://www.php.net/manual/en/session.configuratio...
2. https://www.owasp.org/index.php/HttpOnly

2. Обмен токена (перевыписка) делается цепочкой:
1. Вы зарегились на сайте. Запрос на выписку НОВОГО токена генерирует JS-код браузера, обменивая хэш валидации, зависящий от IP и ClientID (User-Agent и ещё какие-то параметры) сервером на рабочий токен (лучше - обменивать ещё и временный токен, который приходит в письме по электронной почте сразу после регистрации). Т.е., браузер НЕ ПЕРЕДАЁТ IP и ClientID в чистом виде на сервер.
2. Вы работаете и вдруг у Вас меняется IP-адрес (сессия - та же): посылается команда обмена старого токена на новый сервером на клиент (или переаутентификация/перевыписка токена в "прозрачном" режиме). До окончания успеха этой операции - все запросы от текущего клиента будут невалидны!
3. Клиент посылает в ответ HASH: CliendID, текущий (устаревший) токен и предыдущий IP-адрес, и подписывает всё какой-либо частью устаревшего токена.
4. После получения хеша от клиента, сервер анализирует хеши: если клиентский и серверный хеши верны, то сервер одобряет перевыписку (обмен устаревшего токена на новый) и возвращает новый токен. Иначе - генерирует процедуру ручной аутентификации.

Вы не испытываете неудобств, т.к. для пользователя это всё проходит незаметно, не отвлекая его от работы.
Ответ написан
Комментировать
@marataziat
Джангист-тракторист
Если кратко - никак. Юзер должен что-то показать в качестве ключа доступа. Например если твои сейчии недолжеы истекать ты можешь юзать JWT ключи .

Если твой сайт работает через https ты можешь делать авторизацию через публичный ключ https клиента. Насколько я знаю в ssl есть публичные и приватные ключи. Ты бы мог заюзать api например nginx и как то проверять если запрос https то какому public key id он принадлежит :)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы