Comments 193
Все молчат, никто не высовывается, а то Егор и на наши ресурсы придет. Хабр он видимо любит, раз в списке его нет )
Boo!

p.s. а если серьезно на хабре вроде тоже надежда возложена на requested with xmlhttprequest которая обходится трюком с флешом. мне так яхуда катз сказал — они из за этого токен даже в xhr пихают. хотя если реферер везде проверяется то проблем нет.
Интересно, а насколько быстро Вам удастся «поломать» проект на Битриксе?
на хабре вроде тоже надежда возложена на requested with xmlhttprequest которая обходится трюком с флешом

Уже сложно :-) Но есть еще один способ, я писал им, но они не исправили…
Честно говоря сарказм не до конца понятен.
Мало знать что это такое, надо уметь прилагать усилия с нужным вектором и искать знаниям применение.
Список ресурсов соразмерного размера, не особо мелкие, и если их разработчики о csrf «не знали», то почему бы не отдать 500 баксов тому кто знает и умеет этим пользоваться?
А если учесть, что многие предлагают аудит безопасности гораздо дороже и с гораздо меньшим «портфолио», то ценник вообще заоблачным не кажется.
Как говорится, «ноты знают все, но не все могут написать симфонию»
Прям как неуловимый Джо )
Про он CSRF узнал, жду выпуск с sql include.
Егор может внедрять через XSS картинку «Please read and donate 500$ to Egor Homyakov...»? Достаточно действенно )
Даже пытаться не будут, вдруг его чего не устроит, а это страшно )))
я думал ты меня троллил каким то изощренным самурайским способом =)
Да я знаю)) Но видимо ему все мало зарплаты…
Я не удивлюсь если в метро в переходе его увижу с шапкой в которую ему кидают на википедию.
я говорил про себя) Где — секрет.
а то мои проекты уже начали ломать конкурирующие группировки
>самый главный баг с переводом денег через Moneybookers он предварительно зарепортил разработчикам и дождался, пока те закроют уязвимость
Нет бы анонимно рассказать о нем на множестве ресурсов, а потом наблюдать за происходящим со стороны.
зря вы так. Будет у вас сервис работающий с платежами, будет не до смеха.
meanwhile
>PS: Well, everybody needs money. People advise me to try security audit/consulting either — if you are interested, get in touch with me, prices start from $1000/site.
>$1000
> showcase: GET to bitbucket.org/USERNAME/follow
description: Following. Well, making score github:bitbucket — 1:1

Егор слишком преувеличил «вес» вреда сайту Bickbucket сравнив это с тем что случилось на github.
Я считаю что будучи авторизованным на Bitbucket вполне нормально по прямой ссылке фолловить спокойно.
А вот у гитхаба был косяк серьезнее. Ну нет тут Bitbucket/Github 1:1 гитхаб допустил больший косяк.
Напомню что у Github он подставил свой ключ и коммитил в репозиторий rails.
Для таких сервисов как Github и Bitbucket репозитории это их хлеб и в том случае он в сердце ранил Github а сейчас лишь подписка и то при авторизации.
bitbucket.org/homakov
Followers (75)
час назад было ноль. я им вообще не пользовался.
хотя очевидно не 1-1. но хочется к гитхабу подлизаться =) что они бяки какие.
Ну так видно же что кто-то заинтересован в этих цифрах… слишком заметно.
Нет тут 1:1 и слишком там кричат эти цифры.
Будь хорошим мальчиком и убери упоминание гитхаба там и 1:1
а то разработчики Bitbucket тебя заспунят!!!
www.youtube.com/watch?v=dYBjVTMUQY0

Подлизываться лучше лестью или хорошими делами в отношении гитхаба а не засиранием битбакета.
Нифига не нормально, расширение какое-нибудь может ссылки префетчить, например. Выполнение действий по GET — это явный косяк. Правильно тут при нажатии на ссылку слать ajax POST-запрос, а для людей без аякса предусмотреть страничку с формой подтверждения.
Это я изначально неправильно понял. А потом зайдя на Bitbucket обнаружил что я оказывается подписался на homakov))
Все равно косяк у Bitbucket не сопоставим с тем что Егор проделал на Github.
Извините что вмешиваюсь, а чем технологически выполение по GET отличается от ajax+POST? Я вот не понимаю в чём разница то.
Спасибо, смешно.

