Опубликовали отчёт по результатам годичного мониторинга систем управления контентом (CMS) и других веб-технологий в Рунете. Кроме прочего, там есть граф переходов веб-узлов между разными CMS. Например, видно, что Joomla! активно теряет установки.

CMS migration



Comments Off on Ссылки: CMS в Рунете, итоги 2013 года

Опубликовано исследование распространения CMS в Рунете, включающее, кроме того, анализ использования современных веб-технологий (HTML5, различные DOCTYPE и др.). Выполнено аналитической группой RU-CENTER.

С большим отрывом побеждают Joomla! и WordPress, Drupal – третий. Там, по ссылке, опубликовано описание методики и ещё куча интересной статистики.



Комментарии (2) »

Снова спрашивают про одноразовые пароли, которые сейчас можно без особых проблем прикрутить к авторизационной системе CMS, при этом пароль генерируется специальным брелоком. Почему-то многие считают, что использование такого брелка и одноразовых паролей выводит защищённость “от взлома” всей системы авторизации на уровень, требующий физически украсть брелок – а это очень сложно и, поэтому, надёжно: типа, такой “сейф” получается (сейфы, как известно, дистанционно обычно не взламывают, нужно персонально выезжать на место). А про “токены”, выдающие пароли, говорят, мол, даже если и скопировали пароль от сайта, всё равно он – одноразовый.

Вообще, известно, что это опасное заблуждение. Так, пароли от хостингов, сайтов, и CMS, как показывает статистика работы саппорта, обычно крадут не удалённым сетевым снифером, а с помощью троянской программы, внедрённой непосредственно на ПК жертвы. Понятно, что модифицировать троянскую программу, наделив её возможностями по перехвату (до использования) одноразового пароля, – не такая уж сложная для профессионального взломщика задача. (Задача, судя по всему, много раз решена теми спецами, которые работают в направлении систем интернет-банкинга.) Конечно, механизм поддаётся полной автоматизации.

Более того, если предположить, что “многоразовый” пароль крадётся из открытой сети – обычно в пример приводят общедоступный Wi-Fi, – то в этом случае атакующий может вмешаться в трафик, перенаправить атакуемого на другой ресурс и там запросить у него хоть бы и сразу пять-десять одноразовых паролей впрок (тоже схема не новая). Есть и другие способы борьбы с “одноразовыми”.

Да, конечно, брелок-генератор одноразовых паролей – вещь полезная. Если правильно встроен в процесс пользования системой авторизации (SSL никто не отменяет!), то защищённость повышает, но сводить всё к необходимости кражи брелка – это большая ошибка. Система с таким брелком не надёжнее, чем защита компьютера, который используется для ввода одноразовых кодов-паролей.



Комментарии (7) »

Рейтинг CMS от iTrack – довольно странный: не приводят количества сайтов в выборке (типа, 2 млн доменов второго уровня .RU обошли, хотя там не все делегированы, много сайтов на третьего уровня доменах) и не публикуют, на скольких сайтах из выборки установлены коммерческие CMS. Без этих данных рейтинг бесполезен.

Особенно забавно выглядит “подробное” описание методики: не публикуется список “сигнатур”; куча странных для изложения методики исследования фраз, типа “…учитывались домены, ответившие в течение 4 секунд на запрос по адресу http://domain.ru.” (какой запрос? почему в течение 4 секунд? что значит – “ответивший домен”? и т.п., и т.д.) Очень сомнительно.

Впрочем, довольно занимательна вот какая “аппроксимация”: S.Builder пишет на сайте, что на их CMS сделано более 3500 сайтов. Предположим, что сайтов 3500, и это всё сайты на доменах второго уровня в .ru (наилучший для рейтинга вариант). В рейтинге iTrack у S.Builder – 4% от всех коммерческих CMS. Это даёт оценку количества всех сайтов на коммерческих CMS в 87500 (понятно, что всё приблизительно). То есть, если продолжать в терминах рейтинга iTrack, общая доля всех платных CMS – всего около 4.4% от объёма сайтов. В десять раз меньше, чем у WordPress, например. (Реально, я думаю, платных российских CMS использует ещё меньше, чем 4% от всех сайтов.)

