Comments 67
в представленном скрине кармы голосов 60, а на данный момент у вас 8 голосов. Как?
На самом деле для кросс-доменных запросов очень удобно использовать расширения в Google Chrome, так как там они разрешены.
Я буду просить об этом жертву? Поставьте, мол, такое то расширение, а то я не могу вас атаковать!
ой, немного не в тему получился комментарий, не до конца врубился в начале )
Но все равно кому то пригодится )
Но все равно кому то пригодится )
При голосовании всяко передаются кукисы с идентификатором сессии, заголовок X-Requested-With можно передать и в форме, и еще вы забыли сказать, что те пользователи, от имени которых идет скрытное голосование, должны быть авторизованы на хабре.
Кукисы передаются. Люблю Flash!
Я не понял, почему у вас 404 ошибка получалась. Видимо, просто не все POST параметры передавали. Тут нет никакой разницы Ajax это запрос или нет.
kafeman, беги за инвайтом
А на referer проверки тож не идёт? Зря помом, зря. А то, как тут говорили, можно подделать с помощью всяких аддонов. referer конечно тоже подделать можно, но всё ж…
Теперь это пост любви к django.middleware.csrf.CsrfViewMiddleware
Мне интересно, чем думают люди, которые так легко, одним движением руки, разрешают кроссдоменные запросы с любого сервера? Что у них в голове? или это орудует то самое новое поколение кодеров, которое привыкло бездумно копипастить файлы и куски кода из интернета? Впрочем, я никогда и не считал флешеров настоящими программистами, мышкой квадратики перетаскивать-то много ума не надо.
На самом деле разработчики Хабра мне показались людьми хорошими. А разрешение они это дали, будете смеяться, для рекламы :-). (И ещё для habrastorage).
А многие Flash-программисты пишут всё в коде, без «квадратиков». Точно знаю, что так пишут программисты ВКонтакте.
А многие Flash-программисты пишут всё в коде, без «квадратиков». Точно знаю, что так пишут программисты ВКонтакте.
вы слышали о таком понятии, как API на сайтах?
уязвимость закрывать надо было, а не кросс-домен перекрывать. сам по себе последний безопасен.
уязвимость закрывать надо было, а не кросс-домен перекрывать. сам по себе последний безопасен.
При чем тут уязвимость? Что вы за бред пишете? Если вы размещаете на своем сайте crossdomain.xml с allow-access-from = "*", вы открываете всем хакерам доступ к своему сайту. Это не уязвимость, так как это поведение документировано Adobe. Это халатность и безответственность скорее.
Есть еще firebug и dragonfly
разработчики хабра надеятся на отсутствие XSS? почему нельзя было встроить защиту от CSRF, а не перекрывать кроссдомен? если они потом захотят API сделать, да забудут про происшествие, и опять включат кросс-домен?
и кстати, я правильно понимаю, что все LiveStreet более старших версий уязвимы?
API у ХабраХабра, кстати, есть. Документация.
Забавно, заготовка этой же статьи про csrf на Хабре лежит локально)
А если бы копали дальше — нашли бы кое что с SQL, там уже интереснее :) все времени докопать нет.
А если бы копали дальше — нашли бы кое что с SQL, там уже интереснее :) все времени докопать нет.
Насколько я понимаю — нужно было всего-лишь послать правильный запрос? Тогда это также можно сделать модифицировав трафик с помощью HTTP дебаггера Fiddler2, или-же используя например IEWatch для ручного построения нужного запроса.
авторизационная cookie нужна еще, чтобы проголосовать от имени человека
Ну а при чем здесь авторизация? И в первом и во втором случае вы авторизуетесь как обычно — через броузер. Вот дальше нужно послать специальный запрос, содержащий кроме куки, еще и X-Requested-With? Я правильно понимаю?
Если правильно — то добавить этот хедер можно с помощью Fiddler2 перехватив и модифицировав трафик вашего броузера. Также этот запрос можно построить с помощью билдера запросов в броузере (если таковой имеется в броузере).
Если правильно — то добавить этот хедер можно с помощью Fiddler2 перехватив и модифицировав трафик вашего броузера. Также этот запрос можно построить с помощью билдера запросов в броузере (если таковой имеется в броузере).
И да и нет. Вы правильно поняли, что нужно составить правильный запрос, но не правильно поняли кто его должен послать. Посылать его должна жертва, а нашедший уязвимость. В этом и состояла вся задача, решить которую удалось с помощью Flash.
Читайте внимательно: Уязвимость в том, что другой пользователь Хабра, открыв популярное приложение на vkontakte, автоматом проголосовал злоумышленнику в Карму…
… запрос нужно выполнять с браузера жертвы… (авторизованного и не голосовавшего хабраюзера) — вот что пропущено вами и всеми подобными комментаторами
Все слишком сложно. Вы не пробовали консоль хрома? Прекрасно работает на любом домене
Возможно, нетерпеливый читатель уже решил, что я нашёл элементарную, очевидную каждому дыру? Как бы ни так! Все мои попытки подделать запрос приводили к одному и тому же:
Брр, мож я чего не понял. Запрос, заголовки XML request, кроссдомены… А разве дырка не тупо в том что на серверной стороне не сверяется сессия пользователя? И никакие ид юзера передавать в скрипт не нужно, хост должен узнать пользователя и так — если тот «законопослушный» и дал верный SID.
Неплохо так автору подняли карму ))
> Если у вас нет сайта, то думая договариваемся за Profit с владельцем крупного приложения ВКонтакте и заливаем код к нему. Охват 50% пользователей гарантирован.
50% пользователей этого приложения будут залогинены на хабре?
50% пользователей этого приложения будут залогинены на хабре?
Я надеюсь получить мои куки с хабра и послать их куда-то никакое флеш приложение не может?
Получить — нет, послать — только на страницу в домене habrahabr.ru
Sign up to leave a comment.
CSRF уязвимости на примере ХабраХабра