Как лучше всего предотвратить нападения на CSRF в приложении GAE?
я бы сказал, что никогда не использовать псевдонимы в производственных скриптах (и считается наилучшей практикой). Если это небольшой тестовый код или что-то быстрое и грязное, что никто другой никогда не будет использовать, достаточно справедливо, но никогда в сценариях производства. Псевдонимы можно удалять, изменять для запуска других команд и оставлять вас с непредвиденными результатами, так как они зависят от пользователя.
3 ответа
Когда вы создаете страницу, которая позволяет пользователю удалить объект, генерируйте случайный токен и включайте его в скрытое поле формы. Также установите это значение для файла cookie только для HTTP. При получении запроса на удаление убедитесь, что случайный токен из формы и значение из файла cookie совпадают.
Ваш случайный токен не должен быть просто случайным числом. Вы должны зашифровать комбинацию случайного числа и личности пользователя, чтобы злоумышленникам было сложно подделать свои собственные токены. Вы также должны использовать разные ключи шифрования для значения, хранящегося в форме, и значения, хранящегося в cookie, поэтому, если один из токенов действительно протекает, злоумышленнику по-прежнему трудно подделать другой токен.
Этот подход проверяет что запрос на удаление исходит из вашей формы, по наличию токена безопасности в форме; и не требует записи в хранилище данных.
Этот подход по-прежнему уязвим для атак с использованием межсайтовых сценариев, когда злоумышленник может получить скрытое значение из формы или отправить форму, поэтому тщательно проверьте свой сайт на межсайтовый скриптовые уязвимости. Этот подход также уязвим для атак "кликджекинг" .
Простой: Проверьте ссылающийся домен. (Сознательно) невозможно установить это использование JavaScript, HTML-формы, и т.д. Если это - пробел (некоторые прокси, и браузеры разделяют ссылающиеся домены), или от Вашего собственного сайта - или более конкретно из ожидаемого источника - позволяют его. Иначе отклоните его и зарегистрируйте его.
Править: Jeff написал последующую статью с несколькими способами предотвратить нападения на CSRF.
В ответе сервера, отображающем форму, создают волшебный хеш (на основе клиентского IP + дата/время + случайная соль, безотносительно). Поместите его в cookie и сохраните где-нибудь на сервере. Во время утверждают, что обработка действия проверяет хеш cookie по записи базы данных.
Если нет такого хеша, или это отличается, отклоните представление.
После успешный утверждают, что можно удалить запись хеша, изменение, это - состояние к отправленному - безотносительно исков Вы.
Тот метод должен защитить Вас во многих случаях, но конечно все еще не является на 100% пуленепробиваемым.
Сделайте поиск статей о CSRF, возможно, Вы найдете некоторые хорошие ответы на этой вещи Переполнения стека.;)
Не делайте никаких проверок ссылающегося домена или клиентских проверок IP - это слишком подвержено ошибкам (информация о ссылающемся домене могла бы быть очищена агентом пользователя, прокси или предпочтениями пользователя), и IP клиента мог бы измениться между созданием формы, и представление - не наказывают пользователя за динамическое распределение IP-адресов.