Кросс-пост отсюда: http://1.dxdt.ru/2009/07/20/



Комментарии (1) »

Jus fi, flickr До сих пор в Интернете популярна авторизация по IP-адресу, например в тех же CMS (но не только). Например, помимо предъявления авторизационного куки-файла, для авторизации требуется, чтобы и запрос был с заданного IP-адреса, скажем с того же, с которого делался логин, породивший куку, или просто готовится “белый список” допустимых IP-адресов.

С одной стороны, это увеличивает “стойкость”, так как, на первый взгляд, если злоумышленник “угнал куки” или подслушал снифером пароль, то авторизоваться в системе со своей машины он не сможет, так как у этой машины, предположительно, другой IP-адрес.

А вот с другой стороны в реальности есть хитрости. Например, пользователи, которым требуется авторизация в “защищаемой системе”, могут располагаться за тем или иным NATом – это приводит к тому, что извне IP-адрес соединения пользователя будет выглядеть другим, нежели внутренний адрес этого пользователя. Но не это главное. Главное, что “внешний” адрес разделяется между многими пользователями внутренней сети, то есть с точки зрения внешнего сервера разные компьютеры всех этих пользователей будут выглядеть как имеющие один и тот же IP-адрес. Это сейчас очень и очень распространённая ситуация и в корпоративных сетях, и у “домовых” интернет-провайдеров: IP-адреса – ресурс дефицитный. При этом пользователь, не будучи подкован в технических вопросах, может и не подозревать о том, как хитро всё работает и что он разделяет с соседями один “внешний” IP-адрес.

Теперь приплюсуем сюда такой момент: прослушивать, с целью похищения “куков и паролей”, сетевой трафик данного пользователя минимальными затратами, скорее всего, могут его соседи по сети (скажем, “хакеры-пионеры” балуются в плохо настроенных “домовых сетях”). Выходит, что похитивший авторизационные данные нехороший сосед, очень вероятно, автоматом имеет возможность работать с внешним сервером с того же IP-адреса, что и пострадавший пользователь.

Так что на практике дополнительная авторизация по IP-адресу хоть и работает хорошо, но уже не выглядит панацеей.

Интересен и другой практический эффект: в системах онлайн-голосования за всякие рейтинги и конкурсы запрет повторного голосования с одного IP-адреса в течение некоторого отрезка времени (типа, защита от накруток, вспоминаем “Премию Рунета”) приводит к тому, что множество добросовестных пользователей вообще не могут проголосовать (они, волей админов, сидят за общим “IPшником”), а владелец среднего ботнета (или социальной сети) элементарно накручивает голосовалку, действуя с набора разных IP-адресов, да ещё и с нужным разбросом по времени.



Комментарии (5) »

padlock by Augapfel, Flickr Вновь приходится слышать от разработчиков CMS старую песню: “мы закрываем исходный код, потому что там наверняка уязвимости, а в закрытом коде найти их сложнее”. Речь о коммерческой CMS, о PHP, а “закрывают код”, понятно, с помощью Zend Optimizer.

А вот интересно разобраться, кому в действительности нужно, чтобы код был закрыт подобным образом. Разбираемся. Например, раз уязвимости есть (а они есть), то наверняка среди них полно шаблонных решений. Разработчики-то, собственно, нормальные, как и у других продуктов, поэтому нужно ожидать неистребимых SQL injection и далее по списку. То есть, обнаружению и использованию типичных уязвимостей закрытый код не помешал. Не удивительно – ведь от того, что код закрыт, дыры не исчезли, их просто хуже видно.