Но вы мне лучше расскажите почему если я могу сделать document.write() я не могу сделать ajax-POST запрос? Мне совесть не позволит или в чем дело?
Если можете сделать document.write прямо на сайте, то это уже XSS, а не CSRF — соответственно и меры по защите от CSRF не действуют.
По GET на сайт человек может попасть извне, с другого сайта (по ссылке). При этом csrf-токен в ссылку добавить нельзя (другой сайт этот токен никак не получит, тем более что токен может обновляться на каждый запрос). Поэтому при GET-запросах возможности защититься от CSRF нет => GET-запросы не должны выполнять действия, менеяющие данные, они должны просто отдавать информацию. Если этому правилу следовать, то CSRF-атаки через GET-запросы (== человек просто переходит по ссылке) будут безобидными.

POST же человек в большинстве случаев (не учитывая api и тд, где обычно предусматриваются другие средства защиты) выполняет с того же сайта. Перед этим запрашивается страница через GET и у сервера есть возможность передать csrf-токен в куке, который потом при POST-запросе можно проверить.

Браузеры работают так, что js с чужого домена прочесть не свою куку не может, поэтому правильный POST-запрос сгенерировать на js не получится. С помощью html формы — тем более (токену с чужого сервера там взяться неоткуда).
Ок, чуть подробнее: вы тут защитились от CSRF через GET, но при этом закрыли возможность ссылаться на ваш сайт (т.к. любая ссылка без токена будет вызывать 403, а стороннему сайту ваш токен взять неоткуда); кроме того, усложнили жизнь пользователям (им при первом вводе адреса в строку браузера тоже нужно будет откуда-то брать этот токен).

Это и имеется в виду в фразе «при GET-запросах возможности защититься от CSRF нет».
Хорошо, а если я использую POST-запрос, то это что, откроет возможность ссылаться с других сайтов?

Мне как-то всегда казалось, что задачи защиты от CSRF и возможность ссылки с других сайтов являются взаимоисключающими, независимо от используемого метода.
Да, вы правы.

Я писал все это не в общем случае, а в частном — в контексте фреймворка, продоставляющий защиту от csrf по умолчанию. Профессиональная деформация. Это как-то затерялось у меня, даже сам забыл — ответ на замечание про битбакет (правильный в контексте), потом опять вопрос-ответ и тд. То, что я пишу, не верно в общем случае, но вполне верно в конкретном про битбакет.

В чем тут суть — защита работает, если ее нужно отключать, а не включать. Для POST ее включать по умолчанию можно, а для GET — очень непрактично. Поэтому, если следовать принципу «защита должна быть по умолчанию», защищаться от CSRF через GET не получается.
Мне кажется, запрещать действия по GET-запросам просто из-за сложностей с определением необходимости защиты — неправильно, ведь дать написать простую ссылку гораздо проще, чем скрипт, отправляющий POST-запрос. Собственно, это и есть основная проблема подобных «автоматических» защит.

Лично мне кажется разумнее другой вариант. Если использовать MVC-разбиение, то все страницы сайта поделятся на относящиеся к виду (и при обращении к ним не выполняется никаких действий) и относящиеся к контроллеру (выполняющие действия, но не выдающие пользователю ничего кроме редиректа). В таком случае необходимо и достаточно защитить только вторую половину адресов.
Основное отличие — у POST запроса есть тело, которое в URL не передаётся. Если сервер не контролирует тип запроса (и способ передачи параметров), то злоумышленник может любым способом передать вам ссылку, перейдя по которой вы совершите нужное ему действие.
Егор, а вот они говорят что являются № 1 в аудите безопасности. Можешь даказать обратное на их примере? :)
UFO landed and left these words here
Я по логам xss сканера могу несколько сотен сайтов с такими же проблемами назвать. Но делать это не буду :)
Да, слышал, что этому подвержены enterprise java beans с конфигурацией через байт-код в БД.
Они обе опасны в первую очередь для пользователя. Расскажите, есть ли что-то такое, чего нельзя сделать через XSS, но можно сделать через CSRF?

