Comments 37
упс… так и ajax-отправку тех-же сообщений можно через токены проверять…
пошел крутить токены на ajax_privatemsg
«низко кланяемся барину в ножки» (с) не помню.
пошел крутить токены на ajax_privatemsg
«низко кланяемся барину в ножки» (с) не помню.
Отличный разбор полётов, пошёл исправлять ошибки. Спасибо
Большое спасибо за статью.
UFO just landed and posted this here
дядя, атата, это плохо. труЪ хацкеры сообщают о найденных уязвимостях. они само благородство. а вот всякие скрипт-киддисы наичинают бесноваться, и крушить все подряд(а о проксях и логах они знают??).
кстати были недавно XSS уязвимости на яндексе и рамблере кажись… или мэйле. не помню точно. не могу найти=(
кстати были недавно XSS уязвимости на яндексе и рамблере кажись… или мэйле. не помню точно. не могу найти=(
UFO just landed and posted this here
давайте ссылку — вместе поглядим=) одна голова хорошо. ну а две = хорошо^2
UFO just landed and posted this here
я поражен наплевательским отношением к дырам на сайтах контор.
сайт алькогольной компании довольно крупной(импортер в Россию). я сообщал об уязвимости(SQL Inj + еще одна с раскрытием путей). закрыли спустя год где-то=) на некоторых до сих пор актуальны(Genser например).
про доверие это точно. много каках нынче развелось.
сайт алькогольной компании довольно крупной(импортер в Россию). я сообщал об уязвимости(SQL Inj + еще одна с раскрытием путей). закрыли спустя год где-то=) на некоторых до сих пор актуальны(Genser например).
про доверие это точно. много каках нынче развелось.
UFO just landed and posted this here
UFO just landed and posted this here
Это же одно из основных правил: любые действия, вносящие изменения на сайт, нужно делать через 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.
Безопасный код в Друпале: Подделка межсайтовых запросов