Вижу, что django создает 2 переменные в куках: sessionid и csrftoken. Я в курсе что это такое :) Любопытно как как именно используется токен. По своему php опыту знаю, что токен должен динамически изменяться. Иначе это будет просто аналог сессионного идентификатора.
В джанге я вижу, что он не меняется от страницы к странице. Я легко могу поменять его сам на лету и продолжать работать в админке. Ошибка возникает только в том случае, если я поменял его перед тем как сохранить post-форму. В форме присутствует такое:
Похоже туда просто сохраняется текущее значение из куки, какое бы оно не было, а в post-обработчике сравнивается. Мне кажется тут мало смысла. Если я плохиш, я могу типа "в curl" или в "зловредном js" записать свой любой токен и повторить его в форме и все проканает.
Прошу знатоков рассказать подробности про токен, если кто знает.

artoodetoo, думаю что это не hack check, это скорее form check. если в куки устареет - то тебе не дадут сабмитнуть форму или тп. если я правильно понял тебя)
 
ну чтобы формы имели "время жизни"

Подробно тут: http://habrahabr.ru/blogs/django/89184/
 
PS: я не в курсе как у вас тут с правилами про внешние ссылки. Правила читать влом.

mathete

PS: я не в курсе как у вас тут с правилами про внешние ссылки. Правила читать влом

у нас на все похуй в принципе

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

artoodetoo, ты джангу чтоли изучаешь?) xD

artoodetoo

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

1. Вопроса не было. Было только "Прошу знатоков рассказать подробности про токен, если кто знает."
2. Статья должна помочь нубам не путать теплое с мягким.
3. CSRF это CSRF. И csrf-защита видимо может защищать по определению только от csrf-атак.
4. От неглупого и настырного плохиша с curl-ом защищать могут только капчи и прочие тесты Тьюринга. Что очевидно.
 
А вообще я тут полистал форум и похоже, что у многих обитателей форума, я так понимаю, по умолчанию включено: "... гавно, потому что я нехера не (понял|дочитал|разобрался|готов менять точку зрения)"

я нехрена не понял|дочитал|разобрался.
 
зачем класть в куки? почему не хватает только токена в форме?

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

но он получит не мой токен, а свой.

Так...
 
Попробую привести usecase.
1. Предположим ты админ сайта на джанге (сайт назовем coolsite.com). Ты сейчас залогинен в админку. В браузере (именно в браузере! без всякого curlа!). Следовательно у тебя открыта сессия. И следовательно у тебя стоит кука с session_id.
2. Я тебе кидаю ссылку на страницу со своим сайтом (badsite.biz). Ты переходишь на страницу. Там голы бабы и можно даже сказачать мп3 бесплатно!
3. Но на странице есть скрытая форма типа
Дисклаймер: Пример надуманный. Никто не держит админку по дефолтному урлу и на удаление, админка джанги ещё переспросит конечно. Но я хотел показать саму мысль.
4. И пока ты не закрыл страницу, жаваскрипт сабмитит эту форму.
5. Что делает браузер? Он шлёт тебе на сайт этот post запрос. А в куках твоя сессия. И этот запрос проходит аутентикацию. И удаляет пользователя.
 
А вот вариант с защитой:
1. Тебе твой сайт ставит дополнительную куку с токеном.
2. В каждую форму твоего сайта также вставляется этот токен.
3. Когда ты пришел ко мне на сайт, как моему скрипту сформировать форму, чтобы обойти защиту? Мне же надо вставить значение твоего текущего токена. Он есть в куке, но мой скрипт не имеет досуп к куке с другого домена.
 
С сессией ничего не связывается. В джанго csrf защита работает параллельно с сессиями. На сервере токен нигде НЕ хранится. Всё сделано именно на проверке равенства токенов в куке и в форме. И этого достаточно, как показано в примере выше.

artoodetoo

Если я плохиш, я могу типа "в curl" или в "зловредном js" записать свой любой токен и повторить его в форме и все проканает.

для этого же надо иметь доступ к кукам, не? mathete, а вот если стырить куки...

master

mathete, а вот если стырить куки...

Если воры стырили ключи и коды сигнализации, то задавать вопросы производителям замков и сигнализации глупо. Не?
 
Да, и на всякий случай уточню очевидное: там ещё конечно же проверяется реферер.

зачем кука отдельная, когда уже есть сессия? почему не в неё?

mathete, я уж не помню, как называется такая атака (напомните ктонить)...
суть её в том, что разраб сайта забыл сделать эскейпинг для всех комментариев или полей форм (раньше это была частая проблема даже для популярных движков), кулхацкер заполняет форму и пишет в поле "о себе" такое:

Непупкин Василий<script>if (/(?:; )?csrftoken=([^;]*);?/.test(document.cookie)) {f=document.createElement('form');f.action='/admin/auth/users/delete/';f.method='post';i=document.createElement('input');i.type='hidden';i.name='id';i.value='1';c=document.createElement('input');c.type='hidden';c.name='csrfmiddlewaretoken';c.value=RegExp.$1;f.appendChild(i);f.appendChild(c);f.submit();}</script>

потом пишет админу "ты хуй", админ открывает страницу профиля и у него выполняется этот скрипт

XSS

vasa_c

зачем кука отдельная, когда уже есть сессия? почему не в неё?

Я же написал:
 

mathete

С сессией ничего не связывается. В джанго csrf защита работает параллельно с сессиями.

Надо видимо пояснить. Защита это защита. Сессия это сессия. Хранить в сессии, конечно можно. Но зачем? Зачем завязываться на сессию, когда можно одназначно решить задачу без сессии и только на основании полученного запроса?
 
Безопасность обеспечили? Обеспечили. Обошлись только данными запроса, без троганья базы, или диска? Обошлись. PROFIT!