Hint: если у вас есть XSS, то у вас есть доступ к Cookie, токенам и т.п. — т.е. вы можете обойти любую защиту от CSRF. Обратное неверно.
> и в 3 раза реже встречается, чем CSRF
бред. приглашаю тестить алексу 1000. XSS фильтрация настолько распиарена что только полный мудак про неё может забыть, извиняюсь за выражение(та жехрень с sql inject). Чего не скажешь про CSRF который до сих пор чертовски распространен.
Цифры использовались фигурально, чтобы не использовать дважды слово «намного». Подставьте вместо цифр over 9000 или на 146% если вам так будет понятнее.

Теперь по пунктам:
1. XSS позволяет нанести намного больший вред
2. XSS встречается намного реже
3. XSS встречается не настолько редко, как вы думаете. За последний год XSS были найдены практически в каждом крупном ресурсе

А CSRF есть в огромных количествах практически в каждом ресурсе и их даже искать почти не надо. Это не значит, что их не надо искать и что к ним не надо привлекать внимание.

Но это значит, что относиться к XSS как к «этой старой скучной атаке» не стоит. CSRF в крупном ресурсе может найти любой школьник. XSS — далеко не любой. XSS меньше, они опаснее, искать их интереснее. Часто нужно именно обходить защиту, а не банально радоваться тому, что разработчик забыл ее сделать.

Кроме того, я бы не утверждал с такой уверенностью, что XSS старше CSRF. Скорее наоборот. Сама возможность проводить CSRF атаки появилась с созданием HTTP протокола. XSS — только после появления JS.

Первые рассуждения на тему CSRF (без употребления этого названия правда) датируются 1988 годом. У вас есть подобные данные про XSS? Сравним, подумаем что из них «старая скучная атака»
Но это значит, что относиться к XSS как к «этой старой скучной атаке» не стоит. CSRF в крупном ресурсе может найти любой школьник. XSS — далеко не любой. XSS меньше, они опаснее, искать их интереснее. Часто нужно именно обходить защиту, а не банально радоваться тому, что разработчик забыл ее сделать.

ну что за ересь а?! уэлл, в рельсах фильтрация safe_buffer стоит по умолчанию. берите тестите хоть самые укромные места. и так на всех нормальных ресурсах — фильтрация не выборочная а по умолчанию на весь аутпут юзерского инпута. (опять таки, если разраб не мудак)

поэтому можно даже так перефразировать ваше заявление
много пользователей имеют пароль 123123 и qweqwe и это намного опасней чем всякие взломы. Да, встречается редко, но это же так прикольно тратить время с попыткой угадать пароль.

Атаки совершенно РАЗНЫЕ. защититься от XSS в разы проще чем от CSRF на практике. Ну зачем путать и делать ложные аналогии?
1. А теперь задача со звездочкой.

Пользователь форматирует текст (комментарии, email с интересным форматированием). Вы будете фильтровать весь пользовательский ввод? Хорошо. Тогда вам придется изобрести свой велосипед или пользоваться готовым (BB code). И превращать их в HTML. И вот в этом месте могут (и возникают, и даже в крупных ресурсах) XSS уязвимости.

2. Причем здесь пользователи с простыми паролями? Они встречаются очень часто и это действительно заметно опаснее (вы правда примеры плохие привели — эти не так часто встречаются). Обход фильтра XSS это не подбор пароля. Это самый что ни на есть взлом. Подумать как бы решал эту задачу разработчик и где он мог допустить ошибку.

3. Атаки разные. Защититься одинаково просто. Я не путаю. Вы заявили, что «XSS — это старо и скучно», подразумевая «по сравнению с CSRF». Т.е. аналогии начали проводить все-таки вы. Тем не менее, CSRF скорее всего старее и искать их в разы проще.

