Статистика уязвимостей веб-приложений за 2009 год

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

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

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

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

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

Анализ уязвимостей веб-приложений за 2009 год показал, что практически половина проанализированных систем содержали уязвимости. В статистике собраны данные о 5560 веб-приложениях, полученные в результате проведения 6239 автоматических сканирований и детального анализа 77 веб-приложений. Суммарно во всех приложениях было обнаружено 13434 ошибок различной степени риска, зафиксировано 1412 образцов вредоносного кода, содержащихся на страницах уязвимых систем. Доля скомпрометированных сайтов распространявших вредоносное программное обеспечение составила 1,7%. Каждый из таких сайтов содержал уязвимости, позволяющие выполнять команды на сервере, что подтверждает возможность использование этих уязвимостей для компрометации системы.

Распределение критических уязвимостей на сайтах

Основной результат исследования неутешителен. Вероятность обнаружения критичной ошибки в веб-приложении автоматическим сканером составляет около 35% и достигает 80% при детальном экспертном анализе. Этот факт демонстрирует невысокую защищенность современных веб-приложений не только от атак со стороны квалифицированных злоумышленников, но и от действий атакующих, вооруженных готовыми утилитами для "автоматического взлома".

Вероятность обнаружения уязвимостей различной степени риска

Как и ранее [1,2,3], наиболее распространенными ошибками, допускаемыми разработчиками приложений, являются уязвимости "Межсайтовое выполнение сценариев" и "Внедрение операторов SQL" на которые пришлось более 19% и 17% всех обнаруженных уязвимостей соответственно.

Наиболее распространенные уязвимости, допускаемые разработчиками веб-приложений (обобщенные данные)

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

Процент сайтов с уязвимостями различной степени риска

С точки зрения соответствия требованиям регуляторов (compliance management) ситуация улучшилась незначительно. До 84% веб-приложений не удовлетворяет требованиям стандарта по защите информации в индустрии платежных карт PCI DSS и 81% не соответствуют критериям ASV-сканирования, определенного в стандарте.

Уровень соответствия анализируемых веб-приложений требованиям стандарта PCI DSS (QSA)

Полную версию отчета в формате pdf можно скачать на сайте компании Positive Technologies: http://www.ptsecurity.ru/download/PT-WEBSTAT-2009.pdf

