ФорумПрограммированиеPythonDjango → django csrftoken

django csrftoken

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 9:36, спустя 4 минуты 18 секунд

    Обошлись только данными запроса, без троганья базы, или диска? Обошлись. PROFIT!

    вот это кстати разумно если учесть что сессионный адаптер может быть достаточно различным)
    Сапожник без сапог
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 3 декабря 2011 г. 9:49, спустя 12 минут 28 секунд

    Ещё поясню. Не забывайте про архитектуру.
    Csrf - это уровень запроса. И по определению csrf защита должна отрабатывать на этом уровне вне зависмости от того есть сессия, или нет. Ты должен определить корректность запроса до сессии.

    А session - это уже уровень следующий, уровень персонализации.

    И если так смотреть, то просто "некрасиво" переносить csrf-защиту на уровень за сессию.
  • vasa_c

    Сообщения: 3131 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 9:53, спустя 4 минуты 41 секунду

    защита должна отрабатывать на этом уровне вне зависмости от того есть сессия

    Если в джанге сессии не всегда стартуют, то это аргумент. Остальные про персонализацию - нет.
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 10:08, спустя 14 минут 37 секунд

    в источниках истинного знания описание csrf (то что масете описал) и xss (исполнение зловредного скрипта на стороне клиента) часто совмещают.
    от этого есть некоторая путаница в голове. будем считать что джанга реабилитирована.
    ιιlllιlllι унц-унц
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 10:10, спустя 2 минуты 22 секунды

    Кстати, о XSS, недавно в одной из версий джанги был баг с выводом csrf-токена, можно было менять ключ на XSS, дальше думаю понятно… Атака на самого себя не интересно, но баг был, сразу же пофиксили
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 10:13, спустя 2 минуты 59 секунд

    предположим теперь такой расклад: каким-то образом пользователь проебал свой sessionid. обеспечит нам scrftoken в нынешнем виде защиту от поддельных данных? — нет!
    то есть свою функцию он не выполняет сам по себе.
    ιιlllιlllι унц-унц
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 3 декабря 2011 г. 10:16, спустя 3 минуты 9 секунд


    защита должна отрабатывать на этом уровне вне зависмости от того есть сессия

    Если в джанге сессии не всегда стартуют, то это аргумент. Остальные про персонализацию - нет.


    Сессия это всего навсего инструмент разработчика. В зависимости от задачи он может быть нужен, а может быть и нет. Обычный сайт визитка с формой обратной связи. Зачем там сессии?? А вот csrf-защита почемубы и нет?

    И более-менее правильная архитектура это когда:

    [Получаем запрос] -> [Валидируем на уровне запроса] -> [Получаем сессию, если она нужна] -> [Прочее, для чего уже необходима сессия (аутентикация например)] ==> [контроллер (обработка конкретного запроса)]

    А если у тебя:

    [Получаем запрос] -> [Берем сессию, так как мы без неё не можем ничего делать в любом проекте] -> [Делаем ещё чего-то, в том числе что мы можем делать без сессии, но мы в сессию пихаем всё] ==> [контроллер]

    Ты уверен, что всё впорядке? Ничего поменять не хочется?



    предположим теперь такой расклад: каким-то образом пользователь проебал свой sessionid. обеспечит нам scrftoken в нынешнем виде защиту от поддельных данных? — нет!
    то есть свою функцию он не выполняет сам по себе.


    Да, именно! Смесь совершенно ортогональных аспектов всегда ведет и к подобным side эффектам.
  • vasa_c

    Сообщения: 3131 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 10:22, спустя 5 минут 25 секунд

    Ты уверен, что всё впорядке? Ничего поменять не хочется?

    Смотря что подразумевать под сессией и как её брать.
    Сессия это просто связь данных на сервере с конкретным сеансом клиента.
    Если же брать тот же стандартный механизм сессий из пыха, где чтобы что-то из сессии получить нужно тащить файл с диска и десериализовывать куча всякой лажи из-него каждый раз, то да, это иногда излишне.
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 10:33, спустя 10 минут 59 секунд

    теперь возвращаемся к изначальному вопросу. если наш токен не обеспечивает никакой дополнительной защиты, зачем он нужен? к чему эти якобы исправления в безопасности — в старых версиях токен посылался вообще в любой форме, а теперь типа толmко в тех которые ведут на внутренние адреса — да и хуй бы с ним! вся безопасность сводится только к sessionid.
    ιιlllιlllι унц-унц
  • master

    Сообщения: 3244 Репутация: N Группа: Джедаи

    Spritz 3 декабря 2011 г. 10:37, спустя 4 минуты 4 секунды

    И по определению csrf защита должна отрабатывать на этом уровне вне зависмости от того есть сессия, или нет.

    Ну это не аргумент вообще.
    Спустя 42 сек.
    Обычный сайт визитка с формой обратной связи. Зачем там сессии??

    а зачем вообще сессии?
    не всё полезно, что в swap полезло
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 10:39, спустя 2 минуты 25 секунд

    другой пример мнимой заботы о безопасности это автоматическое экранирование всего вывода в шаблонах. (это как раз про XSS).
    от чего тотальное экранирование должно защищать по идее — от того, что в html будет присутствовать "зловредный js". в реальности верстало обнаружит, что экранирование убивает любой вывод html из переменной и будет выключать это экранирование во всех местах где переменная хранит разметку. то есть во всех местах потенциально уязвимых, а там где экранирование НЕнужно, оно будет таки делаться.
    ιιlllιlllι унц-унц
  • master

    Сообщения: 3244 Репутация: N Группа: Джедаи

    Spritz 3 декабря 2011 г. 10:43, спустя 3 минуты 55 секунд

    в реальности верстало обнаружит, что экранирование убивает любой вывод html из переменной и будет выключать это экранирование во всех местах где переменная хранит разметку. то есть во всех местах потенциально уязвимых, а там где экранирование НЕнужно, оно будет таки делаться.

    нет панацеи кроме главного разраба, анально карающего нерадивых
    не всё полезно, что в swap полезло
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 3 декабря 2011 г. 10:45, спустя 2 минуты 2 секунды

    это точно! нельзя расслабляться
    ιιlllιlllι унц-унц
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 3 декабря 2011 г. 10:59, спустя 13 минут 56 секунд


    теперь возвращаемся к изначальному вопросу. если наш токен не обеспечивает никакой дополнительной защиты, зачем он нужен? к чему эти якобы исправления в безопасности — в старых версиях токен посылался вообще в любой форме, а теперь типа толmко в тех которые ведут на внутренние адреса — да и хуй бы с ним! вся безопасность сводится только к sessionid.


    Ничего не понял… Я вроде подробно расписал, как токен ОБЕСПЕЧИВАЕТ защиту. Как вообще это работает в джанго. И в статье вроде тоже какой-то пример там был.
    А позже подробно расписал, что вообще никак не связан механизм сессий с csrf защитой.
    Какая безопасность сводится только к sessionid? Про какой тип атаки говорим?


    И по определению csrf защита должна отрабатывать на этом уровне вне зависмости от того есть сессия, или нет.

    Ну это не аргумент вообще.


    Аргумент к чему? Сross Site Request Forgery. Ключевое слово я выделил. Злоумышленник подделывает запрос. И защита на уровне запроса и речь только про запрос.

    Обычный сайт визитка с формой обратной связи. Зачем там сессии??

    а зачем вообще сессии?


    Нахера мне сессии в проекте, где они не нужны? Что я буду хранить в сессиях сайта визитки? Или не визитки, но где мне не надо персонализировать посетителей?


    А вообще моё мнение, что csrf-защиту должен обеспечивать веб-сервер. Опять же исходя из понятия ЗАПРОС. Например перепереть https://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py на си(или луа), как расширение для nginx дело недолгое. А польза очевидна.
  • master

    Сообщения: 3244 Репутация: N Группа: Джедаи

    Spritz 3 декабря 2011 г. 11:11, спустя 11 минут 33 секунды

    Сross Site Request Forgery. Ключевое слово я выделил. Злоумышленник подделывает запрос. И защита на уровне запроса и речь только про запрос.

    Ну кагбэ да, но эта атака неотделима от сессии. Подразумевается, что пользователь:
    создал сессию -> выполнил действие A -> выполнил действие B -> закончил сессию
    При CSRF имитируется дополнительное действие
    создал сессию -> выполнил действие A -> выполнил действие B -> выполнил фейковое действие C -> закончил сессию

    Какой смысл в CSRF-защите для сайта-визитки с формой обратной связи, которому не нужны сессии? Что изменится, если эту защиту убрать?
    не всё полезно, что в swap полезло

Пожалуйста, авторизуйтесь, чтобы написать комментарий!