Возможно у нас разные точки зрения на то, что скучно. Мне скучно искать банальные CSRF. А они в большинстве своем очень банальные. А банальных XSS практически нет. Если вы так не думаете, то вам должно быть еще веселее пользоваться сканерами уязвимостей и наборами готовых exploit'ов.
Если коротко — чем меньше надо думать, тем мне скучнее. Вам на оборот?
>Если коротко — чем меньше надо думать, тем мне скучнее. Вам на оборот?
понял вас. с этим согласен. csrf легко искать но тут смотря что — искать скучно но сама уязвимость не скучная =)

Начет перевода пользовательского контента — тема стара и есть масса механизмов для фильтрации. Если разраб не начнет делать велосипед то все будет фильтроваться. Искать XSS весело, развлекательно, но если на сайте нет CSRF то его НЕТ. На хероку отличная защита от csrf по токена. Но, опля, очередная рельс badpractise и куча дырок из за match.
А средствами CSRF можно?

Hint: JS коду, выполняемому в контексте уязвимого сайта не надо подделывать referer — у него он уже правильный. Для CSRF это не так.
Проверка referer один из способов защиты от CSRF. И вовсе не факт, что у JS-кода внедренного через XSS он будет правильным. «Опасный» скрипт ждёт referer example.com/page1, а XSS на странице example.com/page2.
XSS не использует «опасные» скрипты. XSS использует стандартные обычные возможности сайта.

И самое главное, позволю себе повториться:
>> Расскажите, есть ли что-то такое, чего нельзя сделать через XSS, но можно сделать через CSRF?

Пока мы только нашли способ защиты, который защитит вас и от CSRF и от XSS. При этом, на многих ресурсах есть действия, которые можно выполнить с любой страницы. CSRF защита по referer будет проверять только домен. От XSS такая защита не поможет.
«Опасные» не случайно поставил в кавычки. Это стандартные возможности сайта, изменяющие его состояние.

При отключенном JS с XSS вообще ничего нельзя сделать. Для CSRF это не помеха.

В IE 6 несколько уязвимостей, позволяющих подменить referer и c плагином flash не все в порядке.
Исходя из того, что доля IE 6 небольшая, то для среднего ресурса можно считать, что закрыты.

Но остается актуальный вопрос с прокси, который у людей на работе хватает.

Проверять referer, конечно, удобней, но пока общепринятым (и не просто так) остается сессия в token ну или более продвинутые вариации.
C одной стороны, про CSRF/XSS можно конечно сказать, мол сами виноваты, разработчики, не читаете стостраничные мануалы, RFC и не используете фреймворки. Но давайте подумаем.

Ведь технологии типа HTML, PHP, Ruby провигаются как простые (в противовес яве с профессиональными фреймворками enterprise уровня). Пишут на них в основном всякие школьники и студенты, но и оптыные разработчики могут пропустить CSRF или XSS. Всюду в блогах примеры кода на jQuery/PHP, которые толком
ничего не проверяют.

Уже который год находят такие баги. Да давайте возьмем наугад любой крупный сайт — наверняка там что-то найдется. Я видео, например, CSRF на вконтакте, хоть его и писали отличники и победители олимпиад. Если уж они допускают такие ляпы, что ждать от обычных программистов? Я знаю только Гугл, у которого нет дыр.

Да что там далеко ходить, возьмите свой старый код, небось и там можно такую дыру найти, не?

Очевидно, что меры по борьбе с уязвимостями должны предприниматься авторами языка/фреймворка. echo должен автоматически ескейпить данные. При обработке POST/GET данных при левом реферере или отсутствии токена интерпретатор PHP по дефолту должен выть и плеваться ошибками. Сырые SQL запросы должно быть неудобно делать. display_errors по умолчанию должен быть равен 0. Да, это надо вводить постепенно, но надо. Иначе число ошибок будет только расти.
Я джавист. От PHPшных фреймворков у меня мозг сворачивается в трубочку. Что-то они мне совсем не кажутся простыми.
Не обязательно ходить за примерами далеко. Over 9000 бесплатных темплетов и плагинов в официальном лепрозории репозитории содержат столько дыр (как случайных, так и злонамеренных), что становится страшно за бедолаг, которые используют сей комбайн не штудируя сорцы каждого плагина.
* темплетов и плагинов для WordPress, хотя и для других CMS хватает.
В том-то и проблема. Вы не заставите хотя бы 50% веб-разработчиков как следует читать мануаы. Все равно они будут копипастить код из интернета и писать его левой пяткой. Потому защита от уязвимостей должна делаться изначально на уровне HTTP/браузера/веб-сервера/среды/платформы, а не отдаваться на добрую волю разработчика.

