Защита CSRF путем хранения данного случая в Переменной сеанса и форме
Для защиты от CSRF, необходимо поместить данный случай в скрытое поле в форме, и в cookie или в переменной сеанса. Но что, если пользователь открывается на несколько страниц на различных вкладках? В этом случае каждая вкладка имела бы форму с уникальным данным случаем, но будет только один данный случай, сохраненный в переменной сеанса или cookie. Или если бы Вы пытаетесь сохранить все данные случаи в cookie/переменной сеанса, как Вы определили бы, какой принадлежит который форма?
2 ответа
Вы можете сохранить один и тот же одноразовый номер в каждой из форм. Самый простой способ сделать это - привязать одноразовый номер к идентификатору сеанса, чтобы эти формы работали только в этом сеансе.
Вы захотите, чтобы злоумышленникам было сложно перехватить идентификаторы сеансов и создать свои собственные одноразовые номера. Итак, один из способов сделать это - использовать HMAC-SHA256 (или что-то подобное) для хеширования идентификатора сеанса, используя ключ, который вы не раскрываете публике.
(Очевидно, что если злоумышленник может получить фактический идентификатор сеанса, он уже может захватить сеанс.Я говорю не об этом, а о возможности злоумышленника создать сценарий (который запускается на компьютере жертвы), который может каким-то образом захватить идентификатор сеанса и использовать его для динамической генерации URL-адреса с предварительно заполненным одноразовым номером. .)
ETA: Достаточно ли описанного выше подхода сам по себе, зависит от того, как долго, по вашему мнению, продлятся ваши типичные сеансы. Если пользователи обычно используют длительные сеансы продолжительностью более нескольких часов, вам нужно будет использовать что-то более сложное.
Один из подходов заключается в создании нового одноразового номера для каждой формы, который содержит метку времени, а также хэш (timestamp. Sessionid) (где хэш - это некоторый вариант HMAC как описано выше, чтобы предотвратить подделку, и . - конкатенация строк). Затем вы проверяете одноразовый номер:
- проверяя временную метку, чтобы убедиться, что одноразовый номер достаточно свежий (это зависит от вашей политики, но обычно несколько часов)
- , затем вычисляя хэш на основе временной метки и сеанса ID и сравнение с одноразовым номером для проверки подлинности одноразового номера
Если проверка одноразового номера не удалась, вы захотите отобразить новую форму, предварительно заполненную отправкой пользователя (чтобы, если они заняли целый день написать свой пост, они не потеряют всю свою тяжелую работу), а также свежий одноразовый номер. Тогда пользователь может сразу же успешно отправить заявку повторно.
Некоторые люди создают токен для каждой формы, и это очень безопасный подход. Однако это может сломать ваше приложение и разозлить пользователей. Чтобы предотвратить все XSRF на вашем сайте, вам просто нужна уникальная переменная 1 токена для каждого сеанса, и тогда злоумышленник не сможет подделать любой запрос, если он не сможет найти этот 1 токен. Незначительная проблема с этим подходом заключается в том, что злоумышленник может подобрать этот токен, пока жертва посещает веб-сайт, контролируемый злоумышленником. ОДНАКО, если токен довольно большой, например, 32 байта или около того, то для грубой силы потребуется много лет, и сеанс http должен истечь задолго до этого.