Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 191
Все молчат, никто не высовывается, а то Егор и на наши ресурсы придет. Хабр он видимо любит, раз в списке его нет )
Boo!
p.s. а если серьезно на хабре вроде тоже надежда возложена на requested with xmlhttprequest которая обходится трюком с флешом. мне так яхуда катз сказал — они из за этого токен даже в xhr пихают. хотя если реферер везде проверяется то проблем нет.
p.s. а если серьезно на хабре вроде тоже надежда возложена на requested with xmlhttprequest которая обходится трюком с флешом. мне так яхуда катз сказал — они из за этого токен даже в xhr пихают. хотя если реферер везде проверяется то проблем нет.
Интересно, а насколько быстро Вам удастся «поломать» проект на Битриксе?
на хабре вроде тоже надежда возложена на requested with xmlhttprequest которая обходится трюком с флешом
Уже сложно :-) Но есть еще один способ, я писал им, но они не исправили…
Уже сложно :-) Но есть еще один способ, я писал им, но они не исправили…
Там более сложная операция готовится.
500$ человеку, который узнал, что такое CSRF?) Олололо…
согласен. kid goes home :D
Честно говоря сарказм не до конца понятен.
Мало знать что это такое, надо уметь прилагать усилия с нужным вектором и искать знаниям применение.
Список ресурсов соразмерного размера, не особо мелкие, и если их разработчики о csrf «не знали», то почему бы не отдать 500 баксов тому кто знает и умеет этим пользоваться?
А если учесть, что многие предлагают аудит безопасности гораздо дороже и с гораздо меньшим «портфолио», то ценник вообще заоблачным не кажется.
Мало знать что это такое, надо уметь прилагать усилия с нужным вектором и искать знаниям применение.
Список ресурсов соразмерного размера, не особо мелкие, и если их разработчики о csrf «не знали», то почему бы не отдать 500 баксов тому кто знает и умеет этим пользоваться?
А если учесть, что многие предлагают аудит безопасности гораздо дороже и с гораздо меньшим «портфолио», то ценник вообще заоблачным не кажется.
Егор к успеху идет
Как говорится, «ноты знают все, но не все могут написать симфонию»
Егор будет продолжать пока не снимут фильм про него? О_о
Прям как неуловимый Джо )
Про он CSRF узнал, жду выпуск с sql include.
Про он CSRF узнал, жду выпуск с sql include.
Егор может внедрять через XSS картинку «Please read and donate 500$ to Egor Homyakov...»? Достаточно действенно )
Когда уже его на работу возьмут? :)
Даже пытаться не будут, вдруг его чего не устроит, а это страшно )))
Он же в mail.ru работает
Лучшеб его взяли. А то он задолбал уже попрошайничать.
>самый главный баг с переводом денег через 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
>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 гитхаб допустил больший косяк.
description: Following. Well, making score github:bitbucket — 1:1
Егор слишком преувеличил «вес» вреда сайту Bickbucket сравнив это с тем что случилось на github.
Я считаю что будучи авторизованным на Bitbucket вполне нормально по прямой ссылке фолловить спокойно.
А вот у гитхаба был косяк серьезнее. Ну нет тут Bitbucket/Github 1:1 гитхаб допустил больший косяк.
Напомню что у Github он подставил свой ключ и коммитил в репозиторий rails.
Для таких сервисов как Github и Bitbucket репозитории это их хлеб и в том случае он в сердце ранил Github а сейчас лишь подписка и то при авторизации.
Для таких сервисов как Github и Bitbucket репозитории это их хлеб и в том случае он в сердце ранил Github а сейчас лишь подписка и то при авторизации.
bitbucket.org/homakov
Followers (75)
час назад было ноль. я им вообще не пользовался.
хотя очевидно не 1-1. но хочется к гитхабу подлизаться =) что они бяки какие.
Followers (75)
час назад было ноль. я им вообще не пользовался.
хотя очевидно не 1-1. но хочется к гитхабу подлизаться =) что они бяки какие.
Ну так видно же что кто-то заинтересован в этих цифрах… слишком заметно.
Нет тут 1:1 и слишком там кричат эти цифры.
Нет тут 1:1 и слишком там кричат эти цифры.
Будь хорошим мальчиком и убери упоминание гитхаба там и 1:1
а то разработчики Bitbucket тебя заспунят!!!
www.youtube.com/watch?v=dYBjVTMUQY0
Подлизываться лучше лестью или хорошими делами в отношении гитхаба а не засиранием битбакета.
а то разработчики Bitbucket тебя заспунят!!!
www.youtube.com/watch?v=dYBjVTMUQY0
Подлизываться лучше лестью или хорошими делами в отношении гитхаба а не засиранием битбакета.
Нифига не нормально, расширение какое-нибудь может ссылки префетчить, например. Выполнение действий по GET — это явный косяк. Правильно тут при нажатии на ссылку слать ajax POST-запрос, а для людей без аякса предусмотреть страничку с формой подтверждения.
Это я изначально неправильно понял. А потом зайдя на Bitbucket обнаружил что я оказывается подписался на homakov))
Все равно косяк у Bitbucket не сопоставим с тем что Егор проделал на Github.
Все равно косяк у Bitbucket не сопоставим с тем что Егор проделал на Github.
По GET на сайт человек может попасть извне, с другого сайта (по ссылке). При этом csrf-токен в ссылку добавить нельзя (другой сайт этот токен никак не получит, тем более что токен может обновляться на каждый запрос). Поэтому при GET-запросах возможности защититься от CSRF нет => GET-запросы не должны выполнять действия, менеяющие данные, они должны просто отдавать информацию. Если этому правилу следовать, то CSRF-атаки через GET-запросы (== человек просто переходит по ссылке) будут безобидными.
POST же человек в большинстве случаев (не учитывая api и тд, где обычно предусматриваются другие средства защиты) выполняет с того же сайта. Перед этим запрашивается страница через GET и у сервера есть возможность передать csrf-токен в куке, который потом при POST-запросе можно проверить.
Браузеры работают так, что js с чужого домена прочесть не свою куку не может, поэтому правильный POST-запрос сгенерировать на js не получится. С помощью html формы — тем более (токену с чужого сервера там взяться неоткуда).
POST же человек в большинстве случаев (не учитывая api и тд, где обычно предусматриваются другие средства защиты) выполняет с того же сайта. Перед этим запрашивается страница через GET и у сервера есть возможность передать csrf-токен в куке, который потом при POST-запросе можно проверить.
Браузеры работают так, что js с чужого домена прочесть не свою куку не может, поэтому правильный POST-запрос сгенерировать на js не получится. С помощью html формы — тем более (токену с чужого сервера там взяться неоткуда).
> При этом csrf-токен в ссылку добавить нельзя
www.example.org/api/do_something?csrf_token=1234567890
Что я не так сделал?
www.example.org/api/do_something?csrf_token=1234567890
Что я не так сделал?
не прочитали объяснение в скобках)
Ок, чуть подробнее: вы тут защитились от CSRF через GET, но при этом закрыли возможность ссылаться на ваш сайт (т.к. любая ссылка без токена будет вызывать 403, а стороннему сайту ваш токен взять неоткуда); кроме того, усложнили жизнь пользователям (им при первом вводе адреса в строку браузера тоже нужно будет откуда-то брать этот токен).
Это и имеется в виду в фразе «при GET-запросах возможности защититься от CSRF нет».
Это и имеется в виду в фразе «при GET-запросах возможности защититься от CSRF нет».
Хорошо, а если я использую POST-запрос, то это что, откроет возможность ссылаться с других сайтов?
Мне как-то всегда казалось, что задачи защиты от CSRF и возможность ссылки с других сайтов являются взаимоисключающими, независимо от используемого метода.
Мне как-то всегда казалось, что задачи защиты от CSRF и возможность ссылки с других сайтов являются взаимоисключающими, независимо от используемого метода.
Да, вы правы.
Я писал все это не в общем случае, а в частном — в контексте фреймворка, продоставляющий защиту от csrf по умолчанию. Профессиональная деформация. Это как-то затерялось у меня, даже сам забыл — ответ на замечание про битбакет (правильный в контексте), потом опять вопрос-ответ и тд. То, что я пишу, не верно в общем случае, но вполне верно в конкретном про битбакет.
В чем тут суть — защита работает, если ее нужно отключать, а не включать. Для POST ее включать по умолчанию можно, а для GET — очень непрактично. Поэтому, если следовать принципу «защита должна быть по умолчанию», защищаться от CSRF через GET не получается.
Я писал все это не в общем случае, а в частном — в контексте фреймворка, продоставляющий защиту от csrf по умолчанию. Профессиональная деформация. Это как-то затерялось у меня, даже сам забыл — ответ на замечание про битбакет (правильный в контексте), потом опять вопрос-ответ и тд. То, что я пишу, не верно в общем случае, но вполне верно в конкретном про битбакет.
В чем тут суть — защита работает, если ее нужно отключать, а не включать. Для POST ее включать по умолчанию можно, а для GET — очень непрактично. Поэтому, если следовать принципу «защита должна быть по умолчанию», защищаться от CSRF через GET не получается.
Мне кажется, запрещать действия по GET-запросам просто из-за сложностей с определением необходимости защиты — неправильно, ведь дать написать простую ссылку гораздо проще, чем скрипт, отправляющий POST-запрос. Собственно, это и есть основная проблема подобных «автоматических» защит.
Лично мне кажется разумнее другой вариант. Если использовать MVC-разбиение, то все страницы сайта поделятся на относящиеся к виду (и при обращении к ним не выполняется никаких действий) и относящиеся к контроллеру (выполняющие действия, но не выдающие пользователю ничего кроме редиректа). В таком случае необходимо и достаточно защитить только вторую половину адресов.
Лично мне кажется разумнее другой вариант. Если использовать MVC-разбиение, то все страницы сайта поделятся на относящиеся к виду (и при обращении к ним не выполняется никаких действий) и относящиеся к контроллеру (выполняющие действия, но не выдающие пользователю ничего кроме редиректа). В таком случае необходимо и достаточно защитить только вторую половину адресов.
Это называется Double Submit Cookies.
www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Основное отличие — у POST запроса есть тело, которое в URL не передаётся. Если сервер не контролирует тип запроса (и способ передачи параметров), то злоумышленник может любым способом передать вам ссылку, перейдя по которой вы совершите нужное ему действие.
Егор, а вот они говорят что являются № 1 в аудите безопасности. Можешь даказать обратное на их примере? :)
Я по логам xss сканера могу несколько сотен сайтов с такими же проблемами назвать. Но делать это не буду :)
xss? причем тут эта скучная старая атака ?) Не, это банальщина.
Надоели эти скучные атаки… Меняешь, меняешь их постоянно....
Опаснее для кого?
> и в 3 раза реже встречается, чем CSRF
бред. приглашаю тестить алексу 1000. XSS фильтрация настолько распиарена что только полный мудак про неё может забыть, извиняюсь за выражение(та жехрень с sql inject). Чего не скажешь про CSRF который до сих пор чертовски распространен.
бред. приглашаю тестить алексу 1000. XSS фильтрация настолько распиарена что только полный мудак про неё может забыть, извиняюсь за выражение(та жехрень с sql inject). Чего не скажешь про CSRF который до сих пор чертовски распространен.
Но это значит, что относиться к XSS как к «этой старой скучной атаке» не стоит. CSRF в крупном ресурсе может найти любой школьник. XSS — далеко не любой. XSS меньше, они опаснее, искать их интереснее. Часто нужно именно обходить защиту, а не банально радоваться тому, что разработчик забыл ее сделать.
ну что за ересь а?! уэлл, в рельсах фильтрация safe_buffer стоит по умолчанию. берите тестите хоть самые укромные места. и так на всех нормальных ресурсах — фильтрация не выборочная а по умолчанию на весь аутпут юзерского инпута. (опять таки, если разраб не мудак)
поэтому можно даже так перефразировать ваше заявление
много пользователей имеют пароль 123123 и qweqwe и это намного опасней чем всякие взломы. Да, встречается редко, но это же так прикольно тратить время с попыткой угадать пароль.
Атаки совершенно РАЗНЫЕ. защититься от XSS в разы проще чем от CSRF на практике. Ну зачем путать и делать ложные аналогии?
ну что за ересь а?! уэлл, в рельсах фильтрация safe_buffer стоит по умолчанию. берите тестите хоть самые укромные места. и так на всех нормальных ресурсах — фильтрация не выборочная а по умолчанию на весь аутпут юзерского инпута. (опять таки, если разраб не мудак)
поэтому можно даже так перефразировать ваше заявление
много пользователей имеют пароль 123123 и qweqwe и это намного опасней чем всякие взломы. Да, встречается редко, но это же так прикольно тратить время с попыткой угадать пароль.
Атаки совершенно РАЗНЫЕ. защититься от XSS в разы проще чем от CSRF на практике. Ну зачем путать и делать ложные аналогии?
>Если коротко — чем меньше надо думать, тем мне скучнее. Вам на оборот?
понял вас. с этим согласен. csrf легко искать но тут смотря что — искать скучно но сама уязвимость не скучная =)
Начет перевода пользовательского контента — тема стара и есть масса механизмов для фильтрации. Если разраб не начнет делать велосипед то все будет фильтроваться. Искать XSS весело, развлекательно, но если на сайте нет CSRF то его НЕТ. На хероку отличная защита от csrf по токена. Но, опля, очередная рельс badpractise и куча дырок из за match.
понял вас. с этим согласен. csrf легко искать но тут смотря что — искать скучно но сама уязвимость не скучная =)
Начет перевода пользовательского контента — тема стара и есть масса механизмов для фильтрации. Если разраб не начнет делать велосипед то все будет фильтроваться. Искать XSS весело, развлекательно, но если на сайте нет CSRF то его НЕТ. На хероку отличная защита от csrf по токена. Но, опля, очередная рельс badpractise и куча дырок из за match.
Средствами JS можно подделать referer?
В IE 6 несколько уязвимостей, позволяющих подменить referer и c плагином flash не все в порядке.
И до сих пор не закрыты?
Исходя из того, что доля IE 6 небольшая, то для среднего ресурса можно считать, что закрыты.
Но остается актуальный вопрос с прокси, который у людей на работе хватает.
Проверять referer, конечно, удобней, но пока общепринятым (и не просто так) остается сессия в token ну или более продвинутые вариации.
Но остается актуальный вопрос с прокси, который у людей на работе хватает.
Проверять referer, конечно, удобней, но пока общепринятым (и не просто так) остается сессия в token ну или более продвинутые вариации.
C одной стороны, про CSRF/XSS можно конечно сказать, мол сами виноваты, разработчики, не читаете стостраничные мануалы, RFC и не используете фреймворки. Но давайте подумаем.
Ведь технологии типа HTML, PHP, Ruby провигаются как простые (в противовес яве с профессиональными фреймворками enterprise уровня). Пишут на них в основном всякие школьники и студенты, но и оптыные разработчики могут пропустить CSRF или XSS. Всюду в блогах примеры кода на jQuery/PHP, которые толком
ничего не проверяют.
Уже который год находят такие баги. Да давайте возьмем наугад любой крупный сайт — наверняка там что-то найдется. Я видео, например, CSRF на вконтакте, хоть его и писали отличники и победители олимпиад. Если уж они допускают такие ляпы, что ждать от обычных программистов? Я знаю только Гугл, у которого нет дыр.
Да что там далеко ходить, возьмите свой старый код, небось и там можно такую дыру найти, не?
Очевидно, что меры по борьбе с уязвимостями должны предприниматься авторами языка/фреймворка. echo должен автоматически ескейпить данные. При обработке POST/GET данных при левом реферере или отсутствии токена интерпретатор PHP по дефолту должен выть и плеваться ошибками. Сырые SQL запросы должно быть неудобно делать. display_errors по умолчанию должен быть равен 0. Да, это надо вводить постепенно, но надо. Иначе число ошибок будет только расти.
Ведь технологии типа 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».
Жалко, мне некогда этим заняться.
У меня, кстати, есть еще одно предчуствие, мне кажется, если порыться по сети, можно найти кучу уязвимостей с crossdomain.xml, так как многие разработчики толком не понимают, что делает этот файл и тупо следуют советам типа «если ваше флеш-приложение не соединяется с сервером, добавьте файл crossdomain».
Жалко, мне некогда этим заняться.
Первый закон программирования гласит: «У идеального пользователя не должно быть рук». Это я к тому, что то что один построил, другой завсегда сломать сможет. Мне трудно представить себе гибкую систему (каковой является Web), загнанную в рамки жёстких ограничений. Можно минимизировать угрозы, можно проводить ликбез или даже вводить обязательную аттестацию и ответственность для разработчиков, но окончательно ликвидировать все дыры — задача фактически невыполнимая.
Легко провести параллель с реальным миром, например — с ДТП. Вроде бы всех просвещают о ПДД, автомобили стараются делать безопасными, но каждый год на дорогах погибает более миллиона (!) человек. То что вы предлагаете, равнозначно обязательному изготовлению бронированных автомобилей, облицованных подушками и с ограниченной до 20 км/ч скоростью передвижения, а также введению ещё и «пешеходных прав», дающих разрешение на передвижение возле автострад.
Легко провести параллель с реальным миром, например — с ДТП. Вроде бы всех просвещают о ПДД, автомобили стараются делать безопасными, но каждый год на дорогах погибает более миллиона (!) человек. То что вы предлагаете, равнозначно обязательному изготовлению бронированных автомобилей, облицованных подушками и с ограниченной до 20 км/ч скоростью передвижения, а также введению ещё и «пешеходных прав», дающих разрешение на передвижение возле автострад.
А вообще странно что с Bitbucket так все легко получилось.
Они используют Django 1.3.1 и там по полной используется csrf.
Нужно постараться чтобы отключить csrf)
Они используют Django 1.3.1 и там по полной используется csrf.
Нужно постараться чтобы отключить csrf)
Хмм хотел ответить на этот комментарий.
Они не отключали csrf, просто для защиты кроме включения защиты необходимо еще не делать глупостей и уважать http (не менять данные по GET-запросам, а использовать POST для этого).
Я не понимаю принципиальной разницы между GET и POST, если есть token или даже просто проверяется referer (не надежный и глючный вариант). Можете пояснить?
Понятно, что POST в src картинки не вставишь, но есть JS и это все равно серьезная уязвимость.
Понятно, что POST в src картинки не вставишь, но есть JS и это все равно серьезная уязвимость.
По GET можно перейти по ссылке, по POST нельзя. А POST запрос на вашей странице не получит куку аутентификации моего сайта. Вывод — вы не сможете передать пользователю ссылку, перейдя по которой он совершит нужные вам действия на моем сайте, если мой сайт проверяет тип запроса и способ передачи параметров. Конечно, если вы не можете внедрить JS-код на мой сайт.
Я смогу внедрить JS-код на любой другой сайт и сделать там отправку формы через POST, в том числе и в скрытом iframe.
Да, сложнее, вероятность внедрения на стороннем крупном сайте значительно меньше, чем в случае с картинкой, но дыра остается, перейдя по ссылке на сайт злоумышленника, вы будете взломаны без каких-либо внешний проявлений.
Да, сложнее, вероятность внедрения на стороннем крупном сайте значительно меньше, чем в случае с картинкой, но дыра остается, перейдя по ссылке на сайт злоумышленника, вы будете взломаны без каких-либо внешний проявлений.
Какой-то token или другая подобная защита нужна при любом методе отправки.
Не очень понял схему атаки. Вы, грубо говоря, на своем сайте делаете iframe со страницей моего сайта, заполняете мою форму со своего же сайта и с него же инициируете отправку моей формы?
Нет, iframe будет мой. Нельзя менять iframe из родителя.
Там будет форма c action такого вида и она будет сабмититься автоматически через javascript:
Можно не заморачиваться с iframe и отправить AJAX-запрос, но это будет обозначено в заголовке.
Короче, способов куча, это уже технический вопрос, лишь бы XSRF была в наличие, пусть и с пост.
Там будет форма c action такого вида и она будет сабмититься автоматически через javascript:
Можно не заморачиваться с iframe и отправить AJAX-запрос, но это будет обозначено в заголовке.
Короче, способов куча, это уже технический вопрос, лишь бы XSRF была в наличие, пусть и с пост.
Блин, тег съелся, хотя я его в code и обернул. Короче, action на взламываемый ресурс, допустим, Хабр:
action="http://habrahabr.ru/index.php"Ну, так ваша форма не получит мою сессионную куку, в ответ она получит не 200, а 401. Или получит? Что-то я запутался.
А в общем, GET запрос сделать проще, а значит POST это дополнительная защита. Ведь цель любой защиты сделать чтобы взлом был сложнее чем получение профита другим путём.
А в общем, GET запрос сделать проще, а значит POST это дополнительная защита. Ведь цель любой защиты сделать чтобы взлом был сложнее чем получение профита другим путём.
Моя форма нет, а сайт получит свою куку независимо от referer.
Сложнее, но уязвимость все-равно остается. И ее можно использовать почти с тем же успехом.
Это все равно что защищаться зонтиком от пуль, ведь сложнее же пробить, особенно если в спицу попадут :)
А концепция post — сохранение, get — открытие страницы, на мой взгляд, уже давно не является обязательной.
Сложнее, но уязвимость все-равно остается. И ее можно использовать почти с тем же успехом.
Это все равно что защищаться зонтиком от пуль, ведь сложнее же пробить, особенно если в спицу попадут :)
А концепция post — сохранение, get — открытие страницы, на мой взгляд, уже давно не является обязательной.
Тут не так, что через GET проще, а через POST сложнее, тут так: через GET защититься нельзя (ну по крайней мере разумным способом), через POST — можно. Разделение на GET и POST с распространение CSRF-атак как раз-таки становится обязательным.
Можете пояснить почему через GET защитится нельзя? Я уже задавал этот вопрос.
Какой метод защиты вы имеете в виду? Просто использовать POST — это не защита.
Использование POST — это одно из необходимых условий для наименее проблемного способа защиты (через токены). Вот тут: habrahabr.ru/post/141277/#comment_4726068 хорошая ссылка.
Ну и с битбакетом случай конкретный: фреймворк django и его защита от csrf, у которой первое и единственное требование — соблюдение разделения GET и POST.
Ну и с битбакетом случай конкретный: фреймворк django и его защита от csrf, у которой первое и единственное требование — соблюдение разделения GET и POST.
Там, конечно, много и по-английски, который для меня не родной :)
Но я не нашел, что с GET, токены не будут работать.
Там речь идет о косвенных проблемах, об этой я уже упоминал:
> Понятно, что POST в src картинки не вставишь,
> но есть JS и это все равно серьезная уязвимость.
Как бы мягко говоря не панацея, выше была дискуссия.
А вторая — history API и вообще вроде как GET снифить проще. Но это уже при наличии серьезных проблем с безопасностью на стороне пользователя или других уязвимостей на сайте и касается только многоразовых токенов.
Там было на примере отправки куков через форму. И это если не просто не запретить GET, а еще и его использовать.
В django, я так понял, POST-запросы как-то автоматически защищаются токеном? Тогда, да, фейл, но это касается логики работы конкретной CMS, а не технологии в целом.
Но я не нашел, что с GET, токены не будут работать.
Там речь идет о косвенных проблемах, об этой я уже упоминал:
> Понятно, что POST в src картинки не вставишь,
> но есть JS и это все равно серьезная уязвимость.
Как бы мягко говоря не панацея, выше была дискуссия.
А вторая — history API и вообще вроде как GET снифить проще. Но это уже при наличии серьезных проблем с безопасностью на стороне пользователя или других уязвимостей на сайте и касается только многоразовых токенов.
Там было на примере отправки куков через форму. И это если не просто не запретить GET, а еще и его использовать.
В django, я так понял, POST-запросы как-то автоматически защищаются токеном? Тогда, да, фейл, но это касается логики работы конкретной CMS, а не технологии в целом.
Забыл, AJAX-запрос послать нельзя, потому я к этой форме и прицепился.
Очень хотелось бы увидеть подобный кряк на Foresquare или любой другой вебсайт, построенный на Lift web framework.
Я бы еще посмотрел на примеры с Django. Не всегда все всё делают так как надо и хочется реальных примеров чтобы «мотать на ус» и проверять себя и свои проекты. Более того часто приходится использовать чужие разработки и подключать готовые джанго пакеты в проекты — надо быть и в них уверенным…
у лифта name у инпутов какой то хешированый. и вообще все действия с хешем. кароче, секьюрно
Спасибо за пример конфига для nginx, не думал в этом направлении еще.
Угу, конфиг замечательный, будет отсекать людей, от которых http_referer не дошел по какой-то причине (кривая прокся, настройки браузера, фаервол и тд) и выдавать им 403. http_referer — заголовок по rfc2616 необязательный, полагаться на его наличие не здорово.
Ну я же не говорю что я именно этот конфиг буду использовать. Он меня натолкнул на мысли что со стороны nginx можно много чего в плане безопасности реализовать. И как я говорил выше не особо думал в этом направлении(ибо кто знает где и как будет хостится написанный код).
И спасибо за это замечание забыл сказать.
реферер вообще можно скинуть. это я про webkit hole который нашел
банальный контроль referer
А я было уже порадовался, что хоть кто-то здравые мысли излагает… Ан нет.
Особенно раздражают сайты, владельцы которых считают, что таким образом они защищаются от накруток и всяческих ботов. А если я просто любитель держать отправку referrer в состояним перманентного ВЫКЛ?
Выводить уведомления и требовать подтверждения при отправке любых данных на другой домен?
Разработчики IE попытались что-то сделать в этом направлении, вышло, впринципе, не так уж и плохо.
А вот найдите CSRF в Drupal, например :)
Лучше сразу ставить обратную задачу — попробуйте не найти ни одной CSRF в продукте/сайте X.
Квалификация квалификацией, но с безопасностью такая штука — она работает, когда включена по умолчанию (экранирование в шаблонах, защита от csrf), и нужно предпринять какие-то действия (пометить контроллер как свободный от csrf-защиты, пометить строку как безопасную для вывода), чтоб ее отключить, когда на это есть причина.
Запретить передачу данных через POST к себе с чужого домена, именно, с возможностью включения обратно.
Яндек.поиск и умные межсайтовые переходы должны выполняться (и выполняются) методом GET, при чем они тут? Для биллинга правильно csrf явно отключать и использовать другие средства защиты (подписи запросов и тд).
Если гугл рассылкает POST-запросы пачками, то можно и 403 возвращать на эти запросы, т.к. нефиг. Про остальное не понял, о какой такой надоедливой ерунде идет речь.
Что делать? Подумать и перехотеть. Т.к. если не перехотите — создатите у себя CSRF-уязвимость, вот и все. Опасной она будет или нет — зависит от ситуации, но без защиты любой пользователь сможет при наличии неких скиллов выполнить эту отправку данных от имени любого другого пользователя (например, с помощью XSS на стороннем сайте), и вы этому никак помешать не сможете.
Короче, я не очень понял, о чем это вы написали, увидел наезд на «молодые языки», понты про «квалификацию кодеров» и поэтому огрызаюсь так, уж простите.
— Запретить передачу данных из форм на отличный от текущего домен? А как же такие полезные применениях данной возможности, как «умные» межсайтовые переходы, не говоря уже о системах биллинга, и банальных формах «яндекс.поиск по сайту»?
Запретить передачу данных через POST к себе с чужого домена, именно, с возможностью включения обратно.
Яндек.поиск и умные межсайтовые переходы должны выполняться (и выполняются) методом GET, при чем они тут? Для биллинга правильно csrf явно отключать и использовать другие средства защиты (подписи запросов и тд).
— Выводить уведомления и требовать подтверждения при отправке любых данных на другой домен? Сдается мне, выстроится очередь из желающих либо перейти на браузеры без этой надоедливой ерунды, либо каким-то образом отключить это. Межсайтовые запросы происходят куда чаще, чем вы привыкли это замечать. В том числе и через POST. Один только google рассылает их пачками.
Если гугл рассылкает POST-запросы пачками, то можно и 403 возвращать на эти запросы, т.к. нефиг. Про остальное не понял, о какой такой надоедливой ерунде идет речь.
— Ну и, напоследок, что делать, если я захочу позволить пользователям отправлять на свой сервис данные через POST откуда угодно без лишних проблем? Переезжать на другую планету, где из-за того, что не умеющие плавать способны утонуть, еще не залили бетоном все реки?
Что делать? Подумать и перехотеть. Т.к. если не перехотите — создатите у себя CSRF-уязвимость, вот и все. Опасной она будет или нет — зависит от ситуации, но без защиты любой пользователь сможет при наличии неких скиллов выполнить эту отправку данных от имени любого другого пользователя (например, с помощью XSS на стороннем сайте), и вы этому никак помешать не сможете.
Короче, я не очень понял, о чем это вы написали, увидел наезд на «молодые языки», понты про «квалификацию кодеров» и поэтому огрызаюсь так, уж простите.
началась консервативная белеберда со стандартными аргументами, отмазами, все это уже тыщу раз слышал.
а ты попробуй face it подумаю сколько уязвимо, что уже с 2001 года этим страдают такими вот csrf припадками — и попробуй найти другое решение. я не настаиваю на своем решении, я настаиваю на РЕШЕНИИ чтобы пхп новичок пишущий новый стартап вконтакте был защищен. все просто. я говорю что хочу получить а не как это должно быть реализовано, если честно.
а ты попробуй face it подумаю сколько уязвимо, что уже с 2001 года этим страдают такими вот csrf припадками — и попробуй найти другое решение. я не настаиваю на своем решении, я настаиваю на РЕШЕНИИ чтобы пхп новичок пишущий новый стартап вконтакте был защищен. все просто. я говорю что хочу получить а не как это должно быть реализовано, если честно.
Пожалуйста, CSRF в Drupal :]
www.exploit-db.com/exploits/18564/
www.exploit-db.com/exploits/18564/
А ничего что referer тоже передается клиентом и подделывается на раз? :)
неправда. реферер нельзя «подделать». или хотя бы я незнаю действующих уязвимостей для подделки реферера. как максимум его можно дропнуть
curl --referer example.com/page1.html www.example2.com/?
из браузера используя JS от лица пользователя. не надо считать себя самым умным лол
А зачем? Достаточно пропустить через свой прокси. О сделает с запросом всё, что душе угодно.
Всему, что приходит от пользователся нельзя доверять, ну никак.
Всему, что приходит от пользователся нельзя доверять, ну никак.
Можно, но, насколько я знаю, только в IE 6 и с помощью flesh. Были еще какой-то баги, но они проявлялись мало у кого и не юзабельные.
Можно нагуглить.
Можно нагуглить.
флешем, жавой
Реферер можно и иногда нужно подделывать, я когда-то SQL-inj через реферер делал :)
Ужас :) куда мы катимся… А например вот так? :)
In = FALSE
Out = TRUE
Key = «Referer: spoof (Out)»
Match = "*"
Replace = "\u"
Домашнее задание пробить по гуглу название программы по кусочку конфига. И таких программ 2 чемодана на самом деле. Не говоря о том что все реквест HTTP заголовки можно собрать руками из перла-курла-пхп-явы и т.д.
In = FALSE
Out = TRUE
Key = «Referer: spoof (Out)»
Match = "*"
Replace = "\u"
Домашнее задание пробить по гуглу название программы по кусочку конфига. И таких программ 2 чемодана на самом деле. Не говоря о том что все реквест HTTP заголовки можно собрать руками из перла-курла-пхп-явы и т.д.
У Хомяка клинический пример юношеского максимализма. Сразу Денис Попов вспоминается.
И тарифы забавно в блоге растут, моя плакать =)…
И тарифы забавно в блоге растут, моя плакать =)…
Ееееееееееегооооооооор Хоооооомяяяяяяяяякооооов
Егор продолжает взломы хомяков?
вебкилл 2.0
перезагрузка
перезагрузка
хороший коммент, хорошие примеры. XSS фильтруется кучей стандартных функций. если не делать велосипеды то все ок. CSRF и правда легко найти и юзать. А я разве говорил что я пипец какой крутой взлом произвел? цель другая, там в конце описано.
а вот тут вы о чем?
>ревью кода должен делать специалист который разбирается в криптографии, теории вероятности
я не секу и я не специалист, меня надо выпороть?
а вот тут вы о чем?
>ревью кода должен делать специалист который разбирается в криптографии, теории вероятности
я не секу и я не специалист, меня надо выпороть?
Вот хрень — зашёл на Formspring, а я оказывается фолловлю пользователя homakov, сам того не зная.
Похоже ссылочка то волшебная в посте ;)
Похоже ссылочка то волшебная в посте ;)
изначально планировалась сделать бомбу-месадж с тучей ретвитов репостов через левые сервисы типа yforg который напрямую работает с твиттером и прочие, кароче чтобы кровь кишки расфигачило и сделать это часов в 5 утра по SF. но решил ограничиться фоловингом на паре сервисов чисто для статистики.
Как инструмент для статистики — жуткая штука. Ты сразу получаешь целый аккаунт пользователя на изучение вместо просто связки типа IP/UserAgent, да ещё и полностью незаметно для пользователя.
Поставить такое на порно-сайте — и…
Formspring уже исправился, появился хидер x-formspring-token.
Егор — ужас разработчиков, благодаря ему, они теперь работают по выходным (
Хомячить сайты — это по-русски :)
Заходя на хомяк личный блог Егора, будьте готовы к CSRF-атаке на ваши твиттеры-шмиттеры.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Егор Хомяков продолжает взломы