ты лучше смысл объясни

я забыл разлогиниться когда проверял это https://www.linux.org.ru/news/opensource/10534550?cid=10544507

в результате наспамил.. (случайно)

"это" - это что это. что именно у тебя работает?

у эхе "ii.dev.14" -- там про курагу пишет кто-то другой (не я) -- зайди и глянь... :-)

я это и имею ввиду что работает..

а принцип какой? мне про курагу неинтересно, ты лучше про принцип объясни.

суть в том что кода web-движёк принимает POST-запрос -- то он обязан проверять CSRF-токен.

если CSRF-токен совпадает -- то POST-запрос должен проходить нормально, если не совпадает -- то POST-запрос должен *откланяться(!) ..

(для каждой web-сессии должен генерироваться свой CSRF-токен .. ну или не для каждой сессии а для каждого пользователя)

а на текущий момент -- web-движёк принимает все подрят запросы (не глядя на CSRF-токен) -- поэтому появляется возможность постить от чужёго имени (нужно лишь заманить чужака на свой хацкерский школосайт :))

вместо CSRF-окена -- можно передать hash-код (тот самый который пароль как бы)... но передавать его нужно обязательно НЕ через cookie, а именно как обычный POST-параметр

а он чё, не через как пост-параметр передаётся? он же вроде просто подставляется как post-код, а кука - вобще для барабану? или нет.

ты по исходникам делал или просто форму глянул?

в исходниках 51t -- до конца так и не смог разобраться.. (хотя сайт про курагу -- я тоже делал на pybottle) -- так что просто по отклику web-баузера пришлось делать сайт про курагу..

исходный код сайта про курагу вот -- https://www.dropbox.com/s/vryr61d2ubv0kr2/51kuraga.tar.xz

но если ещё пол часа повтыкаю на исходники 51t -- то может сразу и патч сделаю... :-)

но мне бы хотелось бы чтоб разработчик сайта 51t -- понял бы суть всего этого инцедента (это было бы более полезно для мирового прогресса в целом!)

> я не верю в безопасность - я верю в добрых людей и открытые двери.

ну сделай ты чтобы "auth" передавался бы НЕ в cookie а в обычном POST-параметре.. во время отправки любого POST-запроса...

если уж не хочешь возиться с CSRF-токенами :-)..

пойми что я тут за 30 минут смастерил говно-на-палочке (сайт про курагу), а умные люди (умее меня, которые) -- наверно могли бы сделать что-то более умное :-) чем рекламу кураги :-) ..

мне бы вот например было бы неприятно если бы вдруг от моего имени якобы-я начал-бы писать матерные сообщение... и быть может я получил бы за это бан :-) .. так что могут и опасное что-нибудь сделать же

да тут по 30000 сообщений иной раз валится.

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

а эту штуку - исправим, наверное. если не учитывать того, что я мало что понял :)


> и быть может я получил бы за это бан :-)

тут не банят. максимум, таймлимиты двигают. тем более, если понятно, что это не ты :) вернули бы номер владельцу :)


> ну сделай ты чтобы "auth" передавался бы НЕ в cookie а в обычном POST-параметре.. во время отправки любого POST-запроса...

мне почему-то казалось, что так оно и есть. я переповерю api-auth


большое спасибо за аудит, за совет, и за курагу, конечно! :)

> большое спасибо за аудит, за совет, и за курагу, конечно! :)

пажалуйста -- когда будешь протеводействовать кураге -- сделай заодно (добавь) и HTTP-хеадер на все странички:

"X-Frame-Options: DENY"

это не касается кураги (курага это CSRF .. а хеадер про который я написал -- это от ClickJacking)..

ну вобщем погугли там, если что будет не понятно... для ClickJacking-случаев -- нужно обладать более изошрённым умом чтобы заэксплуатировать это -- но всё равно не надо злоумышленникам давать и такого шанса тоже :-)