Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 134
Спасибо, не слышал о таком простом методе. Странно, что на крупном сайте он есть.
Баге, я имел в виду =)
Это вовсе не баг. Этому хаку подвержены многие сайты.
Угу, а грипп не болезнь, потому что многие подвержены.
хехе ) одну метафору одновременно придумали =)
Вы считаете, что через script tag нужно отменить обращение к другим домейнам?!
ну или через img tag...
В Wiki были описаны методы борьбы с такими атаками. Не обязательно запрещать во всем мире обращение к другим доменам. Достаточно ужесточить контроль за отправкой форм на самом сервисе - http://en.wikipedia.org/wiki/Cross-site_…
Знаю про многие способы, но речь шла о другом. На мой взгляд это не баг, ибо не какой ошибки не было допущено.
Ну тогда это скорее вопрос терминологии. Пускай это не ошибка, но это возможность использоваться сервис в своих интересах для других компаний, в ущерб пользователям сервиса. Не ошибка - но очень неприятно, и кого вы думаете пользователи сделают виноватыми? Думаю не спаммеров...
Согласен полностью. Просто этому виду атак подвержен весь веб, от gmail и до хабра.
Гляньте сюды http://csrf.0x000000.com/csrfdb.php
Гляньте сюды http://csrf.0x000000.com/csrfdb.php
Я считаю, что CSRF - это баг безопасности, и его надо закрывать известными способами: токены, рефереры, капчи.
Гриппом болеет очень много людей, потому мне тоже кажется что это вовсе даже не болезнь, это нормально =)
Я понимаю вашу точку зрения. Безусловно, чисто не там где убирают, а там где не сорят. Но к сожалению в славянской действительности, всегда есть вредные люди которые пытаются заработать на таких вот "не багах", и сервисы с такими уровнями популярности должны позаботиться о защите своих пользователей от них.
Я понимаю вашу точку зрения. Безусловно, чисто не там где убирают, а там где не сорят. Но к сожалению в славянской действительности, всегда есть вредные люди которые пытаются заработать на таких вот "не багах", и сервисы с такими уровнями популярности должны позаботиться о защите своих пользователей от них.
Уже не работает )
Не зря советуют никогда не делать страниц, реагирующих модификацией БД на GET - только на POST.
и это тоже не выход, джаваскриптом ведь можно послать и POST... Но, не все хакеры так хорошо знают джаваскрипт =)
Вообще-то нельзя. :)
Ну т.е. можно только в пределах того же домена :)
точно? Может просто не во всех броузерах? А как же примеры вида:
xmlhttp.open("POST", "http://api.google.com/search/beta2",true);
?
xmlhttp.open("POST", "http://api.google.com/search/beta2",true);
?
Нельзя нигде. :) Хотя по идее в некоторых браузерах существуют хитрые хаки с ифреймами и прочим, чтобы это обойти. Можешь погуглить на тему cross-domain XMLHttpRequest.
http://premshree.livejournal.com/66129.h…
"You can do cross-domain requests in MSIE; however, this involves changing its default security settings" - хоть так =)
И там еще с помощью мод-реврайта мутки какие-то.
"You can do cross-domain requests in MSIE; however, this involves changing its default security settings" - хоть так =)
И там еще с помощью мод-реврайта мутки какие-то.
не думаю, что у многих пользователей IE стоят недефолтные настройки секьюрити :)
там был еще метод с модреврайтом...
Вы, как раз, все очень хорошо понимаете, это я увлекся копанием вглубь вместо решений, что лежат на поверхности. =)
Когда происходит тупой пост формы, в случае, подобном описанному в посте, юзер тут же увидит отредактированную страничку и исправит нужное. Здесь же красота заключается в том, что юзер заходит на страницу сайта и даже не подозревает, что у него что-то поменялось в совсем другом месте.
ИМХО это было логично с самого начала.
Если очень хочется отослать пост, то кто мешает создать невидимую пост форму и сделать сабмит из нее с помощью JavaScript ? Никто и это применяется на практике втех местах, где Ajax не пройдет.
> и это тоже не выход, джаваскриптом ведь можно послать и POST
Все таки это выход. Простой img — это одно дело, работает почти везде, мало кто отключает, считается безопасным. А javascript — это уже другое дело, с ним можно гораздо более серъезные вещи сделать, не зря же есть отдельные галочки в настройках и расширения (тот же noscript), которые или отключают или серъезно урезают его функциональность.
Вообще не стоит принимать формы на изменение базы через GET и тем более их так посылать. Чего стоит только добавление такой ссылки в закладки.
Все таки это выход. Простой img — это одно дело, работает почти везде, мало кто отключает, считается безопасным. А javascript — это уже другое дело, с ним можно гораздо более серъезные вещи сделать, не зря же есть отдельные галочки в настройках и расширения (тот же noscript), которые или отключают или серъезно урезают его функциональность.
Вообще не стоит принимать формы на изменение базы через GET и тем более их так посылать. Чего стоит только добавление такой ссылки в закладки.
Если кратко, то GET передает параметры в самом адресе:
httр://example.com/script.cgi?donate=20;currency=rub;target=greenpeace
а POST в отдельном блоке запроса (упрощено для наглядности):
Если тебе дали GET адрес или он оказался в избранном, то открытие его автоматом пожертвует 20 рублей гринпису, а POST-параметры в избранном не окажутся, так просто передать другу ссылку тоже нельзя.
Кроме того, обновление страницы после GET запроса проходит без вопросов (т.е. каждый раз будешь жертвовать по 20р), а перед тем как переотправить POST-запрос браузер спросит твоего разрешения.
Итого: GET предназначен для операций, которые не производят изменений (поиск, фильтр, чтение и т.п.), а для удаления, редактирования, добавления и т.п. — POST.
Всегда пожалуйста :)
httр://example.com/script.cgi?donate=20;currency=rub;target=greenpeace
а POST в отдельном блоке запроса (упрощено для наглядности):
httр://example.com/script.cgi
Params:
donate=20
currency=rub
target=greenpeace
Если тебе дали GET адрес или он оказался в избранном, то открытие его автоматом пожертвует 20 рублей гринпису, а POST-параметры в избранном не окажутся, так просто передать другу ссылку тоже нельзя.
Кроме того, обновление страницы после GET запроса проходит без вопросов (т.е. каждый раз будешь жертвовать по 20р), а перед тем как переотправить POST-запрос браузер спросит твоего разрешения.
Итого: GET предназначен для операций, которые не производят изменений (поиск, фильтр, чтение и т.п.), а для удаления, редактирования, добавления и т.п. — POST.
Всегда пожалуйста :)
Хм. :)
> Не существует GET-адресов, ровно как и POST-параметров.
Да, видимо зря я свернул "адрес с параметрами как в HTTP запросе типа GET" и "блок параметров в HTTP запросе типа POST".
> разница семантическая и у этих запросов разное назначение.
Синтаксическое различие между GET и POST покажет расширение Header Spy. Там все просто :) Семантическую разницу конечно не оспариваю.
> Это зависит от поведения клиента, а в браузерах меняется в настройках
Как выключить в FFPOST-вопрос вопрос о том, надо ли переотправлять на сервер HTTP запрос типа POST или нет, я не нашел ни в настройках ни в about:config :) А гугл вывел на баг #160144. Интересное чтение :)
> Не существует GET-адресов, ровно как и POST-параметров.
Да, видимо зря я свернул "адрес с параметрами как в HTTP запросе типа GET" и "блок параметров в HTTP запросе типа POST".
> разница семантическая и у этих запросов разное назначение.
Синтаксическое различие между GET и POST покажет расширение Header Spy. Там все просто :) Семантическую разницу конечно не оспариваю.
> Это зависит от поведения клиента, а в браузерах меняется в настройках
Как выключить в FF
Семантическая разница состоит в том, что GET предназначен для получения (getting) информации, а POST — для отправки (posting).
По GET'у не должны совершаться какие-то действия, ведущие к изменению состояния системы.
POST не должен использоваться для действий, не ведущих к изменению состояния системы.
По GET'у не должны совершаться какие-то действия, ведущие к изменению состояния системы.
POST не должен использоваться для действий, не ведущих к изменению состояния системы.
это вообще-то не советуют. для этого метод POST и придумали — для запросов, приводящих к изменениям в БД.
Грамотно продумано. А какие могут быть применены санкции к сайтам, которые "рекламируются" подобным образом?
если вы в этот же момент авторизованы на вконтакте...
Не обязательно. Нужно просто там быть зарегистрированным. Авторизация произойдёт автоматически при загрузке "картинки".
У меня так не получилось. Нужны куки, нужны.
Ну да. Куки появляются после авторизации и хранятся целый год в браузере. Но конкретно в момент загрузки картинки не обязательно быть авторизованным.
Как это — куки есть, а не авторизован? Чего я недопонял? %(
В куках хранятся параметры для автоматической авторизации при следующем заходе на сайт. Но если вы на сайте сейчас не находитесь, то как можно говорить, что вы сейчас авторизованы? Вы зарегистрированы. :)
Чуть ниже приведу и цитату из википедии, в которой чуть иначе сформулировано это.
Чуть ниже приведу и цитату из википедии, в которой чуть иначе сформулировано это.
просто все перепутались в терминах "авторизован", и "зарегистрирован" только и всего, мы все об одном говорим по-моему. =)
Авторизован, в данном случае — это состояние, при котором при следующем входе на сайт не придётся вводить логин и пароль. То есть, маркер авторизации хранится в куках. Чуть ниже это уже сказано иначе.
Похоже, наша дискуссия упирается в разное понимание терминологии.
Похоже, наша дискуссия упирается в разное понимание терминологии.
более того, они сохраняют в куки md5 хэш пароля=)
Ну я имел ввиду не "открытое окно с vkontakte.ru" а именно "авторизованное состояние пользователя". Если я на вконтакте нажму "Выход", то стану неавторизованым, и джаваскрипт не отработает. Просто потому что сервис меня не узнает. Я же "вышел".
Ну хорошо, в одном браузере у вас авторизованное состояние — вы прямо сейчас находитесь на сайте, у вас установлены куки. Открываете другой браузер, без кук, заходите на сайт неавторизованным, сервис вас не узнаёт. Так авторизованными вы сейчас являетесь или нет? :)
Из википедии: "под понятием авторизированный пользователь подразумевается посетитель сайта, который ранее проходил процесс регистрации и на данный момент зашел под своей учетной записью".
Из википедии: "под понятием авторизированный пользователь подразумевается посетитель сайта, который ранее проходил процесс регистрации и на данный момент зашел под своей учетной записью".
Если в другом браузере нет куки, значит в нём вы не авторизованы. Авторизация куками привязана к браузеру. Там выше ссылка пробегала, почитайте. Вы, похоже, неверно понимаете термин «авторизация».
все верно, но с точки зрения сервиса и csrf я буду неавторизованным пользователем для системы в другом броузере, ведь так? Смотря что брать за точку отсчета =) Я же говорю, просто термины по разному понимаем, только и всего. Вряд ли у нас есть тут какие-то расхождения технического плана.
все правильно.. расслабся
Понял. Ушёл пить яд. :)))
:) я говорю зря напрягаешься - кому надо сразу все поняли. а ты тут докторскую пишешь
О... Вы не видели мои посты, когда я напрягаюсь. А здесь было всего лишь желание разобраться с формулировками.
Тем временем яд начинал медленно действовать. Автор, сидя у окна и тихо отбивая пальцами по клавиатуре ноутбука, вспоминал радостные минуты своего детства. За окном плыли облака, словно маня куда-то вдаль. На губах чувствовался сладкий и успокаивающий вкус жидкости "на все случаи жизни"...
Тем временем яд начинал медленно действовать. Автор, сидя у окна и тихо отбивая пальцами по клавиатуре ноутбука, вспоминал радостные минуты своего детства. За окном плыли облака, словно маня куда-то вдаль. На губах чувствовался сладкий и успокаивающий вкус жидкости "на все случаи жизни"...
Ладно, умолкаю, а то уже пошли в ход кулаки, карму дёргают... Печально.
Если есть куки, это и называется "авторизован" (точнее говоря, аутентифицирован).
Каким образом произойдёт авторизация?
Сервер получит из cookie хеш пароля и сверит с тем, что в базе. Это я и понимаю под авторизацией. Если пароль подойдёт - создастся сессия. Пока сессия жива (хранится на сервере обычно 30 мин. от последней загрузки) - вы авторизованы.
Это детали реализации, которые мы наверняка не знаем. Можно с той же степенью уверенности сказать, что пароль у них проверяется каждый раз, поэтому-де аутентификация происходит с каждым запросом.
С точки зрения user experience (что собственно и подразумевалось) аутентифицируемся ровно один раз, потом работают персистент-куки.
С точки зрения user experience (что собственно и подразумевалось) аутентифицируемся ровно один раз, потом работают персистент-куки.
Реферрер проверять нужно. По сути-то, самые азы обработки форм.
Я им это первое посоветовал, они отказались сославшись на то, что в письмах пользователями часто были прямые линки (читай: GET запрос изниоткуда) на добавление друзей и пр. Но это конечно просто отмазка, можно было придумать какие-то токены случайные.
это не совсем правильно. многие фаерволы режут реферер (или ставят туда что-то типа ** blocked by outpost **), хотя отсеканием варианта "в реферере валидный урл и он не наш" проблема, в целом, для большинства пользователей решается.
но правильнее для каждой формы генерировать уникальное одноразовое значение, класть его в сессию и в хидден-поле, и сравнивать. (можно и к ссылкам дописывать, если очень хочется GET, но вообще конечно такое надо делать POSTом).
но правильнее для каждой формы генерировать уникальное одноразовое значение, класть его в сессию и в хидден-поле, и сравнивать. (можно и к ссылкам дописывать, если очень хочется GET, но вообще конечно такое надо делать POSTом).
Рефереры иногда режутся файерволами или "шифруются". Но в принципе 90% пользователей это бы спасло. Плюс можно пустой реферер разрешить если в ифрейме реферер ставится.
Проверка основанная на referer не правильна по своей сути, т.к. некоторые пользователи режут передачу referer из параноидальных соображений.
Реферрер можно подделать, хотя его, конечно, тоже нужно проверять. Просто одна проверка реферрера - не панацея.
Ну да, зато "одноклассники.ру" - шедевр программисткого (жуткое слово) гения))
Небольшие (а это небольшой) баги разумеется будут встречаться на таких крупных сайтах. Главное чтобы их исправляли (что, судя по всему, и сделали - у меня в Opera вышеописанный баг уже не работает).
Небольшие (а это небольшой) баги разумеется будут встречаться на таких крупных сайтах. Главное чтобы их исправляли (что, судя по всему, и сделали - у меня в Opera вышеописанный баг уже не работает).
если можно изменить сайт, то наверное можно и другие данные поменять. например пол http://vkontakte.ru/profileEdit.php?subm=1&sex=1
или подпортить что-нить
или подпортить что-нить
Кстати, все другие поля в "контактной информации" - телефон, ася и т.д. обнулятся.
Саппортерам, которые первым делом отвечают "это не бага", нужно давать хорошего, увесистого пинка.
Интересное решение ) Прям вирус :)
давно уже известно. сам всем в аську кидал tinyurl, который перенаправлялся на мегастраницу, меняющее фио на тупой лошара xD
Странно, в Сафари работает, в Опере нет.
Вчера только с этой "багой" игрался :) Если в iframe (или даже редиректом) с какого-нибуть хостинга открыть что-то типа http://vkontakte.ru/settings.php?act=cha…, то пишет Security Breach or Incorrect Firewall. А если такую же страницу открыть с жесткого диска или вбить в адресную строку, то работает. Значит, что-то они все-таки позакрывали?
Вчера только с этой "багой" игрался :) Если в iframe (или даже редиректом) с какого-нибуть хостинга открыть что-то типа http://vkontakte.ru/settings.php?act=cha…, то пишет Security Breach or Incorrect Firewall. А если такую же страницу открыть с жесткого диска или вбить в адресную строку, то работает. Значит, что-то они все-таки позакрывали?
Ну да, после вышеупомянутых осенних игр стали проверять referrer. Видимо, при запросе картинки referrer не ставится. Если так - сейчас пойдет новая волна "приколов"
Проверяют реферер. C жесткого диска и из адресной строки реферер пустой. С хостинга - какой-то, несовпадающий с vkontakte.ru. Пользователей с пустым реферером отбрасывать нельзя, т.к. некоторые файрволы и прокси их режут.
в IE 6 версии не рабит. Пока только в Mozilla Firefox 2.0.0.12 пашет и в браузерах с движком gecko от фаерфокса3 (тестили на линухе).
Приемы безопасного программирования веб-приложений на PHP c citforum'a
http://citforum.ru/internet/securities/phpsecure.shtml
http://citforum.ru/internet/securities/phpsecure.shtml
Похожая дырка по осени кучу народа огорчила ;-) У них ник менялся на что вроде "Павел Дуров, почини контакт", а в статусе ссылка на сайт с подобным кодом, а в друзьях появлялся автор кода.
Вроде раньше вконтакте не обрабатывал запросы с внешним реффером, или это только при промотре анкет?
ЕЩе был случай, когда спамили во мнения ссылкой на сайт, при переходе на которую ваше имя и фамилия вконтакте менялось на "ЙА КРЕВЕДКО". На моих глазах так поменялось имя у друга :)
к счастью этот баг закрыли.
к счастью этот баг закрыли.
Да сколько можно такие вещи в $_GET передавать? Или "они" лопают все что придет из $_POST и $_GET...
Всё что в form - только $_POST иначе СSRF.
И вообще опять же скорее всего с "нормальным" MVC как обычно проблемы.
А если серьезно то безобидная атака... скорее детская
Кстати хочу спросить тех кто мне минусов наставили за "раскрутку" сайтов.... это вы так сайты "раскручиваете"!?
Потом обижаетесь... что вас за "живое" ловят...
Всё что в form - только $_POST иначе СSRF.
И вообще опять же скорее всего с "нормальным" MVC как обычно проблемы.
А если серьезно то безобидная атака... скорее детская
Кстати хочу спросить тех кто мне минусов наставили за "раскрутку" сайтов.... это вы так сайты "раскручиваете"!?
Потом обижаетесь... что вас за "живое" ловят...
У вконтакта очень феерический саппорт, у них похоже там инструкция висит:
1. Сказать, что это не баг
2. Настучать по рукам.
1. Сказать, что это не баг
2. Настучать по рукам.
img src=http://vkontakte.ru/profileEdit.php?page=contacts&subm=1&website=http://tvoydohod.com
выезжает на правый край.
ггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггг
выезжает на правый край.
ггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггггг
Для защиты от таких "приколов" достаточно в каждой форме (у себя на сайте) передавать какой-то уникальный для данного кользователя ключ, а при проверке данных формы проверять соответствие ключей. Все. И тогда можно хоть все формы по GET обрабатывать, не опасаясь последствий
Интересно, несколько месяцев назад я превращал неосторожных юзеров Вконтакте в Ya Krivedko, и тогда они законопатили дырку в течение буквально нескольких часов одноразовым ключиком формы. А теперь, кажись, убрали обратно, молодцы какие.
очень интересно. спасибо большое!
клево! ;)
клево! ;)
Однако, какой-то хэш там у формы есть (или только стал?)
Если он не проверяется, то печально...
Если он не проверяется, то печально...
Сработал ещё и как медиа вирус. Потому что в контакте уже похоже вылечились от этого, а на tvoydohod.com я благодаря этому посту зашёл. ;) Хотя я уже поиск по инету сделал и выяснил, что они лохотронщики.
Можно ли и как захватить куку с внешнего сайта изнутри iframe и отдать на вредный сервер?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSRF на vkontakte.ru