У меня, кстати, есть еще одно предчуствие, мне кажется, если порыться по сети, можно найти кучу уязвимостей с crossdomain.xml, так как многие разработчики толком не понимают, что делает этот файл и тупо следуют советам типа «если ваше флеш-приложение не соединяется с сервером, добавьте файл crossdomain».

Жалко, мне некогда этим заняться.

Первый закон программирования гласит: «У идеального пользователя не должно быть рук». Это я к тому, что то что один построил, другой завсегда сломать сможет. Мне трудно представить себе гибкую систему (каковой является Web), загнанную в рамки жёстких ограничений. Можно минимизировать угрозы, можно проводить ликбез или даже вводить обязательную аттестацию и ответственность для разработчиков, но окончательно ликвидировать все дыры — задача фактически невыполнимая.

Легко провести параллель с реальным миром, например — с ДТП. Вроде бы всех просвещают о ПДД, автомобили стараются делать безопасными, но каждый год на дорогах погибает более миллиона (!) человек. То что вы предлагаете, равнозначно обязательному изготовлению бронированных автомобилей, облицованных подушками и с ограниченной до 20 км/ч скоростью передвижения, а также введению ещё и «пешеходных прав», дающих разрешение на передвижение возле автострад.
А вообще странно что с Bitbucket так все легко получилось.
Они используют Django 1.3.1 и там по полной используется csrf.
Нужно постараться чтобы отключить csrf)
Они не отключали csrf, просто для защиты кроме включения защиты необходимо еще не делать глупостей и уважать http (не менять данные по GET-запросам, а использовать POST для этого).
Я не понимаю принципиальной разницы между GET и POST, если есть token или даже просто проверяется referer (не надежный и глючный вариант). Можете пояснить?

Понятно, что POST в src картинки не вставишь, но есть JS и это все равно серьезная уязвимость.
По GET можно перейти по ссылке, по POST нельзя. А POST запрос на вашей странице не получит куку аутентификации моего сайта. Вывод — вы не сможете передать пользователю ссылку, перейдя по которой он совершит нужные вам действия на моем сайте, если мой сайт проверяет тип запроса и способ передачи параметров. Конечно, если вы не можете внедрить JS-код на мой сайт.
Я смогу внедрить JS-код на любой другой сайт и сделать там отправку формы через POST, в том числе и в скрытом iframe.

Да, сложнее, вероятность внедрения на стороннем крупном сайте значительно меньше, чем в случае с картинкой, но дыра остается, перейдя по ссылке на сайт злоумышленника, вы будете взломаны без каких-либо внешний проявлений.
Какой-то token или другая подобная защита нужна при любом методе отправки.
Не очень понял схему атаки. Вы, грубо говоря, на своем сайте делаете iframe со страницей моего сайта, заполняете мою форму со своего же сайта и с него же инициируете отправку моей формы?
Нет, iframe будет мой. Нельзя менять iframe из родителя.

Там будет форма c action такого вида и она будет сабмититься автоматически через javascript:



Можно не заморачиваться с iframe и отправить AJAX-запрос, но это будет обозначено в заголовке.

Короче, способов куча, это уже технический вопрос, лишь бы XSRF была в наличие, пусть и с пост.
Блин, тег съелся, хотя я его в code и обернул. Короче, action на взламываемый ресурс, допустим, Хабр:
action="http://habrahabr.ru/index.php"
Ну, так ваша форма не получит мою сессионную куку, в ответ она получит не 200, а 401. Или получит? Что-то я запутался.

