Безопасная защита 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?
Решение
Метод хранения токена CSRF в cookie довольно широко используется (AngularJS, Джанго) но работает немного по другому. Сервер отправляет токен в печенье, клиент использует JavaScript для чтения куки и отражать знак в Заголовок HTTP. Сервер должен проверять значение только из заголовка HTTP, даже если файл cookie будет также отправлен автоматически.
Фактические имена файлов cookie и заголовков не важны, как только интерфейс JavaScript и серверная часть знают о них.
Это предотвращает CSRF, потому что только JavaScript, запущенный из подлинного источника, сможет прочитать cookie (см. подробное обсуждение в Википедии). Токен может быть HMAC cookie сеанса, что устраняет необходимость запоминания состояния токена на стороне сервера.
Основное преимущество заключается в том, что этот подход (в отличие от подхода с токеном в полях формы) работает с одностраничными приложениями на основе JavaScript, где вы не генерируете HTML на сервере и не можете встроить токен CSRF в их код.
Другие решения
Это будет работать для большинства клиентов — но ужасно потерпит неудачу, когда клиент получает доступ к вашему сайту через прокси с балансировкой нагрузки (IP-адрес клиента, который вы видите с изменением). Более правильное решение будет использовать данные организации из записи whois или номера ASN, но их поиск требует затрат — в зависимости от объема трафика, возможно, достаточно просто использовать первые 16 бит адреса (IPV4).
Вы также можете столкнуться с проблемами в зависимости от того, сколько пользовательского агента вы храните (Google Chrome может обновляться на лету).