Анти-CSRF печенье? - PullRequest
Новая
       3

Анти-CSRF печенье?

3 голосов
/ 24 ноября 2011

Я создаю приложение, которое использует много AJAX.Большинство анти-CSRF-решений вращаются вокруг размещения некоторой информации в состоянии просмотра и работы с этими данными на почте.Однако у меня нет доступа к состоянию просмотра при вызове ajax.

Я планирую сгенерировать GUID для вставки токена в файл cookie и состояния сеанса, чтобы срок действия файла cookie истек при выходе пользователяизменяйте маркер cookie и состояние сеанса при каждом запросе и используйте httpmodule для выполнения работы, сравнивая то, что в сеансе, с тем, что возвращается от клиента, перед переходом к веб-службе или методу страницы.

Будет ли это доказательство CSRF моего приложения?

Спасибо.

1 Ответ

9 голосов
/ 24 ноября 2011

Нет."anti-CSRF" и "cookie" не объединяются. Как кратко указывает Тило:

Cookies - это то, что позволяет CSRF работать в первую очередь ...

Хорошее начальное чтение: Подделка межсайтовых запросов Статья, в которой большая часть CSRF суммируется с:

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

Проблема в том, что в браузере всегда есть «действительный файл cookie». Тем не менее, GUID - действительно, просто nonce - может быть передан back на сервер другими средствами ... что фактически является тем, что он находится в состоянии просмотра.

Механизм предотвращения CSRF # 1 (согласно Википедии):

Требование секретного пользовательского токена во всех отправленных формах и URL-адресах с побочными эффектами предотвращает CSRF; сайт злоумышленника не может вставить правильный токен в свои сообщения.

Важным моментом является то, что этот секрет (мы надеемся, что это исключает возможность повторных атак) - это часть данных (URI или контент), которые отправляются и не передаются через cookie.

Удачного кодирования.

Считайте, что это можно реализовать одним из способов:

Пусть сервер генерирует одноразовый номер при установлении сеанса (и сохраняет его в данных сеанса). Затем при каждом запросе AJAX отправьте этот одноразовый номер обратно - либо как часть URI, либо как некоторые данные POST *.

Серверный сервер должен принимать / отклонять запрос только на основе этого одноразового номера и, если он соответствует одноразовому номеру, сохраненному в состоянии сеанса. (Состояние сеанса может поддерживаться с помощью файлов cookie: это одноразовый номер, передаваемый по другому каналу, который предотвратит этот CSRF, предполагая, что одноразовый номер является секретным.)

Одноразовый номер может быть передан клиенту несколькими способами, включая, но не ограничиваясь этим, скрытое поле, переменную JavaScript, манипулирование прямыми ссылками или даже cookie (только для чтения! Не для проверки!).

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

...