2016-12-14 28 views
2

Почти все документы, посвященные механизму анти-CSRF, указывают, что токен CSRF должен быть сгенерирован на стороне сервера. Однако мне интересно, нужно ли это.Нужно ли генерировать токен анти-XSRF/CSRF на стороне сервера?

Я хочу осуществить анти-CSRF в этих шагов:

  1. Там не на стороне сервера сгенерированный CSRF маркер;

  2. В браузере, на каждом представлении AJAX или в форме, наш JavaScript генерирует случайную строку в качестве токена. Этот токен записывается в файл cookie csrf до того, как произойдет фактическое представление AJAX или формы; и токен добавляется к параметру как _csrf.

  3. В стороне сервера, каждый запрос должен иметь печенье CSRF и представленный аргумент _csrf. Эти два значения сравниваются. Если они разные, это означает, что это атака CSRF.

На стороне сервера не требуется выдавать токен CSRF, просто выполните проверку; и токен полностью генерируется в браузере. Конечно, это только для анти-CSRF. Для проверки идентификатора пользователя должен выполняться процесс аутентификации на стороне сервера.

Это звуковое решение для CSRF, но я не уверен, почему нет документации по этому подходу.

Есть ли недостатки в этом механизме анти-CSRF?

ответ

1

Насколько я понял, вы хотите создать свой анти-CSRF на стороне клиента, сохранить его в файле cookie и добавить его в качестве параметра запроса, поэтому, когда сервер читает ваш запрос, просто проверяет, совпадает ли ваш cookie-маркер CSRF и параметр, и он решает, является ли он действительным запросом или нет.

Причина создания маркера анти-подделки на стороне сервера заключается в том, что сервер создаст этот токен, и только сервер будет знать правильное значение, поэтому, если этот параметр слегка изменен на стороне клиента, он будет не быть идентичным тому, который хранится на сервере, и этого будет достаточно, чтобы отметить запрос как атаку подделки запроса на межсайтовый сайт. Любые созданные на стороне клиента данные могут быть взломаны злоумышленником, и из-за этого вы не можете полагаться на эту информацию, например, в своем подходе вы создаете случайное значение на своей стороне клиента и присваиваете это значение своему CSRF и ваш параметр _csrf, скажем, что ваше значение «h246drvhd4t2cd98», но поскольку вы только проверяете, что ваши 2 переменные с клиентской стороны имеют одинаковое значение, злоумышленник может легко создать свой файл cookie CSRF и переменную с помощью такое значение, как «I'mByPassingThis» на обоих из них, и ваш сервер будет указывать его как действительный запрос, так что вы вообще не получаете безопасность. С другой стороны, если токен генерируется на сервере, злоумышленник не имеет возможности узнать ожидаемое значение, и это значение будет отличаться для каждого запроса, поэтому наилучшим подходом злоумышленника будет просто попытаться угадать его, что должно быть практически невозможно, если только вы не используете генератор прогнозируемых случайных чисел на стороне сервера.

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

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