Но это одно дело. Теперь предположим, что некий квалифицированный специалист-хакер решил найти особую дыру в данной конкретной CMS. CMS эта не самая распространённая, а значит специалиста заинтересовала не просто так, но с точки зрения атаки конкретного сервера. Потому что ради спортивного интереса специалисты не работают по мелочи, а вот под заказ – вполне. (Заказ может быть и “имиджевым”, кстати. Для этого сайт-цель должен быть очень известным.) Специалист либо приобретает демо-версию, либо покупает лицензию – и, так как он специалист, “раскрывает для себя” исходный код и исследует его. То есть, особенных препятствий нет, и специалисту “закрытый код” не очень помешает – всё ж технологии используются известные. Так что опять концепция “спрятанных под Zend`ом дыр” промахивается.

А вот “хакеры-дети” (“пионеры”), которым не все технологии понятны – может, им помешает “закрытый код”? Нет, оказывается, что “пионеры” либо используют готовый инструментарий, который ищет шаблонные уязвимости (от доступности исходных кодов не зависят), либо просто отправляются атаковать другой сервер. Предположить, что этот тип атакующего станет тратить сутки на тщательный аудит кода одной CMS, когда на сайтах вокруг полно других соблазнов, будет, мягко говоря, странным – потому что это уже не начинающий хакер выходит, а тот самый спец, работающий под заказ. То есть, “закрытый код” тут просто не играет роли, которую ему приписывают.

Итак, против кого работают “спрятанные дыры”? Оказывается, что только против добропорядочных веб-мастеров и админов, которые хотели бы поверхностно взглянуть, что же там внутри CMS, которую планируют поставить на свой любимый сервер. Хотя бы с целью оценить стиль, прикинуть возможности “адаптации”, а вовсе и не для поиска дыр. Для них создаются дополнительные трудности, вполне ощутимые.

А выгода, естественно, у разработчиков: во-первых, спрятаны от глаз потребителя дыры, огрехи и неряшливый код; во-вторых, можно списывать ошибки и проблемы на сопутствующие технологии, потому что потребитель-то в исходный код пальцем ткнуть не может; ну и, в-третьих, можно и в ус не дуть, считая что система лучше защищена, потому что Zend все глубокие архитектурные дефекты попрятал.

Так вот. Требуйте открытых исходников CMS – проще будет эксплуатировать ПО.



Комментарии (23) »

tools Кстати, особенностей CMS касается вот какой момент. CMS, в подавляющем большинстве случаев, служат для управления веб-сайтом, который предназначен для публикации (то есть распространения) данных через Интернет – всё это очевидно. Так что “дыра”, уязвимость в CMS годится не только для того, чтобы просто “взломать сайт”. Как показывает практика, нынче уязвимость CMS оказывается более востребованной в качестве инструмента рассаживания червей и вирусов с добропорядочного сайта.

Работает инструмент так: получив достаточно прав по управлению сайтом, злоумышленник скрытно размещает на нём зловредный программный код, таким образом, что он будет загружаться к посетителям сайта. Расчёт, понятно, делается на то, что посетители сайту доверяют и без лишних сомнений присланный сайтом вирус активируют.

Если удачно использованная злыми хакерами уязвимость в операционной системе настольного компьютера рядового клерка компании приводит к тому, что этот компьютер начинает рассылать спам и вирусы, то это небольшая имиджевая потеря для компании. Если вирусы и зловреды начинает раздавать корпоративный сайт компании, то это уже совсем другое дело, более масштабное в смысле удара по имиджу.

Более того, с рассылкой вирусов компьютером клерка админы локальных сетей могут эффективно побороться – всё ж это нетипичная активность для пользователя-клерка, легко обнаруживаемая сетевыми мониторами. В случае сайта, который специально предназначен для рассылки информации во внешнюю сеть, всё бывает не так уж и просто, обнаружить “лишний модуль” могут не сразу.

А при этом механизмы автоматического обновления всё популярнее у создателей CMS. Есть “самообновляющиеся” коммерческие CMS. Для планирования рисков, связанных с корпоративным сайтом, хорошо бы знать, откуда и как получают свои обновления эти системы? Насколько надёжен канал? Когда его захватят злоумышленники, чтобы успешно рассадить трояны по многим сайтам? Всё это хитрые вопросы. Ответы на которые ещё сложнее отыскать, если используется CMS с “закрытым кодом”, работающая неясным способом и “обложенная” изнутри какими-то якобы “защитными модулями”.



Комментарии (2) »

Часто приводят разную статистику по российским коммерческим CMS – сколько у кого установок. Измеряют, обычно, тысячами. При этом отчего-то регулярно забывают такой “масштабирующий” фактор, как отношение к реально лидирующим CMS – “опенсорсным”, тем самым искажая “ситуацию на рынке”. Между тем оценить масштабы не сложно.

Скажем, сейчас “Яндекс.блоги” “знают” около 186 000 автономных блогов (так пишет сам сервис). Беглая оценка списка плюс учёт тенденций в блогосфере позволяют ввести разумную “оценку снизу”: что-нибудь около 70% от этого числа – блоги на WordPress. То есть, уже по “Яндекс.блогам” выходит, что только WordPress – опенсорсная CMS – может записать на свой счёт около 130 000 установок в Рунете. Понятно, что реально WordPress гораздо больше, но даже и 130 тысяч – это уже другая весовая категория.

А ведь ещё есть Drupal, Joomla и т.д.



Комментарии (2) »

Безопасность веб-сайтов и окружающие эту безопасность вопросы постоянно возникают при обсуждении CMS. (CMS – это система управления контентом: программный комплекс, исполняющийся большей частью на сервере и обеспечивающий публикацию материалов на сайте, а также удобное управление этими публикациями из веб-интерфейса.) Безопасность, как “сигнальный объект”, вообще очень популярна. И, конечно, “референсы” на “безопасность” используют при продвижении тех или иных CMS (которые, кстати, бывают коммерческие и бесплатные).

Что тут нужно иметь в виду конечному потребителю, не желающему стать лёгкой добычей маркетологов? Оказывается, достаточно составить хоть и весьма общее, но строгое представление об этих самых вопросах безопасности и их связи с CMS.

Скажем, конечному пользователю весьма важно понимать, насколько “безопасный” (тут это несколько условный термин, понятно) веб-сайт ему нужен. Потому что одно дело – корпоративный сайт крупного банка, а другое – личная веб-страничка, посвящённая разведению сазанов в домашнем аквариуме. Да, безопасность, конечно, на первом месте. Но нужно понимать, что безопасность строится на оценках рисков, и верно эти самые риски оценивать для банка и для странички про сазанов. Дело даже не в наличии уязвимостей в конкретной CMS, а в том, интересен ли сайт профессионалам-взломщикам и сколь велик будет ущерб от нарушения работы сайта.

При составлении собственного представления о безопасности использования конкретной CMS нужно учитывать её отношения с уязвимостями. Тут есть свои важные моменты. Например, то, что сайты под некоторой CMS “Имярек” “за отчётный период” не были взломаны, никоим образом не означает, что “Имярек” сколь-нибудь надёжна и безопасна. Почему? Потому что отсутствие взломов сайтов ничего нам не говорит о безопасности CMS.

Понятно, что сайты под “Имярек” могли быть просто не интересны хакерам. Понятно, что внутри CMS “Имярек” может присутствовать шикарная уязвимость, которую обнаружат завтра. А послезавтра для этой уязвимости хакерская группа напишет бота, и через два дня все сайты под “Имярек” будут взломаны в одном потоке, автоматически. То есть оценить безопасность “Имярека” на основании “полного отсутствия взломов” – невозможно. А если нельзя оценить безопасность, то нельзя и прогнозировать риски.

И если отсутствие сведений о взломах не позволяет оценить безопасность, то информация об успешно залатанных уязвимостях (в том числе, что важно, использованных на практике для взломов) позволяет приступить к оценке безопасности CMS. Такой “парадокс”. Ведь если уязвимости обнаруживают, используют и латают, то это уже свидетельствует, по крайней мере, о том, что кто-то занимается аудитом безопасности данной CMS (хоть бы и хакеры), что CMS поработала в условиях “интереса взломщиков” и что CMS развивается. Конечно, плохо, если новые критические уязвимости обнаруживаются в CMS по нескольку штук в месяц, но ещё хуже, если об уязвимостях вообще нет сведений.

Вообще говоря, более-менее надёжную оценку “уровня безопасности” CMS может дать её аудит, заказанный специалистам. Но это недешёвый и трудоёмкий процесс. Впрочем, он как раз актуален для банков и вряд ли важен для “аквариумных страничек”.

Есть расхожее заблуждение, что можно “вслепую” использовать уникальную “проприетарную CMS”, разработанную специально для данного сайта небольшой дизайн-студией. Мол, “секретность” и “уникальность” внутреннего устройства такой CMS обеспечивает безопасность. В реальности же разработчики подобной CMS обычно наступают на все широко известные в кругах специалистов по взлому (и по безопасности) грабли, допуская шаблонные ошибки в архитектуре продукта. Эти самые шаблонные ошибки и станут отличным фундаментом для проведения атак даже без изучения исходного кода. Мало того, секретность исходного кода вряд ли можно обеспечить на практике: при малейшей необходимости исходники утекут. Есть много путей для такой утечки: “через хостинг”, через дыры в других программных системах, после “шаблонного взлома”. Или, скажем, исходники просто распространит создатель продукта. Главное правило таково: секретность исходного кода вообще  не добавляет безопасности системе.

Можно предположить, что CMS с открытым исходным кодом сильно безопаснее. Однако это не так. Действительно, открытый код доступен для изучения всем и вся. Вопрос тут лишь в том, как оценить квалификацию специалистов, изучавших этот код. Одно верно: сама по себе открытость исходного кода не может снижать безопасность CMS.

Важный момент: из соображений дальнейшего сопровождения CMS, из соображений развития сайта необходимо выбирать продукт только с открытым исходным кодом (пусть хотя бы этот исходный код открывают не неопределённому кругу лиц, а только экспертам), подробное обоснование – в одной из следующих заметок.

Часто приходится слышать, что коммерческие CMS якобы более безопасные, так как в коммерческих компаниях дорожат имиджем и строго следят за безопасностью. Это неверное обоснование. Да, ничто не мешает коммерческой компании делать безопасный продукт и нанимать специалистов-архитекторов ПО высокой квалификации. Однако на практике коммерческие компании старательно ограждают себя условиями лицензирования от ответственности и используют низкоквалифицированных программистов (а архитекторов не используют вовсе), потому что такое поведение позволяет максимизировать прибыль при обычно небольшом числе инсталляций коммерческой CMS. Бесплатные CMS также имеют свой имидж, которым дорожат лидеры групп разработчиков. И при этом нет никаких оснований считать, что те же программисты, приложившие руку к той или иной бесплатной CMS, не работают в коммерческих компаниях над платными продуктами.

Выбирая бесплатную CMS, следует посмотреть, насколько ровно и планомерно она развивается. Нельзя использовать CMS (платную или бесплатную), которую разработчики забросили три года назад. Интересно, что при этом нельзя и надеяться на то, что коммерческая CMS не будет заброшена компанией-владельцем: коммерческие компании тоже успешно исчезают с рынка по самым разным бизнес-причинам.

Эта заметка – начало серии записок про выбор CMS и про безопасность CMS. Продолжение – в следующий раз. Кстати, в продолжении: нужно ли выбирать распространённую CMS? Платная или бесплатная? Что со “стоимостью владения”? и всякие другие интересные моменты.



Комментарии (1) »
Записки dxdt.ru: