Django 1.2 и CSRF

[junk]

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

Я раньше совсем не задумывался над этой проблемой, приятно, что Django становится еще удобнее и дружественнее к разработчику.

[rukeba]

Да, спасибо. Полезно.

[N3K]

Спасибо!

[motiv]

а не лучше ли как в RoR? По умолчанию(если не отключено в конфиге) токен в любой форме, если не указано обратное. Сдается мне — форм внутри сайта гораздо больше, чем форм на внешние ресурсы(которых у большинства сайтов вообще нету). Зачем делать лишнюю работу и засорять шаблон?

[vorbiz]

Это же пейтон, ничего не поделать. Они и логику в шаблонах злом считают.

[tibalt]

вы таки удивитесь, но не только они оО

[igorekk]

Чем декоратор-то не устраивает?

[motiv]

тем что:
1) О нем надо знать и помнить. Комментарии наверху показывают что этого большинство не знает;
2) По умолчанию оно правильней. Посудите сами — все или почти все формы указывают на сам сайт;
На ум приходит только один случай, когда я отключал токены — морда для части функционала на flex(flash). Хотя и там можно найти выход.

[igorekk]

Как гласит Дао — «Явное лучше неявного» :)

[kmike]

По умолчанию защита CSRF включается глобально для всех view через middleware (эта middleware есть во вновь создаваемом через startproject settings.py), и в своем коде правильно — это отключать ее через декоратор, а не включать. Это дает то преимущество, что нельзя случайно забыть про защиту где-то: отправка форм просто не будет работать и выдаст подробную ошибку с инструкцией, что делать.

[kmike]

Первое предложение было именно такое, как Вы говорите. Оно даже было реализовано (см. github.com/simonw/django-safeform).

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

Если интересно, почитайте дискуссию и это сообщение в ней.

[Rastler]

Спасибо за статью.

[lol2Fast4U]

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

Я и со старой всегда так делал :) А вообще — меньше, меньше форм!

[bosha]

Полезно. Спасибо.

[neithere]

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

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

Кстати, а не перевести ли token как маркер?

[damnerd]

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

Атаку поправил, спасибо за замечание.

[tibalt]

спасибо за перевод, уже совсем скоро бум отмечать релиз)

[loststylus]

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

Радует, что нет глобального требования обновления форм, а то я боялся, что после миграции на новую версию джанго вся работа остановится пока не добавим во все формы токен (а у меня формы не всегда используются по прямому назначению — в некоторых случаев для работы с аяксовыми запросами).

[blackstone]

Как вы считаете — можно-ли положиться на этот механизм и отказаться от каптчи?

[damnerd]

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

[blackstone]

Нет. Я имел ввиду наоборот, что положиться на csrf-защиту и не ставить капчу.
Позволит ли этот механизм от ботов защититься.
.

[damnerd]

Нет. Бот точно так же, открыв страничку на вашем сайте, получит токен и, если он достаточно хорош и поддерживает куки, отправит запрос на сервер с валидным токеном.