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

Question

[slava kk]

Как защитить php сессию от кражи?
Способ с IP адресом использовать нельзя, ибо у многих он динамический, а будет неудобно, когда сессия будет каждые 10-15 минут слетать.

Comments

[Антон Р.]

Чего?? Какой еще кражи? Сессия хранится у тебя на сервере под уникальным id, как её могут украсть?

[slava kk]

Антон Р., id хранится в куке на стороне клиента, а куку украсть уже возможно.

[Антон Р.]

slava kk, и что? это уже проблемы безопасности компьютера пользователя, если у него там троянов полный набор.

[Vitsliputsli]

slava kk,

id хранится в куке на стороне клиента, а куку украсть уже возможно.

тогда храните не в куке, а в том месте, которому доверяете.

[FanatPHP]

Vitsliputsli, например?

[Vitsliputsli]

FanatPHP, не знаю какому месту доверяет автор... Выбирать в любом случае из cookie, local storage, js, html + выбирать способ передачи на сервер и обратно. Но, я ни в коем случае не говорю, что какой-то из этих способов лучше.

Answer 1

[fso]

1) Использовать https.
2) Генерировать стойкий к подбору session id
3) Ставить куку с атрибутом httpOnly - доступ через document.cookie будет закрыт.
Этих пунктов более чем достаточно.

Answer 2

[alex-1917]

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

Answer 3

[Evgeniy Ivanov]

Вопрос устарел лет на 20....

Answer 4

[xmoonlight]

Варианта 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. После получения хеша от клиента, сервер анализирует хеши: если клиентский и серверный хеши верны, то сервер одобряет перевыписку (обмен устаревшего токена на новый) и возвращает новый токен. Иначе - генерирует процедуру ручной аутентификации.

Вы не испытываете неудобств, т.к. для пользователя это всё проходит незаметно, не отвлекая его от работы.

Answer 5

[Марат Мхитарян]

Если кратко - никак. Юзер должен что-то показать в качестве ключа доступа. Например если твои сейчии недолжеы истекать ты можешь юзать JWT ключи .

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