А в общем, GET запрос сделать проще, а значит POST это дополнительная защита. Ведь цель любой защиты сделать чтобы взлом был сложнее чем получение профита другим путём.
Моя форма нет, а сайт получит свою куку независимо от referer.

Сложнее, но уязвимость все-равно остается. И ее можно использовать почти с тем же успехом.

Это все равно что защищаться зонтиком от пуль, ведь сложнее же пробить, особенно если в спицу попадут :)

А концепция post — сохранение, get — открытие страницы, на мой взгляд, уже давно не является обязательной.
Тут не так, что через GET проще, а через POST сложнее, тут так: через GET защититься нельзя (ну по крайней мере разумным способом), через POST — можно. Разделение на GET и POST с распространение CSRF-атак как раз-таки становится обязательным.
Можете пояснить почему через GET защитится нельзя? Я уже задавал этот вопрос.
Какой метод защиты вы имеете в виду? Просто использовать POST — это не защита.
Использование POST — это одно из необходимых условий для наименее проблемного способа защиты (через токены). Вот тут: habrahabr.ru/post/141277/#comment_4726068 хорошая ссылка.

Ну и с битбакетом случай конкретный: фреймворк django и его защита от csrf, у которой первое и единственное требование — соблюдение разделения GET и POST.
Там, конечно, много и по-английски, который для меня не родной :)

Но я не нашел, что с GET, токены не будут работать.

Там речь идет о косвенных проблемах, об этой я уже упоминал:
> Понятно, что POST в src картинки не вставишь,
> но есть JS и это все равно серьезная уязвимость.
Как бы мягко говоря не панацея, выше была дискуссия.

А вторая — history API и вообще вроде как GET снифить проще. Но это уже при наличии серьезных проблем с безопасностью на стороне пользователя или других уязвимостей на сайте и касается только многоразовых токенов.
Там было на примере отправки куков через форму. И это если не просто не запретить GET, а еще и его использовать.

В django, я так понял, POST-запросы как-то автоматически защищаются токеном? Тогда, да, фейл, но это касается логики работы конкретной CMS, а не технологии в целом.
Забыл, AJAX-запрос послать нельзя, потому я к этой форме и прицепился.
Очень хотелось бы увидеть подобный кряк на Foresquare или любой другой вебсайт, построенный на Lift web framework.
Я бы еще посмотрел на примеры с Django. Не всегда все всё делают так как надо и хочется реальных примеров чтобы «мотать на ус» и проверять себя и свои проекты. Более того часто приходится использовать чужие разработки и подключать готовые джанго пакеты в проекты — надо быть и в них уверенным…
у лифта name у инпутов какой то хешированый. и вообще все действия с хешем. кароче, секьюрно
UFO landed and left these words here
Спасибо за пример конфига для nginx, не думал в этом направлении еще.
Угу, конфиг замечательный, будет отсекать людей, от которых http_referer не дошел по какой-то причине (кривая прокся, настройки браузера, фаервол и тд) и выдавать им 403. http_referer — заголовок по rfc2616 необязательный, полагаться на его наличие не здорово.
Ну я же не говорю что я именно этот конфиг буду использовать. Он меня натолкнул на мысли что со стороны nginx можно много чего в плане безопасности реализовать. И как я говорил выше не особо думал в этом направлении(ибо кто знает где и как будет хостится написанный код).
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
банальный контроль referer

А я было уже порадовался, что хоть кто-то здравые мысли излагает… Ан нет.
Особенно раздражают сайты, владельцы которых считают, что таким образом они защищаются от накруток и всяческих ботов. А если я просто любитель держать отправку referrer в состояним перманентного ВЫКЛ?

Выводить уведомления и требовать подтверждения при отправке любых данных на другой домен?

Разработчики IE попытались что-то сделать в этом направлении, вышло, впринципе, не так уж и плохо.

А вот найдите CSRF в Drupal, например :)

