Comments 37
упс… так и ajax-отправку тех-же сообщений можно через токены проверять…
пошел крутить токены на ajax_privatemsg
«низко кланяемся барину в ножки» (с) не помню.
пошел крутить токены на ajax_privatemsg
«низко кланяемся барину в ножки» (с) не помню.
Отличный разбор полётов, пошёл исправлять ошибки. Спасибо
Большое спасибо за статью.
дядя, атата, это плохо. труЪ хацкеры сообщают о найденных уязвимостях. они само благородство. а вот всякие скрипт-киддисы наичинают бесноваться, и крушить все подряд(а о проксях и логах они знают??).
кстати были недавно XSS уязвимости на яндексе и рамблере кажись… или мэйле. не помню точно. не могу найти=(
кстати были недавно XSS уязвимости на яндексе и рамблере кажись… или мэйле. не помню точно. не могу найти=(
давайте ссылку — вместе поглядим=) одна голова хорошо. ну а две = хорошо^2
я поражен наплевательским отношением к дырам на сайтах контор.
сайт алькогольной компании довольно крупной(импортер в Россию). я сообщал об уязвимости(SQL Inj + еще одна с раскрытием путей). закрыли спустя год где-то=) на некоторых до сих пор актуальны(Genser например).
про доверие это точно. много каках нынче развелось.
сайт алькогольной компании довольно крупной(импортер в Россию). я сообщал об уязвимости(SQL Inj + еще одна с раскрытием путей). закрыли спустя год где-то=) на некоторых до сих пор актуальны(Genser например).
про доверие это точно. много каках нынче развелось.
Это же одно из основных правил: любые действия, вносящие изменения на сайт, нужно делать через POST-запросы. Просто большинство про него забывает почему-то. :)
И не только AJAX, а вообще все запросы, изменяющие данные, надо пересылать POST'ом. Это ж элементарные вещи, основы HTTP можно сказать.
POST без ключика не безопаснее GET
Это не решение. Я могу создать зло-сайт и все приходящие на него будут (к примеру) спамить ваш сайт, если они на нем зарегистрированы, а ваш сайт подверен XSRF.
Дешевое решение — проверять реферер (работает только если у вас нет XSS на сайтек, но думаю в 2009 оставлять XSS уже несерьезно), это защизает от атак со сторонних сайтов.
Вообще XSRF — следствие просчета при проектировании браузеров и HTML.
p.s То что написано — откровенный боян, полгода назад (а может и раньше) вроде как эта уязвимость была вконтактике.
Дешевое решение — проверять реферер (работает только если у вас нет XSS на сайтек, но думаю в 2009 оставлять XSS уже несерьезно), это защизает от атак со сторонних сайтов.
Вообще XSRF — следствие просчета при проектировании браузеров и HTML.
p.s То что написано — откровенный боян, полгода назад (а может и раньше) вроде как эта уязвимость была вконтактике.
эта дырка активно года 2 назад обсуждалось… и страдали ей тогда много крупных приложений…
спасибо, полезно
Не «подделка межсайтовых запросов», а «кузница», если дословно перевести. А если не дословно, то все равно «подделка» и «межсайтовых» вместе не должны быть. Подделываются то обычные запросы, с помощью межсайтовых запросов.
По-моему, это не решение проблемы, а «костыль».
Проблема в архитектуре, это неправильно, что действие выполняется при заходе на определённый url, правильнее, как выше написали, все действия выполнять POST-запросом.
А при выполнени серьёзных действии, особенно при удалении, не лишним будет выводить предупреждение «Вы уверены, что хотите сделать то-то?».
Проблема в архитектуре, это неправильно, что действие выполняется при заходе на определённый url, правильнее, как выше написали, все действия выполнять POST-запросом.
А при выполнени серьёзных действии, особенно при удалении, не лишним будет выводить предупреждение «Вы уверены, что хотите сделать то-то?».
POST подделать не сложнее. С вашей точкой зрения не согласен, она не аргументирована. Token обеспечивает максимальную защиту, вы не подделаете его без доступа к сессии.
Как POST подделать?
Если с GET всё понятно, вставить ссылку или картинку с нужным путём, то форму вам вставить никто не даст…
Если с GET всё понятно, вставить ссылку или картинку с нужным путём, то форму вам вставить никто не даст…
Естественно, используя XSS — засабмитив форму джаваскриптом. У нас в условиях не было что сайт не пробиваем для XSS, тем более, мы не застрахованы от полной доступности HTML формата для всех. Думаю, здесь вы со мной согласитесь. И вот в этих условиях Token все-равно остается непробиваем. Т.к. даже получив сессию кого-то из пользователей, вы не сможете сгенерить верный токен без секретного ключа сайта. Конечно, это все уже немного не в ту степь, ибо если вы получили сессии, то все намного проще и по-другому — можно просто залогиниться под пользователем. Но мы ведь рассматриваем только аспект текущей проблемы с CSRF.
И вот в этих условиях Token все-равно остается непробиваем.Если мы можем вставить Javascript, который отправляет форму, то мы можем вставить и скрипт, который найдёт нужную сылку у пользователя, соответственно в которой уже будет token, и запросить её.
Ну и как Вы сами сказли, имея возможность вставлять лобой html и javascript, мы можем сделать куда более интересные вещи, чем просто запросить определённыйй url.
Поэтому я предлагаю не обсуждать «сферического коня в вакууме», а вернуться к реальному положению дел, где разработчик предусмотрел фильтрацию содержимого, и ничего кроме текста и нескольких стандартных тэгов вставить нельзя, никаких форм, никакого яваскрипта.
В таких условиях как подделать POST-запрос?
Да никак, собственно также никак, как и поломать токен.
Куда-то мы не в ту степь ушли. Я же не говорю, что отправлять POSTом хуже. Я только говорю, что ключ все-равно следует включать, дабы хотя бы попытаться избежать тех маловероятных сферических конев в вакууме. Во всех друпаловских формах ключ включается автоматом. Все действия удаления — требуют подтверждения. Мы сейчас обсуждали мой пример, который на то и пример, чтобы быть очевидным для понимания.
Sign up to leave a comment.
Безопасный код в Друпале: Подделка межсайтовых запросов