11 комментариев :

  1. Поздравляю с завершением! Наверное, самое сложное и интересное было проинтерпретировать полученные данные?

    ОтветитьУдалить
  2. нет:) самое сложное было согласовать документ со всеми...

    ОтветитьУдалить
  3. >согласовать документ со всеми...

    Ну-ну ;)

    ОтветитьУдалить
  4. Ознакомился с документом, и снова у меня возник вопрос.

    >> “До 84% веб-приложений не удовлетворяет требованиям стандарта по защите информации в индустрии платежных карт PCI DSS…”

    В контексте идет речь обо всех рассмотренных веб-приложениях, а не функционирующих исключительно в индустрии платежных карт. Насколько уместно приводить статистику соответствия стандарту PCI DSS, включая в нее веб-приложения, никак не связанные с «платежной» индустрией и, соответственно, должным образом не спроектированные? Другими словами, в чем заключается необходимость включения в статистику на соответствие PCI DSS всех веб-приложений?

    Еще хотелось бы узнать, какие инфраструктуры (после веб-среды) наиболее уязвимы по результатам комплексного аудита? Понимаю, что все зависит от конкретного заказчика, но, тем не менее, может быть имеется аналогичная статистика?

    ОтветитьУдалить
  5. >> В контексте идет речь обо всех рассмотренных веб-приложениях, а не функционирующих исключительно в индустрии платежных карт.

    Да, обо всех внешних веб-приложениях.

    >> Насколько уместно приводить статистику соответствия стандарту PCI DSS, включая в нее веб-приложения, никак не связанные с «платежной» индустрией

    А почему нет? Критерий соответствия PCI DSS – это некоторая метрика, по которой можно ровняться. Причем, там ведь нет каких-то заоблачных требований к безопасности. Я бы даже назвал требования PCI DSS, как минимальные требования к безопасности, выполняя которые любая компания может существенно повысить свой уровень информационной безопасности. А научившись выполнять требования PCI DSS, довольно легко перейти и к COBIT/ISO 2700x/etc.

    Поэтому критерий соответствия веб-приложения требованиям PCI DSS можно расценивать, как некий средний уровень защищенности информационной системы.

    См. уязвимости, которые рассматривает PCI DSS в отношении веб: Cross-site scripting (XSS), Injection flaws (SQLi, etc), Malicious file execution, Cross-site request forgery (CSRF), Information leakage and improper error handling, Broken authentication and session management, Insecure communications.

    Т.е. никаких экстраординарных уязвимостей или требований к безопасности веб-приложений в стандарте нет.

    >> в чем заключается необходимость включения в статистику на соответствие PCI DSS всех веб-приложений?

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

    >> Еще хотелось бы узнать, какие инфраструктуры (после веб-среды) наиболее уязвимы по результатам комплексного аудита? Понимаю, что все зависит от конкретного заказчика, но, тем не менее, может быть имеется аналогичная статистика?

    Все верно, очень многое зависит от Заказчика. Но по статистике, по внешнему периметру после веб уязвимостей находится уязвимость, связанная с использованием простых паролей для доступа к внешним системам (сетевое оборудование, протоколы удаленного администрирования, СУБД, ERP, etc). Во внутренней сети – все то же самое, но еще добавляются проблемы с разграничением сетевого доступа, много ошибок в конфигурациях различных систем и patch management. См. Trustwave Analysis of 2009 Penetration Tests. В целом, проблемы, которые описаны в этом отчете подходят и к реалиям в России.

    ОтветитьУдалить
  6. А можешь подробнее разъяснить как считается показатель "Вероятность обнаружения критичной ошибки в веб-приложении при детальном экспертном анализе".
    Мне думается, что p=x/X, где X-всего критичных уязвимостей, х-вы нашли.
    Но остается вопрос - кто тогда нашел Х? ;)

    ОтветитьУдалить
  7. >> уязвимостей, связанных с недостатками администрирования, встречается на 10% больше, чем уязвимостей, связанных с ошибками при разработке систем;

    Еще интересно, почему в статистике не фигурирует разделение количества всех веб-приложений на «самописные» и «коробочные»? И какова доля использования последних в общей статистике? Думаю, нельзя исключать тот факт, что эта разность в 10% вызвана именно использованием готовых веб-приложений/CMS (в отчете это указано).

    Спасибо. :)

    ОтветитьУдалить
  8. Дмитрий, а есть ли статистика относительно того, использование каких технологий Интернет-разработки (PHP/ASP/Java и т.д.) облегчает разработчикам совершать ошибки и допускать появление уязвимостей?

    ОтветитьУдалить
  9. to Vladimir:

    Сумма уязвимых сайтов заданного уровня риска (низкий, средний, высокий), разделенная на количество всех анализируемых веб-приложений в заданной категории (в данном случае – детальный анализ, ручные проверки).

    to c0n Difesa:

    >> Еще интересно, почему в статистике не фигурирует разделение количества всех веб-приложений на «самописные» и «коробочные»?

    Даже ведь и не задумывались об этом:) С другой стороны, "коробочные" решения со временем превращаются в "самописные". Не всегда, разумеется, но администраторам это работу только прибавляет.

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

    to Александр Дорофеев:

    Александр, соглашусь, довольно показательная метрика. К сожалению, в этот раз мы это не рассматривали. В следующем году обязательно сделаем ;)

    ОтветитьУдалить
  10. >где X-всего критичных уязвимостей

    Такой цифры не может быть потому что не может быть никогда.


    >облегчает разработчикам совершать ошибки и
    >допускать появление уязвимостей?

    Очень не люблю такие метрики, потому как они провоцирует войны основанные на вероятной неверной интерпретации.
    Пример. Поскольку php однозначно наиболее распространен - "уязвимых сайтов" и "дырок" с использованием php больше.
    Дим, если будем считать, то только нормированное к распространенности.

    ОтветитьУдалить
  11. to Сергей Гордейчик:
    Именно, что не может быть! Поэтому и спросил как считается показатель.

    to Дмитрий:
    >Сумма уязвимых сайтов заданного уровня
    >риска (низкий, средний, высокий),
    >разделенная на количество всех
    >анализируемых веб-приложений в заданной
    >категории (в данном случае – детальный
    >анализ, ручные проверки).

    Ясно. То есть это есть тоже самое что и "процент уязвимых сайтов"

    ОтветитьУдалить