Лучше сразу ставить обратную задачу — попробуйте не найти ни одной CSRF в продукте/сайте X.
UFO landed and left these words here
Ключ это ключ, токен формы, как хотите, но вы неоднократно упомянули именно referrer, так что не надо… Мотивы использования тех или иных режимов, думаю, вас и вовсе не касаются.
UFO landed and left these words here
Квалификация квалификацией, но с безопасностью такая штука — она работает, когда включена по умолчанию (экранирование в шаблонах, защита от csrf), и нужно предпринять какие-то действия (пометить контроллер как свободный от csrf-защиты, пометить строку как безопасную для вывода), чтоб ее отключить, когда на это есть причина.

— Запретить передачу данных из форм на отличный от текущего домен? А как же такие полезные применениях данной возможности, как «умные» межсайтовые переходы, не говоря уже о системах биллинга, и банальных формах «яндекс.поиск по сайту»?


Запретить передачу данных через POST к себе с чужого домена, именно, с возможностью включения обратно.
Яндек.поиск и умные межсайтовые переходы должны выполняться (и выполняются) методом GET, при чем они тут? Для биллинга правильно csrf явно отключать и использовать другие средства защиты (подписи запросов и тд).

— Выводить уведомления и требовать подтверждения при отправке любых данных на другой домен? Сдается мне, выстроится очередь из желающих либо перейти на браузеры без этой надоедливой ерунды, либо каким-то образом отключить это. Межсайтовые запросы происходят куда чаще, чем вы привыкли это замечать. В том числе и через POST. Один только google рассылает их пачками.


Если гугл рассылкает POST-запросы пачками, то можно и 403 возвращать на эти запросы, т.к. нефиг. Про остальное не понял, о какой такой надоедливой ерунде идет речь.

— Ну и, напоследок, что делать, если я захочу позволить пользователям отправлять на свой сервис данные через POST откуда угодно без лишних проблем? Переезжать на другую планету, где из-за того, что не умеющие плавать способны утонуть, еще не залили бетоном все реки?


Что делать? Подумать и перехотеть. Т.к. если не перехотите — создатите у себя CSRF-уязвимость, вот и все. Опасной она будет или нет — зависит от ситуации, но без защиты любой пользователь сможет при наличии неких скиллов выполнить эту отправку данных от имени любого другого пользователя (например, с помощью XSS на стороннем сайте), и вы этому никак помешать не сможете.

Короче, я не очень понял, о чем это вы написали, увидел наезд на «молодые языки», понты про «квалификацию кодеров» и поэтому огрызаюсь так, уж простите.
UFO landed and left these words here
Статью по ссылке теперь прочитал наконец, понял, о чем вы. Согласен в том, что никакой ракетной науки в защите от csrf нет, в нормальных фреймворках это делается почти тривиально, и что веб-разработчики должны знать, как писать защищенный от csrf (и других атак) код.
часть показанных сайтов написана на «нормальных» фреймворках. где теперь ваш бог?
началась консервативная белеберда со стандартными аргументами, отмазами, все это уже тыщу раз слышал.
а ты попробуй face it подумаю сколько уязвимо, что уже с 2001 года этим страдают такими вот csrf припадками — и попробуй найти другое решение. я не настаиваю на своем решении, я настаиваю на РЕШЕНИИ чтобы пхп новичок пишущий новый стартап вконтакте был защищен. все просто. я говорю что хочу получить а не как это должно быть реализовано, если честно.
UFO landed and left these words here
>Вы говорите, что хотите получать $1000 за аудит одного сайта. Для чего вам и нужно распиарить свое имя на подобных «дешевых разоблачениях».

это что блять за бред? Мне эта гранда нах не нужна, и приписка сделана чисто посмотреть круг заинтересованных лиц. Мне не нужно пиарить имя энимо, и задача поста была порассуждать на тему CSRF — вообще следили пару дней назад HN? Эти ваши истории…

>Скучный сухой отчет по количеству найденных уязвимостей, пара размышлений на тему, как в теории еще можно было бы решить проблему глобально
вообще это я как раз и пытался написать. хотя хотелось бы не «скучный отчет» — их не читают и не внемлют.

