Исходя из того, что вы нам сказали, ваши настройки могут быть безопасными или нет.Вам нужно будет предоставить более подробную информацию, чтобы сообщить нам наверняка.
Например, основываясь на том, что вы нам сказали, вы в основном выдаете пользователю два отдельных токена-носителя, говорящих, что «носитель этоготокену разрешен доступ к сеансу 12345 ", один из токенов хранится в файле cookie httpOnly, а другой - в LocalStorage, и разрешает доступ только в том случае, если оба токена присутствуют и действительны и соответствуют друг другу.
Однако в вашем описании неясно, будет ли токен LocalStorage также действительным в качестве токена cookie или наоборот.Если бы это было так, злоумышленник, который захватил один из токенов, мог бы просто отправить один и тот же захваченный токен дважды в одном и том же запросе Ajax, один раз в файле cookie и один раз в параметрах запроса, и поэтому он выглядит действительным.
Более тогопростой проверки того, что два токена в запросе не совпадают, может быть недостаточно, поскольку злоумышленник может захватить, например, два разных действительных токена LocalStorage для одного и того же сеанса.Скорее всего, чтобы предотвратить подобные атаки, нужно включить в подписанные данные какой-либо идентификатор типа токена , который составляет токен (например, просто type: "cookie" против type: "param") ичтобы убедиться, что тип каждого токена действительно соответствует способу их представления на сервере.
Или, в качестве альтернативы, вы можете использовать два разных ключа подписи для маркеров cookie и маркеров параметров;таким образом, копирование токена из LocalStorage в файл cookie или наоборот автоматически сделает подпись недействительной.
Тем не менее, если вы каким-то образом убедитесь, что каждый тип токена действителен только при представлении через соответствующий канал.Ваша настройка по крайней мере не менее безопасна, чем просто использование одного токена.Он также должен защищать от определенных типов дополнительных атак, таких как CSRF-атаки (которые могут позволить злоумышленнику делать вредоносные запросы с помощью файлов cookie законного пользователя), и определенные виды атак с использованием JS-инъекций (которые могут поставить под угрозу локальное хранилище пользователя, но не его файлы cookie).).
Однако мы не можем точно определить, являются ли эти атаки релевантными угрозами для вашего приложения, и могут ли быть другие атаки, для которых ваша схема не достаточна для защиты от нее.,В частности, в то время как ваша схема должна быть достаточной защитой от атак, которые только скомпрометируют LocalStorage, стоит отметить, что большинство видов атак, которые могут сделать это, также позволяют злоумышленнику делать другие вещи, такие как создание своего собственного Ajaxзапросы из браузера пользователя (что может помешать вашей схеме).
При этом, по крайней мере, ваша схема (если она реализована правильно) обеспечивает защиту от CSRF, что очень полезно.Предоставляет ли он что-то большее, чем другое.
(В любом случае, как правило, нет необходимости шифровать идентификатор сеанса или любой токен, содержащий его, если злоумышленник не может сделать что-либо вредоносное, просто зная,идентификатор сессии. И если бы они могли, то иметь идентификатор сессии, такой как «12345», было бы в любом случае плохой идеей, поскольку злоумышленнику было бы легко попробовать все идентификаторы сессии, скажем, от 0 до 999999.)