Безопасная защита CSRF без сеансов или базы данных?

я пытаюсь реализовать безопасную защиту CSRF для формы входа в HTML,
я знаю, что лучший способ реализовать защиту CSRF — хранить случайные csrf_key в сеансе,
но я хочу добавить CSRF в мой логин & формы регистрации … и я не хочу хранить много сеансов для любых анонимных незарегистрированных пользователей …

поэтому я хочу создать лучший безопасный posibble без использования сессий или базы данных, только со скрытым полем формы /& cookie, и после входа в систему я буду использовать защиту csrf сессий.

моя идея защищенного user_storage только csrf:

csrf_token = AES (ip + useragent + метка времени + random_data, csrf_aes_site_key)

когда csrf_aes_site_key жестко запрограммирован в конфигурационном файле.
и после каждого входа в систему / регистрации я буду дешифровать строку AES + подтвердить, что IP&ua соответствует ip запроса&да, и отметка времени не слишком совпадает впереди, скажем, 5 минут (если csrf_timestamp + 18000> = current_ts), а random_data — просто случайность (и убедитесь, что один и тот же пользователь не получит один и тот же csrf_token, если его запросят несколько раз в одном и том же ц) …

так … это достаточно безопасно, это хорошее решение?
если нет, то есть ли другие предложения по решению этой дилеммы?
поблагодарить!

РЕДАКТИРОВАТЬ:
Реализация, которую я только что создал, и она работает нормально, но достаточно ли это хорошо?

полный пример:
https://github.com/itaiarbel/aes_based_csrf_protection

выпуск 1:
пользователь может взять csrf_token и успешно отправить форму, используя тот же токен в течение следующих 5 минут
ошибка? какое мне дело, если пользователь отправит много раз? пока это не атака csrf …

выпуск 2:
если страница остается открытой в течение 5 минут, пользователь не сможет войти,
(обновлять страницу входа автоматически каждые 5 минут? возможно, измените ее на 1 час?)

Можете ли вы определить какой-либо конкретный риск безопасности с помощью этой реализации? или я могу предположить, что это безопасный способ защиты CSRF?

5

Решение

Метод хранения токена CSRF в cookie довольно широко используется (AngularJS, Джанго) но работает немного по другому. Сервер отправляет токен в печенье, клиент использует JavaScript для чтения куки и отражать знак в Заголовок HTTP. Сервер должен проверять значение только из заголовка HTTP, даже если файл cookie будет также отправлен автоматически.

Фактические имена файлов cookie и заголовков не важны, как только интерфейс JavaScript и серверная часть знают о них.

Это предотвращает CSRF, потому что только JavaScript, запущенный из подлинного источника, сможет прочитать cookie (см. подробное обсуждение в Википедии). Токен может быть HMAC cookie сеанса, что устраняет необходимость запоминания состояния токена на стороне сервера.

Основное преимущество заключается в том, что этот подход (в отличие от подхода с токеном в полях формы) работает с одностраничными приложениями на основе JavaScript, где вы не генерируете HTML на сервере и не можете встроить токен CSRF в их код.

5

Другие решения

Это будет работать для большинства клиентов — но ужасно потерпит неудачу, когда клиент получает доступ к вашему сайту через прокси с балансировкой нагрузки (IP-адрес клиента, который вы видите с изменением). Более правильное решение будет использовать данные организации из записи whois или номера ASN, но их поиск требует затрат — в зависимости от объема трафика, возможно, достаточно просто использовать первые 16 бит адреса (IPV4).

Вы также можете столкнуться с проблемами в зависимости от того, сколько пользовательского агента вы храните (Google Chrome может обновляться на лету).

0

По вопросам рекламы [email protected]