Alex Pr
А бывает иначе?
Да https://www.owasp.org/index.php/SecureFlag
Сессия обычно так и работает, на точное совпадение "useragent + id сессии + IP + возможно что-то ещё"
По IP ненадёжно и неудобно для пользователей. Например, при смене IP провайдером слетает аутентификация на сайте.
Тут нужно переделывать так, чтоб требовался повторный ввод пароля (по https) на вход в любой закрытый раздел.
Переделывать ничего не придется т.к. как я понял весь приват будет за HTTPS, т.е. куку никто не увидит.
Общее принцип такой: кука устанавливается на HTTPS ресурсе с флагом secure во время логина. Браузер запоминает куку, но никогда не передаёт её по HTTP протоколу. В дальнейшем любые POST запросы, которые требуют аутентификации (отправка сообщений, модерация и.т.п.), должны уходить на HTTPS url. Соответственно браузер будет в них передавать секретную куку. После обработки сервер может при желании редиректить уже на голый HTTP. Таким образом секретная кука с сессией никогда не передаётся плэинтекстом. Повторный ввод пароля в данной схеме излишен, ну кроме самых ответственных операций вроде его смены.
Просто такая схема (частичное покрытие сайта HTTPS, частичное HTTP) сложнее, а значит дороже и затратнее в поддержке. Поэтому я и писал, что в индустрии сейчас по-умолчанию всё закрывают HTTPS - сделал и забыл, не нужно отлавливать все эти грабли. А граблей предостаточно вылезет.
А бывает иначе?
Да https://www.owasp.org/index.php/SecureFlag
Сессия обычно так и работает, на точное совпадение "useragent + id сессии + IP + возможно что-то ещё"
По IP ненадёжно и неудобно для пользователей. Например, при смене IP провайдером слетает аутентификация на сайте.
Тут нужно переделывать так, чтоб требовался повторный ввод пароля (по https) на вход в любой закрытый раздел.
Переделывать ничего не придется т.к. как я понял весь приват будет за HTTPS, т.е. куку никто не увидит.
Общее принцип такой: кука устанавливается на HTTPS ресурсе с флагом secure во время логина. Браузер запоминает куку, но никогда не передаёт её по HTTP протоколу. В дальнейшем любые POST запросы, которые требуют аутентификации (отправка сообщений, модерация и.т.п.), должны уходить на HTTPS url. Соответственно браузер будет в них передавать секретную куку. После обработки сервер может при желании редиректить уже на голый HTTP. Таким образом секретная кука с сессией никогда не передаётся плэинтекстом. Повторный ввод пароля в данной схеме излишен, ну кроме самых ответственных операций вроде его смены.
Просто такая схема (частичное покрытие сайта HTTPS, частичное HTTP) сложнее, а значит дороже и затратнее в поддержке. Поэтому я и писал, что в индустрии сейчас по-умолчанию всё закрывают HTTPS - сделал и забыл, не нужно отлавливать все эти грабли. А граблей предостаточно вылезет.