В ходе тестирования на проникновение, аудита безопасности и других работ, выполненных экспертами Positive Technologies в 2010 и 2011 годах, собралась статистика по защищенности более сотни корпоративных веб-приложений. Именно приложений, а не сайтов-визиток. Сайты электронного правительства, системы интернет-банкинга, порталы самообслуживания сотовых операторов — вот далеко не полный список объектов исследования.
Анализ результатов работ помог нам найти ответы на извечные вопросы ИБ:
- сколько сайтов заражено «зловредами»?
- какая CMS безопасней — коммерческая, OpenSource, или проще разработать самому?
- что безопасней — Java, PHP или ASP.NET?
- выполнить требования стандарта PCI DSS– миф или реальность?
Ответы на некоторые из этих вопросов нас, признаться, удивили. Подробности — под катом.
Потенциально опасны?
Да! Мы нашли уязвимости во всех проверяемых нами веб-приложениях, при этом две трети ресурсов содержали критические уязвимости. На графике — топ-10 уязвимостей с указанием долей уязвимых сайтов.
Кого пожрали вредители
10% сайтов оказались заражены «зловредами». Какие уязвимости этому способствовали? Подозрение падает в первую очередь на выполнение команд ОС, а также на внедрение SQL-кода и некорректные разрешения файловой системы. Инфицированные сайты гораздо чаще содержат эти уязвимости. Для уязвимости «Выполнение команд ОС» разница весьма заметна: почти все зараженные сайты (92%) были уязвимы — в отличие от сайтов без вредоносного кода (21%). В итоге каждый третий сайт с этой уязвимостью оказался заражен вредоносным кодом.
CMS: стоит ли платить за безопасность?
Всем давно хотелось узнать, можно ли использовать CMS с открытым кодом и не стоит ли раскошелиться на коммерческую? или даже разработать самостоятельно? Наше исследование показало, что сайты, построенные на системах собственной разработки, содержат большее количество критических и других распространенных уязвимостей, чем сайты на коммерческих и свободных системах. Плюсом их оказалась, как ни странно, защищенность от малвари: несмотря на множество уязвимостей, они менее подвержены «случайному» взлому в рамках массовой атаки с использованием автоматизированных средств, поскольку никто не возьмется писать эксплойт в надежде «наткнуться» на вашу CMS. Для открытых систем это стало большой проблемой: почти четверть оказались заражены.
Итак, CMS собственной разработки напоминают старое решето и плетутся в хвосте. А что же коммерческие и open-source? Рассматривая самые распространенные и самые опасные уязвимости, приходим к выводу, что различия не так уж и велики. Каждая группа лидирует в своем наборе уязвимостей. Например, уязвимыми для внедрения SQL-кода чаще оказываются коммерческие CMS. Но если вы уверены, что попытки внедрения SQL-кода вам не страшны, — выбирайте коммерческие CMS (у них первое место по защищенности в общем зачете). Выполнение команд ОС, межсайтовое выполнение сценариев (XSS) и внедрение нулевого байта — удел свободных систем. А по уровню устойчивости к обходу каталога и межсайтовой подмене запросов (CSRF) — здесь боевая ничья. Критическая уязвимость «Удаленное включение файлов» была выявлена исключительно на ресурсах с CMS собственной разработки.
Зрим в корень
Известно, что «дырявость» сайта определяется еще в момент выбора языка. Различия в этом смысле потрясающие: системы на PHP в 81% случаев содержат критические уязвимости, на Java — в 59% случаев, а на ASP.NET — только в 26%.
Кто чего боится? Ресурсов на ASP.NET, уязвимых для обхода каталога, не оказалось вообще! Для выполнения команд ОС были уязвимы только 4%. А вот межсайтовому выполнению сценариев почти в два раза реже прочих подвержены сайты на Java. С небольшим отрывом Java выигрывает у ASP.NET и в чемпионате по защищенности от внедрения SQL-кода, а PHP грустно машет им ручкой (61% уязвимых сайтов — доля почти в три раза выше, чем у конкурентов). Та же история с CSRF: сайты на PHP уязвимы в два раза чаще. Ну а внедрению нулевого байта оказались подвержены и вовсе одни только PHP-сайты.
Куда текут деньги по проводам
Рассмотрев веб-ресурсы финансового сектора, мы пришли к выводу, что ситуация весьма удручающая. Только в 10% случаев владельцам удалось выполнить требования PCI DSS к защите веб-приложений. Хорошо хоть, что переполнения буфера никто не допустил. А вот некорректная обработка ошибок характерна для 76% (!) приложений.
В то же время анализ систем дистанционного банковского обслуживания показал, что в них устранены практически все критические уязвимости. Только 1% уязвимостей ДБО связан с высоким уровнем риска.
P.S. Данные собраны в ходе работ по анализу защищенности веб-приложений, проведенных Positive Technologies в 2010—2011 годах. Оценка защищенности проводилась ручным способом методами черного и белого ящика с использованием вспомогательных автоматизированных средств. Для классификации уязвимостей применялась система Web Application Security Consortium Threat Classification (WASC TC v. 2) — за исключением ошибок обработки входных и возвращаемых данных и отказа в обслуживании. Степень критичности уязвимости оценивалась согласно системе Common Vulnerability Scoring System (CVSS v. 2), затем выделялись высокий, средний и низкий уровень риска.
P.P.S. У самых любознательных читателей есть возможность ознакомиться с полной версией отчета.
Автор: ptsecurity
