Loo Опубликовано 31 декабря, 2008 Поделиться Опубликовано 31 декабря, 2008 Меня всегда волновало, когда браузеры начинали обвешивать всякими приблудами. Надстройки, скрипты всякие. До сих пор считаю, что создавать что-то на движке эксплорера полная дурь. Хотя честно признаюсь, что пересел давно на файрфокс. Давно-давно, один секьюрити дяденька, говорил что, все его сенситивные приложени у него хранятся на компакт-диске, чтобы значитца не быть зараженными вирусами, и скомпрометированными всякой херней. Про вирусы мы дискутировали, а вот "всякая херня" как модель угрозы меня не волновала :о)) Ну прикольно, чо? Я даже както выступил, что блин, скоро эти атаки станут опасны. Ну они и стали опасны :о) Меня забавляют сайты, которые при заходе на них, либо открывают еще пару окон (поп-апом например), либо держат счетчики активные на основной странице. Заходишь на сайт банка, а там маленькая ссылочка на интернет-банкинг и еще пару тройку крассивишных картинок на "партнеров". Ссут наверное программеры, ссылки на опасные мелкими строят подсупдно, шобы злые хакиры не заметили :о)) На альфадиректе например, офигенная ссылка "рекомендуй нас друзьям!", офигенная потому что с рефералом. Секьюрное программирование ля веб, это бля очень сложная штука! Ну теперь попробуем посмотреть че происходит. Наша любимая браузера, она нам типа жизнь облегчает, юзабилити добавляет и все такое, и все используют куки. ЧТобы и новости показать, и данные ваши сохранить и все такое. Не, я пока не про пароли сохраненные, да и вообще не про них.Воровать пароли сохраненные в браузерах это другая тема, и вообще мне например не интересная.И во всяких пасскиперах тоже. Прикол в другом, в том что куки есть :о)) Ну куки и куки, печеньки фигли там. Ну знают они, что я на сайт их приходил, чего смотрел на том сайте знают, ничего страшного, так ведь ? Ну почти так :о)) Дело в том, что согласно СПЕЦИФИКАЦИИ куки работают таким незамысловатым способом, ни обновляются, и затирают (могут затирать) предыдущие свои(!) реинкарнации. Это понятно и просто, так ведь? Весь "прикол" в том, что например куки http легко заменяют собой cookie https. Ага, если они от одного привязанного к домену имени и хоста, то им по фигу. На https куки устанавливается так называемый secure flag, ткоторый говорит о том, что эта кука привязанна к защишенной сессии, и не может быть передана по открытм каналам, только по https и в тот домен(плюс хост) которым она иницированна. Браузеры, практически все корректно отрабатывают такие инструкции. ВОт только не гарантируют (да не просто не гарантируют, а ваще ничего не делают!) целостность куки. Между тем, куки с установленым секьюрити флагом никак не защишенна от того, чтобы http кука не сняла с нее сей флаг :о)) И тогда наша https "печенька" отправится по тому маршруту, который будет ей указан ... Не-не, привзяка то к сессии сохранится, сессия не разорванна же! Она по таймауту может отвалиться, но мягко говоря не быстро :о)) В 2007 году drupal'овцы классно озаботились проблемой: http://drupal.org/node/170310 "I have previously used session.cookie_secure with drupal sites to ensure secure authenticated access. This depends on having different session names for the HTTP and HTTPS sites; otherwise, the HTTP site will not see the session cookie and so overwrite it with a new one. Thus, as soon as an authenticated HTTPS user visits the equivalent HTTP url, their original HTTPS session will be gone from the browser cookiejar. What I need is either a way to "force" the session name, or, if drupal wants to require auto-generated session names, it needs to check if session.cookie_secure is enabled, and if so, generate different session names for the HTTP and HTTPS sites. I think a patch would be pretty simple." Симпле, хуимпле! Подкрутили свой PHP код(кривовато есиче, но счас не об этом), обсудили модную DNS rebinding и забили :о)) В принципе их можно понять, они не "человек из Кемерово" -(с) БГ не могут "поправить" весь мир. Им бы про PHP session ID в этом ракурсе подумать, ан нет, замахнемся на dns, хуле там. Но так как сейчас спецов по ит-секьюрити развелось чуть не больше, чем "трейдеров" до кризиса, то парочка гламурных таки выступило например на дефконе, ну коммерция же. "Поймали "тему" и будем на ней жить." -(с) не мой :о)) http://fscked.org/blog/fully-automated-act...ookie-hijacking Расписали оне значит для киддисов как оно работает, наваяли скрипты и вперед с песнями -"Ставтье на свой сервер, будет здоровы!" Не, ну молодцы конечно, чего уж там. Только вот от рекомендаций " как посмотреть в файрфоксе, все ли у вас в порядке" меня прет не по-детски :о)) "To check your sites under Firefox, go to the Privacy tab in the Preferences window, and click on "Show Cookies". For a given site, inspect the individual cookies for the top level name of the site, and any subdomain names, and if any have "Send For: Encrypted connections only", delete them. Then try to visit your site again. If it still allows you in, the site is insecure and your session can be stolen. You should report this to the site maintainer." Установил файрфокс -> смотри че пишет -> будь исследователем! Тотуировки "i 0wn the w0rld" на затылке в комплект не входят, заказываются отдельно! :о)) Когда будешь писать письмо на сайт, укажи шо инфу брал на дефконе, все бабы твои! :о)) Про бекграунд запросы браузеров, это "дефкон маниак" ниче не сказал. Ну не знает он видимо ничего военного, о том как работают браузеры. Это ж неинтересно. То что модель Https подразумевает использование OCSP реквестов это фигня же, правда? То что они открытым текстом передаются по открытому каналу, это тоже фигня. Согласен фигли. Ну а то, что ошибка при отсылке OSCP реквеста (не получен вовремя OSCP response например) никак(!) не препятствует установлению коннекта, это мелочи конечно. Ошибки обработки 302 редиректа тоже конечно мелочи. Ну позволяют они снять (или установить) Secure-Flag на кукис, ну и чего? :о)) Единственным общепризнаным (ну хоть тут мнения сошлись :о)) путем hijack-Инга Https сессии считается атака MITM. ТОлько вот устроить активную MITM атаку очень сложно вроде как. Ну как бы сложно. Ну да. Не берем в расчет wi-fi сети публичные. Там как два пальца. В непубличных сложнее. Ага, там сначала надо пассивную атаку провести, собрать таки пакеты с эфира :о)) Часа 2 даже иногда нужно по хорошему :о)) А вот для того, чтобы устроить MITM атаку на https, нужно подменить "печеньку" (это для нас печенька, а вот для злоумышленника ПИРОГИ целые :о)), чтобы снять с нее секьюре-флаг и отправить не по htps. Это сложно. Ага, если не пользоваться выложенной по вышеприведенной ссылке софтинкой. Ну да, разбираться с каждым отдебным случаем на предмет обустройства dns rebinding (если проспуфить не получиться) это конечно долго :о)) Ну нам же надо будет отослать "клиенту" от имени сайта куку? А если оно привязанно к доменному имени и хосту, то на поверхности вроде как лежит решение про ребиндинг. Потому что в бекграунже реквестов от браузера идет только то: ocsp (вроде как чутка посмотрели), safebrowsing update (гыы, ну откуда только не качается, напрмиер файрфокс запросто с гугля может делать апдейт :о)) ну и редиректы. Кто-там сегодня в safe(!)browsing апдейтах у вашего браузера ? Как не знаете? А как они вообще меняються? Опять не знаете? А с dns чего? Ну вы же внимательно смотрите и контролируете, правильно ли ВАШ браузер знает о http://sb.google.com/safebrowsing/update?client= ... ? Ну судя по панике в http://yandex.ru/yandsearch?text=safebrows...mp;stpar1=%2Fu0 Ладно, проехали. Вернемся в начало. Сколько у вас в браузере надстроек? Чего откуда качают, где взяли? Если не в курсе, то http hijacking может быть произведен с сайта , который вы просматриваете в этом же браузере паралелльно. Ну как будто мало возможности hijacking'а посредством бекграунд реквестов браузера самого. Вы по RSS кстати каналы читаете? Они тоже если чего в бекграунде выполняються читаются, У ВСЕХ БРАУЗЕРОВ. Подписку то пубикуете? На RSS? Ну тоже узнать не сложно на самом деле :о)) Кроме всего прочего, в таком аспекте ОЧЕНЬ СЕРЬЕЗНЫМИ становяться атаки xss и атаки CSRF. И не надо уже днс ребиндить. Чего там за рассылки то были с Ваших айсикью? Споймали библиотечку Activex? Ну майкрософт давно писал об энтом, http://blogs.msdn.com/ie/archive/2006/10/1...patibility.aspx. Напочитайте камменты, там совсем свеженькие есть :о)) Оно касается так называемого mixed-content загружаемого в браузеры. Не помню как по -майкрсоофтовски, в файерфоксе выглядит типа "часть данных на странице не зашифрованна и может быть доступна ..." Вот это оно и случилось скорее всего с вашей ацкой, стандартные API везде, отослать по установленным каналам сообщение не сложно, если канал в это время поднят то. А hijack'нуть его при браузинге мы посмотрели как. Ну вот и все как бы вкратце. А, ну да. Помните секьюрити дядьку, который все приложения (в том числе браузер) хранил на компакте? Он все время читал по одному сайту, в одном запущенном браузере и запускал браузер с компактдиска. И прокси у него там настроен был на localhost:1, чтобы трафик открытым текстом в сеть не бегал. Я еще смеялся помнитьцца. Для особо одаренных и противоречивых могу посоветовать почитать: http://www.adambarth.com/papers/2008/barth...-mitchell-b.pdf ну если не ссцыкотно, так как адобовские приблуды лучшая мишень для реализации описанных атак :о)) http://xs-sniper.com/blog/2008/09/24/surf-...secure-cookies/ там же есть и ссылки, как проверить свой браузер на подверженность такой атаке И не надо писать про то, что No-Script включен у вас, и оно "не сработало" Про Оперу писать вообще не надо. Аутентификация в формах "зашифрованных" на незащишенной веб-странице мне не интересна , как и механизм проверки SVG запрещающий картинки, и в принципе подконтрольный запретам на java scrip, но нихера не запрещающий java аплетты. 9.63 есичо. http://crypto.stanford.edu/websec/csrf/csrf.ppt вот тут можно посмотреть про CSRF и не забивать моск про анонимность на блогхостах и форумах. Включайте побольше надстроек в браузерах, они всем облегчают жизнь! Не только Вам, нельзя быть таким эгоистом. Постите картинки, на них приятно смотреть! Меняйтесь аудио-видео файлами, заточенными под майкрософт медиаплеер, у него классный эквалайзер! (хз что еще придумать :о)) Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vinni Опубликовано 2 января, 2009 Поделиться Опубликовано 2 января, 2009 :smile20: Плюс посмотрите _ttp://resources.enablesecurity.com/resources/Surf%20Jacking.pdf Кстати, этот мужик сделал расширение для FF, чтобы показывать сайты с небезопасными куками прямо в строке состояния браузера. :smile3: Плохо, что этот плагин еще не блокирует такие запросы с куками по HTTP. Зато для этого можно приспособить для такой блокировки плагин 3proxy. :smile1: Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vinni Опубликовано 12 января, 2009 Поделиться Опубликовано 12 января, 2009 еще ссылка в тему - _ttp://blog.modsecurity.org/2008/12/fixing-both-missing-httponly-and-secure-cookie-flags.html - о том, как с помощью Apache+mod-security принудительно сделать куки недоступными для JS-скриптов в браузере (httponly) и куки, полученные от SSL-сервера, сделать отправляемыми только по SSL (secure). В статье описан вариант для отдельного веб-сервера, но правила легко модифицируются и можно сделать прокси на базе mod_proxy для всех веб-серверов. Но надо будет для себя или для своей локальной сети установить такой специфический прокси... :smile3: Ссылка на комментарий Поделиться на другие сайты More sharing options...
Рекомендуемые сообщения
Заархивировано
Эта тема находится в архиве и закрыта для дальнейших ответов.