Кто-нибудь видит недостатки в следующем, чтобы предотвратить CSRF?

Question

Мне интересно, будет ли следующий метод полностью предотвращать CSRF и быть совместимым со всеми пользователями.

Вот оно:

В форме просто укажите дополнительный параметр: encrypted(user's userID + request time). Серверная сторона просто расшифровывает и проверяет, что это правильный ID пользователя, а время запроса было относительно недавним.

Помимо того, что кто-то нюхает трафик пользователя или нарушает шифрование, это полностью безопасно? Есть ли минусы?

Answer 1

Хотя ваш подход безопасен, он не является стандартным. Стандартный способ предотвращения CSRF-атак заключается в создании псевдослучайного числа, которое вы включаете в скрытое поле, а также в файл cookie, а затем на стороне сервера вы проверяете, что оба значения совпадают. Взгляните на этот пост .

Answer 2

Одним из основных недостатков является то, что ваша страница будет «истекла», если пользователь оставит свой браузер открытым дольше, чем тот период времени, который вы считаете разумным, до того, как он отправит форму. Я предпочитаю, чтобы сайты не заставляли своих пользователей совершать свои действия, если только это действие не является чувствительным ко времени.

Answer 3

Предложенная вами система безопасности уязвима для атак.

Блочные шифры, такие как AES, обычно используются в качестве очень надежных генераторов случайных чисел. Они называются CSPRNGs . Однако, как и любому генератору случайных чисел, вам нужно беспокоиться о том, чем вы заполняете алгоритм. В этом случае вы используете user's userID + request time, оба из которых могут знать злоумышленники, ваша реализация не имеет ключа или IV, поэтому я предполагаю, что они имеют значение NULL. Атакующий строит запрос, поэтому он всегда будет знать request time. userId, вероятно, является первичным ключом, если у вас есть 100 пользователей, то злоумышленник может подделать 100 запросов, и один из них будет работать. Но злоумышленник может просто захотеть заставить администратора изменить свой пароль, у администратора обычно есть первичный ключ 1.

Не изобретайте заново wheal , очень хорошие генераторы случайных чисел уже созданы, и есть также библиотеки anti-csrf.

Answer 4

Иметь UserID и DateTime - это начало, но вам также нужно значение псевдослучайного числа, предпочтительно с высокой энтропией, в дополнение к канареечному токену. По сути, вам нужно снизить предсказуемость токена на странице в данном контексте. Теоретически, наличие только UserID и DateTime может привести к поломке через некоторое время, так как оно не является «достаточно случайным». Сказав это, CSRF-атаки, как правило, пишутся по сценарию и не отслеживаются напрямую, поэтому, в зависимости от уязвимости вашего приложения, этого может быть достаточно.

Кроме того, обязательно используйте более безопасный алгоритм шифрования, например Rijndael / AES с ключом битов, достаточным для безопасности вашего приложения, и вектором псевдослучайной инициализации.

Answer 5

Должно работать, да. Хотя я бы посоветовал вам использовать случайное число для UserID при создании новых пользователей, а не просто увеличивающееся число (очевидно, убедитесь, что оно уникально при создании пользователя). Таким образом, злоумышленнику трудно «угадать».

Answer 6

Это не совсем безопасно, так как атакующий сайт может угадать идентификатор пользователя.
Если вы используете ключ шифрования для каждой сессии, он является безопасным. (Но тогда все, что вам нужно, это отправить необработанный ключ, и он уже защищен)

Также помните о часовых поясах и неточных часах.