Исследование безопасности сайтов на различных CMS

    Привет, хабр! Совместно с сервисом SiteSecure мы провели комплексное исследование безопасности сайтов, разработанных на различных CMS-системах, в результате которого получили довольно интересные результаты.

    Сравнение безопасности сайтов на бесплатных и коммерческих CMS


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

    image

    Но и у бесплатных CMS ситуация с безопасностью сильно различается. Так, например, в черные списки попадает каждый двадцатый сайт на Datalife Engine. В то же время среди сайтов на CMS TYPO3 не было обнаружено ни одного зараженного сайта. Мы связываем этот с тем, что команда разработки TYPO3 уделяет значительное внимание повышению безопасности своей CMS. В частности, только в сентябре на сайте TYPO3 было опубликовано 9 новых уязвимостей, в том числе одна категории средней опасности в ядре CMS и 8 критических – в модулях сторонних разработчиков. Среди наиболее распространенных в Рунете коммерческих CMS мы не смогли выделить явного лидера – все они имели примерно одинаковое количество сайтов с проблемами.

    Методика проведения исследования


    Для исследования были выбраны случайным образом 30 000 действующих сайтов в домене RU, созданные на различных CMS. Выборка сайтов с определением типов CMS была предоставлена компанией iTrack.

    Исследование проводилось в период октябрь 2013 — январь 2014 года путем сканирования сайтов-респондентов техническими инструментами SiteSecure. В рамках исследования проводился анализ следующих характеристик сайтов:

    • Версия CMS и веб-сервера;
    • Наличие вирусов на сайте;
    • Наличие сайта в черных списках Google и Yandex;
    • Наличие сайта в черных списках Phishtank, DNSRBL, UCE PROTECT и других;
    • Корреляция между версией CMS и наличием проблем на сайте.

    Использование обновленных версий CMS


    Наблюдается заметная корреляция между использованием наиболее свежих версий CMS и наличием проблем на сайтах, как среди коммерческих, так и среди бесплатных CMS. Своевременно обновляемые версии CMS снижают риск появления проблем в среднем в два раза. Наиболее явно польза от перехода на свежие версии заметна на примере Joomla и WordPress.

    Самую последнюю версию Joomla использовали только 3% сайтов на Joomla, а самую последнюю версию WordPress использовали 15% сайтов. При этом доля проблемных сайтов на Joomla в три раза выше, чем на WordPress. Очевидно, что своевременное обновление версии CMS повышает безопасность сайта.

    image

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

    Отсутствие влияния типа веб-сервера


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

    image

    Сравнение черных списков поисковых систем


    Яндекс заносит сайты в черный список в два раза чаще, чем Google. При этом пересечение списков Google и Yandex составляет всего 10% от общего числа занесенных в черные списки сайтов.

    image

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

    Осведомленность владельцев сайтов о наличии проблем


    Одной из ключевых проблем на рынке является низкая осведомленность владельцев сайтов о возникающих угрозах.

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

    image

    Подводная часть айсберга


    В дополнение к первой части исследования мы проверили все 30 000 коммерческих сайтов на наличие в черных списках по признаку рассылки спама с IP-адреса, на котором размещен сайт. О масштабе проблемы, которую мы обнаружили, мы считаем важным рассказать. Почти 15% всех проверенных сайтов находятся в одном из списков UCE PROTECT, то есть непосредственно участвуют в рассылке спама или находятся по соседству с сайтами, которые рассылают спам. При этом 70% сайтов находятся в одной подсети, а 28% — на одном IP адресе с сайтами – источниками спама.

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

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

    – Владельцы 4500 сайтов, участвовавших в исследовании, подвержены риску финансовых потерь из-за имеющихся на сайте проблем. Это почти каждый седьмой сайт.

    В заключение стоит сказать, что разработчики сайтов (веб-студии и агентства) зачастую не следят за вопросами безопасности, надеясь на надежность встроенных инструментов в CMS/фреймворке. При возникновении проблемы любого рода клиент, тем не менее, винит именно разработчика. Поэтому использование онлайн-сервисов для мониторинга и защиты сайтов вроде SiteSecure может закрыть проблемную зону и избежать конфликтов с заказчиком.
    RUWARD
    Company
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 84

      +6
      Для исследования были выбраны случайным образом 30 000 действующих сайтов в домене RU, созданные на различных CMS.


      доли всех CMS в этой выборке были одинаковы?
        +1
        Доли были одинаковы, конечно. На первом графике — это доля в общем числе зараженный сайтов, а не общий процент зараженных на конкретной CMS.
          +2
          Достаточно «сферическое» тестирование, «в сильно разреженной атмосфере», если вы понимаете о чем я.

          Поясню, почему я так утверждаю…

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

          Помимо прочего не понятно как определялись версии CMS, т.к. далеко не все выдают это в открытом виде (но о корректности определения написали ниже).

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

        +2
        Для исследования были выбраны случайным образом 30 000 действующих сайтов в домене RU

        Надеюсь, количество сайтов на каждой из представленных CMS в выборке было примерно одинаковым? После процитированной фразы закрадываются сомнения. Просто процентное соотношение бралось от общего числа сайтов, и при таком раскладе это очень важный момент.

        PS: я обновлял страницу перед отправкой комментария, там ничего было…
          0
          Количество было одинаковым. На первом графике — доля системы в общем числе зараженных сайтов, а не общий процент зараженных на конкретной CMS.
          +4
          Не совсем понятно что за проценты: процент зараженных сайтов из 30К или процент зараженных сайтов из всех сайтов на данной CMS?

          Меня ОЧЕНЬ смущает то, что никакого реального анализа угроз авторами не было проведено: есть вирус по данным «Васи Пупкина» — считаем. Ложнопозитивные и ложнонегативные результаты могли бы ОЧЕНЬ сильно изменить статистику, особенно первые.
            +19
            Легенда возле графиков нечитаемая вообще.
              +18
              Не только легенда — первая диаграма содержит всего три цвета с небольшими оттенками в ту или иную сторону. Такое впечатление, что это такой специальный тест для дальтоников
                +1
                Я дальтоник, например. :(
                0
                Коллеги, да, с цветами не очень вышло. Но на основной странице исследования www.ruward.ru/sitesecure/ графики интерактивны — там смотреть проще…
                  +1
                  Я пипеткой тыкал. Иначе не разобрать
                    0
                    воистину пути его неисповедимы!
                    а увидеть логику в порядке цветов в легенде и на графе не проще было?
                  +1
                  Интересно было бы узнать, как технически определялась CMS конкретного сайта? Как мне кажется, парсингом HTML?
                    +1
                    Составить выборку нам помогли коллеги из iTrack, у них есть специальный сервис: itrack.ru/whatcms/
                      +9
                      Судя по тому, что на введённом для примера самописном сайте он нашёл NetCat, я бы ему не стал сильно доверять.
                        +4
                        А на demo.advantshop.net не нашел AdvantShop.Net, хотя в списке у них эта CMS представлена.
                          0
                          RBC Contents не смог определить, хотя у них есть эта CMS.
                        0
                        Разработчиков CMS как-то оповещали об обнаруженных проблемах?

                        Так исторически сложилось, что на одном из моих сайтов стоит Datalife Engine (лицензия), которую периодически взламывают, каждый раз через 3-5 месяцев после релиза. При этом дыры я закрываю, безопасность соблюдаю, обновляюсь регулярно.
                          0
                          Да, с рядом вендоров коллеги из SiteSecure плотно общаются сейчас по проблемам.
                            +2
                            Это самая дырявая CMS из всех, с которыми приходилось работать. И ведь деньги за нее платились, а сколько не обновляйся, сколько патчей не ставь, все равно какая-нибудь зараза да проникнет.
                            +21
                            Как-то подозрительно отсутствие Друпала в списке популярных CMS
                              0
                              Видимо, не нашли зараженных экземпляров. Либо с выборкой не повезло, друпал должен быть по сути.
                                +1
                                Всё просто! В Друпале (в отличие от других систем), настолько железобетонная защита, что его просто невозможно заразить )))
                                Поэтому он даже в отчет не попал.
                                  0
                                  Как и ещё более 39 CMS из известных itrack'у
                                    0
                                    Да уж… У него только успевай обновляться — пекут security patches, как пирожки
                                  +1
                                  По результатам исследования сайты, использующие, бесплатные CMS в среднем в четыре раза чаще подвергаются заражениями и попадают в черные списки, чем сайты на коммерческих CMS.
                                  '
                                  Из первой диаграммы неосведомленному человеку понять кто из представленных CMS бесплатный, а кто нет — невозможно.
                                  Связано ли то, что сайты на бесплатных CMS подвергаются заражению чаще, чем сайты на платных CMS с тем, что сайтов на бесплатных CMS больше, чем на платных? Без указания количества сайтов по каждой из CMS в выборке и отдельных диаграмм для платных и бесплатных CMS все диаграммы в статье доверия не вызывают.
                                    0
                                    В анализе участвовало одинаковое количество сайтов на каждой CMS.
                                    +5
                                    Я считаю не совсем корректно делать такой анализ, логика проста: надежность сайта напрямую зависит от квалицикации разработчика его создавшего, от того как настроен сам вебсервер, от того как оперативно обновляется CMS на конкретном сайте, от того сколько сторонних модулей было установлено или написано для сайта и каково качество их кода.
                                    Ибо сайты сделанные по принципе фриланс => фрилансер с опытом несколько месяцев => joomla => +20 сторонних модулей => сдача проекта => забыли на год 100% приводит к образовыванию в сайте огромного количества дыр и врятли тут всю ответсвенность можно возможить на cms.
                                      +1
                                      Да, это отчасти так — очень многое зависит от разработчика. Но общий срез по рынку это не отменяет.
                                        0
                                        К первому графику я могу добавить, что группа CMS набравших 3,4% это долбно мощные решения, порог вхождения в которые достаточно велик и абы какой фрилансе делать на них сайты не возьмется, тем более платность CMS тоже сильно урезает круг желаюших её использовать в каждодневной работе, отсюда процент сайтов с кучей сомнительных модулей и самописного кода плохого качества у этих CMS весьма низок отсюда и такие хорошие показатели.
                                          +2
                                          Вобщем-то, вы абсолютно правы. Например, похожий вывод мы явно пишем по второму срезу «Одной из гипотез авторов исследования является то, что сайты на коммерческих CMS чаще разрабатываются силами профессиональных разработчиков, которые своевременно следят за обновлением версий, что приводит к большей доле зараженных проектов на бесплатных решениях.»
                                            0
                                            Не забывайте, маркетологи коммерческих CMS еще и часто довольно навязчиво предлогают обновления своих продуктов в отличии от бесплатных CMS. Хотя в данной сфере навязчивость наверное даже не плохо.
                                      +6
                                      Вопрос! «Выборка сайтов с определением типов CMS была предоставлена компанией iTrack». В списке на сайте компании есть MODx и Drupal. Они не участвовали в вашем исследовании, или их доля на рынке столь мала, или нет зараженных сайтов с их использованием?

                                      И еще вопрос про первую диаграмму. Не совсем понятно что на ней изображено. Вот есть множество всех обнаруженных при исследовании зараженных сайтов. На диаграмме — доля каждой CMS в этом множестве? Если да, то лучше назвать «Доля в зараженных сайтах», чтобы не возникало второй трактовки.

                                      Вторая трактовка такая: Есть некоторая CMS foo. Во множестве всех исследованных сайтов количество сайтов с этой CMS count(foo), а количество проблемных сайтов — bad(foo). На диаграмме нарисована доля зараженных сайтов, то есть bad(foo)/count(foo). Но тогда совершенно не понятно, как сумма этих показателей для различных CMS равна примерно 100% и зачем их рисовать на круглой диаграмме.

                                      PS Сорри, слишком долго писала, ответы есть выше. Удалять коммент уже не буду.
                                        +4
                                        Используйте MODx ))
                                          –2
                                          MODx крут, но для некоторых задач тяжеловат. Всё-таки интересно, он был в исследовании или нет?
                                            0
                                            Terekhov,22 января 2014 в 16:07
                                            В анализе участвовало одинаковое количество сайтов на каждой CMS.

                                            Полагаю, что был, т.к. в списке itrack он есть.
                                              +1
                                              Извините, но «модекс тяжеловат» какой? Революшн — возможно, хотя он больше каркас (framework). А Еволюшн для динамичных визиток очень даже шустр.
                                              Очень печалит отсутствие упоминания в тесте. Очень.
                                                0
                                                Имелся ввиду Revolution в сравнении с микрофреймворками, которые обычно использую для создания визиток. Даже Revo больше похож на CMS, чем на фреймворк, потому что можно собрать полноценный сайт без программирования (и даже не представляя, что это такое — программировать). А вот порог вхождения для разработки собственного модуля заметно выше, чем в других фреймворках, на мой взгляд.
                                                +4
                                                Тяжеловат? И это после того как в статье упоминаются Битрикс и Джумла???
                                                  0
                                                  Хи-хи, я же не говорю, что самый тяжелый. Для простейших визиток чем меньше лишнего кода — тем надежнее и безопаснее. (Имеется ввиду код для реализации возможностей, которые не используются и на визитке ООО «Рога и копыта» с вероятностью 90% по ряду причин не будут востребованы никогда).
                                                0
                                                Мне кажется что MODx скорее CMF всё же. Там конечно есть админка и всё-такое, но её нельзя поставить, как например wodpress, скачать шаблон и использовать.
                                                  +1
                                                  Все бы так думали, а то на вопрос на собеседовании, какие фреймворки используешь говоришь что MODx — на тебя смотрят и говорят, что это типа Джумлы? какой же это CMF… не. нас интересует именно CMF's…
                                                    0
                                                    В этом отчасти виноваты сами MODX Team :) Которые пытаются его позиционировать как CMS :)
                                                    +1
                                                    Не совсем с вами согласен. Здесь надо разделить modx revo и evo. Первый поддерживает скачивание и установку стандартных шаблонов. Второй идет к этому.
                                                    Установка чуть сложнее, чем у остальных, зато полная свобода в использовании и управлении.
                                                    Вот вопрос с безопасностью. В MODx вообще сложно накосячить так, чтобы сайт лег и не встал. За счет хранения пользовательских данных в БД и их обработки на входе — очень удобно. При этом сама система мониторит свое состояние и, чуть что, оповещает владельца.
                                                    Думаю, что MODx — это пограничное, между CMF и CMS.
                                                      +1
                                                      Чёрт возьми, вы правы! :)
                                                      Извините, это был не сарказм. Просто я действительно только что зашёл в управление пакетами и нашёл там шаблоны :) Мы всегда использовали modx только с уникальным дизайном и вёрсткой для каждого заказчика. И поэтому я их как-то не замечал :)
                                                      Да, modx это что-то среднее между CMF и CMS. Так же как TYPO3. Когда я последний раз работал с TYPO3 там точно не было готовых шаблоном. Но это было очень давно. Возможно тот, кто использует сейчас TYPO3 меня поправит.
                                                        +1
                                                        Спасибо!
                                                        Мы тоже пользуемся уникальными шаблонами, и я столкнулся с ними так: зашел на сайт modx почитать документацию по какому-то сниппету и увидел шаблоны на Zurb Foundation, подивился, и пошел внутрь. Так я осознал, что MODx по свой философии похож на линукс: у тебя есть ядро, а что ты с ним будешь делать и как — это твои проблемы. Хоть звезду смерти, хоть самокат.
                                                        Признаюсь, TYPO3 у нас не взлетел. Также как некоторые другие системы, типа jooml'ы и прочих CMS, которые очень сильно ограничивают вмешательство в работу. В этом смысле мы уже определили свой пакет: MODx, Newscoop, OpenCart, Esotalk и для внутреннего использования у нас и у клиентов Collabtive и SugarCRM.
                                                        А что используете вы?
                                                          0
                                                          Мы по-началу использовали TYPO3, но потом решили что это оверкилл. В данный момент используем только MODx и opencart :) Пока что для всего хватает. В MODx пишем свои сниппеты и плагины, а opencart пытаемся через vqmod дописывать, что не особо удобно :) Последнее время начинаем ощущать что opencart перестаёт хватать. Будем искать что-то ещё :) Буду рад если кто-то тоже поделится своим списком движков для интернет магазинов :) Ну а для внутренней кухни используем redmine, а CRM у нас встроена в программу которую использует бухгалтерия.
                                                            0
                                                            А Collabtive вы используете адаптированным или из коробки?
                                                            Есть ли там у вас древовидный список задач, комментарии к ним, хотя бы?
                                                              0
                                                              Мы collabtive используем из коробки. Комментариев к задачам нет. Для маленьких и микрокоманд — это нормально.
                                                              Думаю, что более эффективным будет использование SugarCRM, если вырубить все лишнее. Да и там есть хорошая система «допиливания» из коробки. Минус — убогая стилистика интерфейса.
                                                              0
                                                              opencart, там проблем с безопасностью меньше всего
                                                              Используем и как ecommerce систему и как CMS (с модулем ocCMS)
                                                                0
                                                                Opencart использует схему MVC. И это хорошо. Но он идёт как конечный продукт, где сложно модифицировать его собственные контроллеры. Это потом влечёт за собой проблемы с обновлениями. Как вы это обходите, если не секрет? Есть vqmod, но он не очень удобен.
                                                            –2
                                                            Вот вопрос с безопасностью.
                                                            И что вас тут интересует? Стандартные SQL-injection, XSS и т.п.? Да, этого почти нет. Зато уязвимостей рода LFI и выполнение произвольного кода — за глаза. Самое интересно, что именно
                                                            За счет хранения пользовательских данных в БД
                                                            эксплуатация банальных уязвимостей доступна только тем, кто знает MODX. Вот скажите, разве нормальному человеку придет в голову использовать такую строчку для выполнения произвольного кода:
                                                            [[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]*id:gte=`5`:then=`phpinfo();`:else=`2`:math=`?+1`]]
                                                            Хотя не спорю, после моих багрепортов это дело поправили. Но кто мешает нам задействовать 2 разных поля одной формы получая в конечном итоге запрос вида (демо на modx.com):
                                                            &aField=[[*[[*id:gte=`1`:then=`id`:else=`&bField=id`]]]]
                                                            А еще можно сделать интеграцию с RSS лентой.

                                                            Но и конечно же чтобы обезопасить себя нужно фильтровать все входящие данные. Т.е. писать что-то типа такого:
                                                            str_replace(array('[',']','`'),array('[',']','`'), $value);

                                                            При этом нужно знать еще одну особенность — сохранение пользовательских данных в ТВ параметр при определенных условиях позволяет выполнить произвольный код. Поэтому создавая документы по данным формы с фронта нужно данные фильтровать не только на предмет XSS, но еще и на наличие начальных фраз типа @ EVAL, @ SELECT.

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

                                                            Итого, MODX — Неуловимый Джо. Это еще год назад заметил один из членов сообщества MODX (не буду показывать пальцем). Таким образом, вся безопасность MODX основана лишь на отсутствии желания у нормальных ребят разбираться во всем этом бреде, т.к. вместо того, чтобы проверить парочку новых компонентов для той же самой Joomla потребуется время на взрыв стереотипов и разбор этого «удобного» до поры до времени синтаксиса.

                                                            P.S. Сорри, не сдержался. Можете дальше нахваливать MODX.
                                                              0
                                                              Для использования [[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]*id:gte=`5`:then=`phpinfo();`:else=`2`:math=`?+1`]] нужно иметь доступ к управлению контентом. Мне кажется что кто-попало не имеет такой доступ. А защита от инсайдерских атак — это уже дело другое. Поправьте меня.

                                                              Поэтому создавая документы по данным формы с фронта

                                                              Вы серьёзно так делали? Можно узнать подробнее причины которые могут подвигнуть на такое? Для хранения пользовательских данных стоит использовать сниппеты, которые будут хранить данные в своих таблицах, но никак не создавать для этого документ.
                                                                0
                                                                Для использования [[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]*id:gte=`5`:then=`phpinfo();`:else=`2`:math=`?+1`]] нужно иметь доступ к управлению контентом. Мне кажется что кто-попало не имеет такой доступ

                                                                ОМГ. Смотрите видео внимательно, а потом учите меня делать сайты
                                                                  0
                                                                  Чёрт, я понял про что вы говорите :) Никогда и нигде без особой надобности не выводил в браузер пользовательские входные данные. И видимо не зря :)

                                                                  P.S.
                                                                  И, спокойнее, уважаемый Agel_Nash, спокойнее :) Вы слишком все принимаете на свой счет :)
                                                        +5
                                                        Сайты на Drupal, TYPO3, MODx вообще не попали в список

                                                        Значит вывод делается вообще неправильный
                                                          +2
                                                          Действительно, интересно. Они просто не учитывались никак или благодаря безопасности не попали в область видимости? Если не анализировались, то обзор практически бесполезен, как и вывод о большей надежности коммерческих CMS.
                                                          0
                                                          Можно ли где-то посмотреть детальную статистику по CMS, где указаны конкретные проблемы в безопасности? Например сколько вредоносного кода (как проверяли?) обнаружили на сайтах? Какова процентная доля используемых критериев? Скажем, «Версия CMS и веб-сервера» как учитывается в исследовании?
                                                            +1
                                                            Подобный более глубокий анализ мы планируем сделать в рамках следующих исследований/срезов, более узко-направленных по сегментам.
                                                            0
                                                            А куда со второй картинки пропали 10%?
                                                              +3
                                                              Призрак чурова ) Сейчас поправим
                                                                +1
                                                                поправили
                                                              +1
                                                              Доли веб-серверов и доли найденных уязвимостей для каждого сервера совершенно не совпадают. Сравните w3techs.com/technologies/overview/web_server/all
                                                                0
                                                                Выборки разные. Да и nginx с apache часто работают в связке, так что вообще неясно, что и как считать.
                                                                  –4
                                                                  Зато ясно что IIS наиболее безопасный. Вернее разработчики, которые пишут под него в среднем менее криворукие.
                                                                  +2
                                                                  Выборки, действительно, разные. К тому же мы исследовали рунет, а статистика по ссылке — глобальная.
                                                                –1
                                                                Небольшое замечание (вдруг кому-то это не очевидно) — из статистики и заголовка (конечно, если верим этому исследованию), вроде бы следует вывод, что надо выбирать платную — хоть дороже, зато безопаснее.

                                                                Но те же факты могут быть и объяснены другой причиной. Когда Пупкин строит хоумпейдж своей аквариумной рыбке, он делает его, скажем, на вордпрессе. Потом забивает на обновления и слежение за новыми уязвимостями, да и вообще — даже забыл, что у него сайт есть. А сайт тем не менее существует, дырки находятся, его троянят, итд.

                                                                Когда в большой компании вроде Аэрофлота делают сайт — то будут две отличных от «пупкиного» примера вещи: во-первых, у аэрофлота 100500 сисадминов, программистов, безопасников, разработанные политики безопасности, куча правил и инструкций итд. во-вторых — есть деньги на CMS, и даже как-то позорно, на бесплатной системе делать сайт. Поэтому сайт Аэрофлота будет гораздо стабильнее и безопаснее сайта про рыбку. А если мы подарим Пупкину лицензию на коммерческую CMS, то все равно, у него не будет нескольких сисадминов-вебмастеров с сертификацией по этой CMS, «и вообще».

                                                                При таком раскладе, выбор в пользу платной CMS, ничуть не делает сайт безопаснее.
                                                                  0
                                                                  Итак, с точки зрения не то, что хостера, а так человека, который плотно работает с хостингами.
                                                                  Всё это личная эмпирическая точка зрения.

                                                                  60-70% всех проблем — вредоносный код в скаченных не_пойми_откуда шаблонах/компонентах.
                                                                  Еще 10-20% — увод доступов троянами и «непонятными личностями».

                                                                  Остальное — уязвимости CMS.

                                                                  Важно: не затрагивается массовая эксплуатация уязвимостьей, которая применима в принципе только в контексте конкретной CMS.

                                                                  К слову сказать, если у хостера руки из правильного места, различные php-шелы/blackmailer-ы в большинстве случаев блокируются на автомате при первой попытке использования(часто вообще до, если файл с известно сигнатурой приполз по ftp).

                                                                    0
                                                                    А как же wordpress? :)
                                                                    Мы пару раз пытались блог на wordpress поставить и заканчивалось это заражением. Последний раз пришлось его ограничить через open_basedir. И теперь в этом блоге друг с другом общаются спам-боты. А некоторые начали уже даже посты писать.

                                                                    Это ни в коем случае не попытка начать холивар. Просто мой личный опыт. Возможно я просто не умею его готовить :)
                                                                      0
                                                                      А причем тут спам боты и заражение, они в коментариях общаются или я чего-то не понимаю.
                                                                      А так берете самый новый стабильный релиз WP ставите его, выставляете правильные права на файлы, делаете нормальный конект с бд, ставите пароль на админа символов 30. Не ставите сторонних обновлений если не уверены в них.
                                                                        0
                                                                        Они сами публикуют (у нас была включена модерация) свои коменты :) А некоторые особо обнаглевшие стали публиковать посты :)
                                                                        Делали ровно как вы описали. Всегда ставили только самую последнюю версию. И потом в директории блога находили кучу веб шеллов. Ставили по инструкции. Пароль был конечно не 30 символов, но довольно стойкий. Возможно стоило чаще обновлять wordpress :)
                                                                          0
                                                                          Да, есть такие хостеры за $1, у которых можно получить список пользователей, прочесать /home//public_html/<стандартные конфиги CMS>. Когда таким хостерам об этом сообщаю, они молча стирают твой аккаунт с сервера, возвращают платёж и всё.
                                                                            0
                                                                            Значит что-то не так ставили, блогов на WP сотни тысяч и я не особо вижу что-бы на них был такой ужас со спам ботами.
                                                                              0
                                                                              А некоторые особо обнаглевшие стали публиковать посты :)

                                                                              Фантастика :)

                                                                              Чаще всего ломают через установленные сторонние плагины.

                                                                              Своевременно обновляйте WP и все будет хорошо.
                                                                                0
                                                                                Я обычно вебшелы находил рядом с плагином akismet. Он, вроде как, идёт по-умолчанию. Может быть конечно совпадение…
                                                                        0
                                                                        Datalife Engine занимает такую долю по зараженности благодаря зараженным дистрибутивам, распространяемым на варез-сайтах.
                                                                          +2
                                                                          Сделайте, пожалуйста, график «доля CMS у которых нет проблем с безопасностью», чтобы видеть лидеров а не аутсайдеров :)
                                                                          Порадовал Drupal. Даже у сайтов с версией, не обновляемой почти 3-4 года — нет проблем.
                                                                            0
                                                                            Похожая ситуация и с TYPO3, примерно такой же период работаю с ним и никаких проблем.
                                                                            +4
                                                                            image
                                                                            блин глаза сломаешь пока поймешь какой оттенок к какой легенде относится. вы про зеленый, розовый, серый и массу других отличающихся от предложенных оттенков слышали?
                                                                              +1
                                                                              Хотелось бы увидеть нечто подобное про php фреймворки…
                                                                              промазал веткой
                                                                              0
                                                                              В instantcms цифра такая большая не из-за проблем системы, а из-за большого количества nulled компонентов, которые ставят себе юзеры.

                                                                              Only users with full accounts can post comments. Log in, please.