Как лучше всего предотвратить CSRF-атаки в приложении GAE?

Question

Итак, как лучше всего предотвратить атаку XSRF для приложения GAE? Представьте себе следующее:

1. Любой может видеть открытый объект пользователя, а идентификатор db.Model используется в запросе, чтобы выяснить, какой объект показывать. Злонамеренный пользователь теперь имеет идентификатор.
2. Вредоносный пользователь создает собственный объект и проверяет форму удаления. Теперь они знают, как удалить объект с определенным идентификатором.
3. Вредоносный пользователь заставляет невинного пользователя отправить запрос на удаление объекта этого пользователя.

Какие шаги я могу добавить, чтобы предотвратить # 3? Обратите внимание, что когда я говорю «ID», я использую фактическую часть «ID» ключа. У меня была идея использовать полное значение ключа в запросах на удаление, но помешает ли это злоумышленнику понять это? Насколько я знаю, ключ - это некоторая комбинация типа класса модели, идентификатора приложения и идентификатора экземпляра объекта, поэтому они, возможно, могут получить ключ из идентификатора, если захотят.

Есть еще идеи? Джефф написал пост об этом и предложил несколько методов - скрытое значение формы, которое будет меняться при каждом запросе, и значение cookie, записываемое через js в форму. Я не хочу исключать пользователей, не поддерживающих JavaScript, поэтому решение для файлов cookie не годится - для значения скрытой формы мне придется выполнять запись в хранилище данных при каждом запросе, отображающем удаляемый объект, - не идеальная ситуация для масштабируемой приложение!

Есть еще какие-нибудь идеи?

Answer 1

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

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

Этот подход проверяет, что запрос на удаление исходит от вашей формы, путем присутствия маркера безопасности в форме; и не требует записи в хранилище данных.

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

Answer 2

Простой: проверьте реферер. Это (преднамеренно) невозможно установить с помощью Javascript, HTML-форм и т. Д. Если оно пустое (некоторые прокси и браузеры лишают ссылок) или с вашего собственного сайта - или, более конкретно, из ожидаемого источника - разрешите это. В противном случае отрицать это и зарегистрировать его.

Редактировать: Джефф написал дополнительную статью с несколькими способами предотвращения CSRF-атак.

Answer 3

В ответе сервера, отображающем форму, создайте магический хеш (на основе ip клиента + дата / время + случайная соль, что угодно). Поместите его в файл cookie и сохраните где-нибудь на сервере. Во время обработки действия отправки проверьте хеш-файл cookie для записи в базе данных.

Если такого хэша нет или он другой, отклоните отправку.

После успешной отправки вы можете удалить хеш-запись, изменить ее состояние на отправленное - что угодно.

Этот метод должен защищать вас во многих случаях, но, безусловно, еще не на 100% пуленепробиваемый.

Выполните поиск статей по CSRF, возможно, вы найдете несколько хороших ответов на эту вещь Переполнение стека . ;)

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