у вас оба хеша в БД?

Второго хеша нет. Залогинился юзер, записываем хеш в БД и этот же в сессию. Дальше, при каждом запросе, сравнивается хеш из сессии с записанным в БД.

P.S. Этот же хеш используется для защиты от CSRF в формах. Возможно, что под вторым хешем вы поняли это и как раз, возможно, что это лишнее?

Аутентичненько, однако..
Зависит от того пишешь ли ты в БД и сессии, не?
А завтра резко перестанет, и останешься без штанов с голыми помидорами.
Ну вот нет её, и как гостю капчу вводить без сессии?
Шинель заправленая в трусы.
А сессия не в БД? Значит шинель заправленая в трусы.
А хеш из БД достается по еще одному хешу из сессии? Ну шинель же, заправленая в трусы.
Так это же сессионная кука, и она не меняется достаточно длительное время.
Шинель заправленая в трусы только ради успокоения но не защиты от CSRF.
..., шинель заправленая в трусы.
Т.е. по твоему тру, иногда, может стать не тру?
Хайлоад грядёт! Закупи яйцы куриные про запас. Скоро будет на чем жарить.

Хоть бы что-то по существу... Я же писал, что разработка не моя. А вот я пытаюсь понять, как привести её в божеский вид.

Букав много?
А если объяснять по существу, то, столько же этих букав станет?
И как это тебя оправдывает? Работа то -- твоя.

Краткий список задач по пунктам тебя устроит?

Устроит.

P.S. Впрочем, забудьте. А то у меня создается ощущение, что я клянчу.
Я не ищу оправданий, т.к. они мне не нужны. Я объяснял ситуацию и не более того.
Естественно! Поэтому я и не просил, чтоб кто-то делал её за меня. Вы видели где-то в моем вопросе что-то вроде кода, с просьбой поправить его? Вопрос риторический. А если вы считаете, что делиться личным опытом или указывать на какие-то конкретные ошибки с конструктивным пояснением - это приравнивается к "сделайте за меня", то пардоньте, что потревожил.

Нет. В двойной сверке с данными, которые хранятся на сервере, нет необходимости.

Задача - обезопасить себя от CSRF атак, поэтому нужно задействовать более подходящий для задачи механизм, то есть токены. Желательно одноразовые.

Если речь о CSRF, то не достаточно. Нужно обязательно сверять токен отправленный клиентом и тот, что хранится на сервере. Ну а если токен от клиента не пришел, то такой запрос можно считать не валидным.

Лучше проверить например на isset, потому что данного ключа может просто не существовать.
Если нужно проверить на наличие ключа + сверить значение этого ключа, то действуем соответственно.

Спасибо, понял.Тут я засомневался немного в другом ключе, в плане идентификации пользователя, который работает в данной сессии. Наверно, это уже относится к XSS, но если украсть сессию, то обычное булевое значение, указывающее на то, что юзер залогинен, даст полный доступ ко всем его данным. Хотя, это рассуждения с дилетантской точки зрения.
Но в целом, спасибо за советы.

Не надо нам тут гвозди забивать двуручной пилой.



1) Перенести хранение сессии в БД, полностью и чтоб она только там была.

2) Стартовать сессию (ага, к БД не забудь подключиться) всегда, вне зависимости от того кто это, гость или пользак.
И если гость -- формировать идентичный профилю пользака объект, с пометкой что это гостевая роль.

3) Перевести все, требующие защиты от CSRF места, на POST/PUT/DELETE запросы.
После чего не использовать CSRF-токен вообще.

Только учти что эти три пункта легко могут обеспечить тебя гемором на пол года вперед.
Поэтому определись:

а) готов ли ты к долгоделу?
б) готов ли ты велосипедить?
в) может лучше взять серьезный фреймворк? там все это есть
г) может оставить все как есть?

Так, видимо, эту тему всё-таки надо прочитать и понаписать текста.
(Добавление)

Давайте начнём с проверки понимания: зачем этот токен делается? Без него же проще.

Идея ответа верна - защита от CSRF. Но зачем он делается?
Отдельный вопрос DeepVarvar'у: если на подконтрольную тебе страницу пришёл пользователь, какая тебе проблема попросить браузер пользователя сделать не GET-запрос на атакуемую страницу, а тот же POST?
Собственно идея: GET должен только читать данные. Обработка GET не должна менять состояние мира. Если это выполняется - то GET-запросы от CSRF защиты не требуют.
А вот запросы на изменение данных - требуют.

Возвращаясь к сути CSRF. Вектор атаки в том, что пользователь авторизован у вас, но свободно гуляет по интернету с этого же браузера. Случайно попадает на совершенно посторонний сайт (злоумышленника или хороший сайт, но скомпрометированный), на котором размещён код, который заставляет браузер пользователя выполнить запрос на ваш сервер. Браузер послушно лезет на ваш сервер, любезно подставляет авторизационные куки, и ваш сайт, считая что пользователь зашёл сам, выполняет этот запрос. Готово, пользователь того не хотел и обычно даже не заметил, а что-то нехорошее произошло.
Ну и нафига тут БД?
К слову про SSL - в вопросе CSRF ничем не отличается от HTTP. Даже не требует атакующему быть HTTPS - запрос из HTTP на HTTPS считается безопасным и не даёт предупреждений пользователю, в отличии от обратного.


Надёжно. Если перехватят куку - то дублирование токена в базе ничего не заметит. А других методов подменить файл сессии нет. Ну кроме прямого доступа к серверу.
Таким образом вы лишь мешаете авторизоваться с двух машин. Например, со смартфона и десктопа одного и того же человека.


То чуть менее чем весь мир у ваших ног. Потому что куки - единственный метод отличить одного пользователя от другого, предоставляемый нам протоколом HTTP.
И HTTPS этой угрозе хорошо мешает. Только вот там тоже не всё так просто. SSL уязвим и использовать его уже нельзя (любой версии). Использовать надо TLS и ещё сколько-то гаек покрутить в области допустимых ciphers
Если параноить, то можно поверх немного прикрутить. Например, поведенческие факторы: если пользователь час назад заходил из Москвы, и тут вдруг из Китая - возможно, что-то не так. Но это мог быть просто VPN. Если вы не банк и у вас нет чемодана денег на разработку - то сессионной куки достаточно.