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

Question

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

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

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

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

Любые другие идеи?

Answer 1

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

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

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

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

Answer 2

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

Редактировать: Jeff написал followup article с несколькими способами предотвращения атак CSRF.

Answer 3

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

Если такого хэша нет или он отличается, отклоните подачу.

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

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

Проведите поиск статей по CSRF, возможно, вы найдете полезные ответы на это сообщение Stack Overflow. ;)

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