вообще рад за ваш крайне высокий уровень квалификации, не думали давать уроки этим, херокам вимео и прочим ребятам выше? критикуете мастерски.
«а ты попробуй face it подумаю сколько уязвимо, что уже с 2001 года этим страдают такими вот csrf припадками — и попробуй найти другое решение.»
Чего?
А ничего что referer тоже передается клиентом и подделывается на раз? :)
неправда. реферер нельзя «подделать». или хотя бы я незнаю действующих уязвимостей для подделки реферера. как максимум его можно дропнуть
из браузера используя JS от лица пользователя. не надо считать себя самым умным лол
А зачем? Достаточно пропустить через свой прокси. О сделает с запросом всё, что душе угодно.
Всему, что приходит от пользователся нельзя доверять, ну никак.
Т.е. пользователь идет через ваше прокси? Так это Man in middle. Так можно даже https перехватить, а не только банальный реферер подделать.
Можно, но, насколько я знаю, только в IE 6 и с помощью flesh. Были еще какой-то баги, но они проявлялись мало у кого и не юзабельные.

Можно нагуглить.
Реферер можно и иногда нужно подделывать, я когда-то SQL-inj через реферер делал :)
Ужас :) куда мы катимся… А например вот так? :)

In = FALSE
Out = TRUE
Key = «Referer: spoof (Out)»
Match = "*"
Replace = "\u"

Домашнее задание пробить по гуглу название программы по кусочку конфига. И таких программ 2 чемодана на самом деле. Не говоря о том что все реквест HTTP заголовки можно собрать руками из перла-курла-пхп-явы и т.д.
еще один кукаретик. напиши страницу xxx которая будет отсылать запрос на yyy с подделаным реферером стандартными средствами JS и я съем свой галстук. учить меня еще будешь, лол.
У Хомяка клинический пример юношеского максимализма. Сразу Денис Попов вспоминается.
И тарифы забавно в блоге растут, моя плакать =)…
Вы говорите о юношеском максимализме, как о чем-то плохом. Уж где-где, а в ИТ на его фундаменте было построено огромное количество замечательных проектов.
А вот хурдовцы и миниксоиды как-то не прореагировали. Беспокойно мне чойто.
Сначала прочитал «проэррегировали». Перечитал правильно. Долго думал.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
хороший коммент, хорошие примеры. XSS фильтруется кучей стандартных функций. если не делать велосипеды то все ок. CSRF и правда легко найти и юзать. А я разве говорил что я пипец какой крутой взлом произвел? цель другая, там в конце описано.

а вот тут вы о чем?
>ревью кода должен делать специалист который разбирается в криптографии, теории вероятности
я не секу и я не специалист, меня надо выпороть?
UFO landed and left these words here
шифрование, wifi? как до этого дошло в этом топике? Впрочим, пожалуйста продолжайте, интересно. тема угона солтов и угадывание серверных параметров интересна.
UFO landed and left these words here
Вот хрень — зашёл на Formspring, а я оказывается фолловлю пользователя homakov, сам того не зная.
Похоже ссылочка то волшебная в посте ;)
изначально планировалась сделать бомбу-месадж с тучей ретвитов репостов через левые сервисы типа yforg который напрямую работает с твиттером и прочие, кароче чтобы кровь кишки расфигачило и сделать это часов в 5 утра по SF. но решил ограничиться фоловингом на паре сервисов чисто для статистики.
Как инструмент для статистики — жуткая штука. Ты сразу получаешь целый аккаунт пользователя на изучение вместо просто связки типа IP/UserAgent, да ещё и полностью незаметно для пользователя.
Поставить такое на порно-сайте — и…
т.е. все геты перестали работать? я рад, там они были в неприятных местах.
Из гетов, чтобы попробовать зафолловить через csrf, я нашел в запросах с вашего бложика всего один, но через него ничего не получалось. Так же, пост запрос из вашей же записи, возвращает 401
image
Ну, и я логично подумал, что они исправили это везде.
Егор — ужас разработчиков, благодаря ему, они теперь работают по выходным (
Заходя на хомяк личный блог Егора, будьте готовы к CSRF-атаке на ваши твиттеры-шмиттеры.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.