Как стать автором
Обновить

Комментарии 22

Спасибо, большое!

Я раньше совсем не задумывался над этой проблемой, приятно, что Django становится еще удобнее и дружественнее к разработчику.
Да, спасибо. Полезно.
а не лучше ли как в RoR? По умолчанию(если не отключено в конфиге) токен в любой форме, если не указано обратное. Сдается мне — форм внутри сайта гораздо больше, чем форм на внешние ресурсы(которых у большинства сайтов вообще нету). Зачем делать лишнюю работу и засорять шаблон?
Это же пейтон, ничего не поделать. Они и логику в шаблонах злом считают.
вы таки удивитесь, но не только они оО
Чем декоратор-то не устраивает?
тем что:
1) О нем надо знать и помнить. Комментарии наверху показывают что этого большинство не знает;
2) По умолчанию оно правильней. Посудите сами — все или почти все формы указывают на сам сайт;
На ум приходит только один случай, когда я отключал токены — морда для части функционала на flex(flash). Хотя и там можно найти выход.
Как гласит Дао — «Явное лучше неявного» :)
По умолчанию защита CSRF включается глобально для всех view через middleware (эта middleware есть во вновь создаваемом через startproject settings.py), и в своем коде правильно — это отключать ее через декоратор, а не включать. Это дает то преимущество, что нельзя случайно забыть про защиту где-то: отправка форм просто не будет работать и выдаст подробную ошибку с инструкцией, что делать.
Первое предложение было именно такое, как Вы говорите. Оно даже было реализовано (см. github.com/simonw/django-safeform).

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

Если интересно, почитайте дискуссию и это сообщение в ней.
Спасибо за статью.
>Новая защита требует от вас теперь вручную добавлять {% csrf_token %} во все ваши формы

Я и со старой всегда так делал :) А вообще — меньше, меньше форм!
Полезно. Спасибо.
Плохо: «апельсин сок», «трамвай поездка», «CSRF атака».
Хорошо: «апельсиновый сок», «поездка на трамвае», «CSRF-атака», «атака через CSRF».
Не будем путать грамматику русского и английского языков.

За перевод спасибо, всегда было лень разобраться в этой штуковине (опасный подход «работает-и-ладно»), а с 1.2 необходимость изучения вопроса стала актуальнее. На исходный материал без Вашего перевода не скоро наткнулся бы, хоть сайт и знаком.

Кстати, а не перевести ли token как маркер?
Token как маркер — однозначно нет. Никто не поймёт. Так и nonce можно перевести. :)

Атаку поправил, спасибо за замечание.
спасибо за перевод, уже совсем скоро бум отмечать релиз)
О, спасибо за обзор. Как раз просил, чтобы кто-нибудь написал. Держите плюс в карму.

Радует, что нет глобального требования обновления форм, а то я боялся, что после миграции на новую версию джанго вся работа остановится пока не добавим во все формы токен (а у меня формы не всегда используются по прямому назначению — в некоторых случаев для работы с аяксовыми запросами).
Как вы считаете — можно-ли положиться на этот механизм и отказаться от каптчи?
Всё-таки эти вещи предназначены для разных задач. Каптча (Completely Automated Public Turing test to tell Computers and Humans Apart) предназначена для различения роботов и людей. Ей, конечно, можно защититься от CSRF атак, но вы же не станете закрывать каждую вашу форму на сайте каптчей даже для залогиненых пользователей?
Нет. Я имел ввиду наоборот, что положиться на csrf-защиту и не ставить капчу.
Позволит ли этот механизм от ботов защититься.
.
Нет. Бот точно так же, открыв страничку на вашем сайте, получит токен и, если он достаточно хорош и поддерживает куки, отправит запрос на сервер с валидным токеном.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории