В 70% веб-сайтов есть критически опасные уязвимости, позволяющие злоумышленникам получать доступ к сайту и причинять серьёзные неприятности не только его владельцу, но и многочисленным пользователям. По средствам разработки самыми дырявыми оказались в 2015 году приложения на Java, значительно возросла доля ресурсов с уязвимостями высокой степени риска на базе серверов Microsoft IIS. При этом использование автоматизированного анализатора исходного кода позволяет выявить в 3 раза больше опасных уязвимостей, чем ручные методы анализа.
Такие выводы содержатся в исследовании компании Positive Technologies на основе статистики, собранной в ходе работ по анализу защищенности веб-приложений в 2015 году. Сравнение с данными аналогичных исследований 2014 и 2013 годов дает возможность оценить динамику развития современных веб-приложений с точки зрения ИБ. В данной статье представлены основные результаты исследования.
Источники и методика
Ежегодно специалисты Positive Technologies изучают около 250—300 веб-приложений в рамках различных работ, начиная от инструментального сканирования и заканчивая анализом исходного кода. По итогам выполненных проектов в 2015 году было выделено 30 веб-приложений, для которых проводился углубленный анализ с наиболее полным покрытием проверок. При этом учитывались только те уязвимости, которые были подтверждены путем проведения проверок на тестовом стенде.
Оценка защищенности проводилась методами черного, серого и белого ящиков — как вручную (с использованием вспомогательных автоматизированных средств), так и с помощью автоматизированного анализатора кода. Метод черного ящика означает исследование сайта от лица внешнего атакующего без дополнительной информации о системе со стороны владельца. Метод серого ящика аналогичен методу черного ящика, но в качестве нарушителя рассматривается пользователь, обладающий определенными привилегиями в системе. Метод белого ящика использует все необходимые данные о системе, включая исходный код приложений.
В настоящей статистике приведены только уязвимости, связанные с ошибками в коде и конфигурации веб-приложений. Уязвимости классифицировались согласно угрозам по WASC TC v. 2, за исключением категорий Improper Input Handling и Improper Output Handling, поскольку они реализуются в рамках множества других атак. Степень риска уязвимостей оценивалась согласно CVSS v. 2.
Исследованные приложения принадлежали компаниям, представляющим телекомы (23%), промышленность (20%), СМИ (17%), IT-компании (17%), финансы (13%) и государственные организации (10%).
Большинство веб-приложений, вошедших в выборку, разработаны на Java (43%) и PHP (30%), также встречались приложения, созданные с использованием технологий ASP.NET, Perl, ABAP, 1С и других. Приложения работали под управлением серверов Nginx (34%), Microsoft IIS (19%), Apache Tomcat (14%) и WebLogic (14%), а также под Apache и SAP NetWeaver Application Server. Примерно половина исследованных ресурсов (53%) представляли собой продуктивные системы, уже доступные пользователям через интернет, вторую половину составляли тестовые площадки, находящиеся в процессе разработки или приемки в эксплуатацию.
Самые популярные уязвимости
Недостатки как минимум среднего уровня риска были обнаружены во всех исследованных приложениях. При этом в 70% рассмотренных систем были обнаружены критически опасные уязвимости. В течение последних трех лет доля таких систем растет: в 2014 году их было 68%, в 2013 – только 61%.
Большинство исследованных приложений позволяют атаковать пользователей. В коде 80% ресурсов обнаружена уязвимость среднего уровня риска «Межсайтовое выполнение сценариев» (Cross-Site Scripting, XSS). В результате эксплуатации данной уязвимости злоумышленник может внедрить в браузер пользователя произвольные HTML-теги, включая сценарии на языке JavaScript и других языках, и таким образом получить значение идентификатора сессии атакуемого и совершить иные неправомерные действия, например фишинговые атаки.
На втором месте — утечка информации (Information Leakage): уязвимость обнаружена в каждом втором веб-приложении. 47% веб-сайтов также содержат уязвимости, связанные с отсутствием защиты от подбора учетных данных (Brute Force). Наиболее распространенным недостатком высокого уровня риска в 2015 году стала уязвимость «Внедрение внешних сущностей XML» (XML External Entities). Уязвимость позволяет злоумышленнику получить содержимое файлов, расположенных на атакуемом сервере, либо совершать запросы в локальную сеть от имени атакуемого сервера.
Средства разработки: Java не лучше PHP
В исследованиях прошлых лет PHP-приложения как правило были более уязвимы, чем системы, разработанные с помощью ASP.NET и Java. Однако на сегодняшний день картина изменилась: 69% Java-приложений подвержены критически опасным уязвимостям, а для PHP-систем данный показатель составил 56%, что ниже уровня 2013 года на 20%.
Каждое веб-приложение на PHP в среднем содержит 9,1 критически опасных уязвимостей, приложение на Java — 10,5. Для всех других языков программирования и средств разработки в среднем на каждую систему приходится лишь 2 критически опасные уязвимости.
Уязвимость «Межсайтовое выполнение сценариев» оказалась наиболее распространенной для всех языков программирования. Доля приложений, подверженных уязвимости «Внедрение операторов SQL», сократилась по сравнению с 2014 годом: тогда уязвимость была выявлена в 67% веб-ресурсов, разработанных на PHP, а сейчас встречается только в 22%.
Дырявые сервера на Microsoft IIS
Доля ресурсов с уязвимостями высокой степени риска на базе Microsoft IIS значительно возросла по сравнению с предыдущими годами и достигла максимального значения. Зато доля уязвимых сайтов под управлением Nginx снизилась (с 86% до 57%), тоже самое с Apache Tomcat (с 60 до 33%).
Веб-приложения с уязвимостями высокой степени риска (по типу веб-сервера)
Для большинства веб-серверов самой распространенной ошибкой администрирования является утечка информации. Данный недостаток был обнаружен во всех исследованных приложениях под управлением серверов Microsoft IIS. На втором месте — отсутствие защиты от подбора учетных данных.
Сайты банков и IT-компаний под угрозой
Как и в пошлом году, на всех банковских сайтах обнаружены критически опасные уязвимости. Аналогичная ситуация наблюдается в сфере IT. Положительная динамика отмечена лишь для приложений промышленных и телекоммуникационных компаний.
Доли приложений с уязвимостями высокого уровня риска для различных отраслей экономики
Рабочие системы защищены ненамного лучше тестовых
Доля уязвимых приложений, уже находящихся в эксплуатации, очень велика: более половины (63%) подвержены критически опасным уязвимостям. Такие недостатки могут позволить нарушителю получить полный контроль над системой (например, в случае загрузки произвольных файлов или выполнения команд), а также получать чувствительную информацию (например, в результате эксплуатации уязвимостей «Внедрение операторов SQL», «Внедрение внешних сущностей XML» и других). Также нарушитель может проводить успешные атаки типа «отказ в обслуживании».
Максимальный уровень риска обнаруженных уязвимостей для тестовых и продуктивных систем (доли уязвимых систем)
Анализ исходного кода лучше выявляет опасные уязвимости
Доля систем, подверженных критически опасным уязвимостям, которые были обнаружены методом черного ящика, существенно ниже, чем аналогичный показатель для сайтов, где анализировали исходные коды приложения. Однако даже для метода черного и серого ящика доля систем с опасными уязвимостями довольно велика (59%). Таким образом, отсутствие у атакующего доступа к исходным кодам не делает веб-приложения защищенными.
Доли систем с уязвимостями разной степени риска по методу тестирования
При этом среднее количество уязвимостей различного уровня риска на одну систему, выявленных методом белого ящика, существенно выше, чем при тестировании методами черного и серого ящиков.
Среднее количество обнаруженных уязвимостей на одну систему
В рамках исследования было также проведено сравнение результатов работ, осуществленных методом белого ящика вручную либо с использованием автоматизированного сканера. В среднем в каждой системе выявлено около 15 критически опасных уязвимостей в случае использования анализатора кода (учитывались только подтвержденные уязвимости), и всего 4 уязвимости — ручными методами.
Среднее количество выявленных уязвимостей определенного уровня риска на одну систему разными методами
Таким образом, анализ защищенности методом белого ящика существенно эффективнее других методов, при которых не анализируется исходный код приложения. При этом автоматизированный анализ кода оказывается достаточно эффективным, особенно если учесть объемы кода современных приложений, где используется множество библиотек.
В целом полученные данные свидетельствуют о необходимости регулярно проводить работы по анализу защищенности веб-приложений. Важно осуществлять такой анализ на всех стадиях разработки, а также регулярно (например, дважды в год) в процессе эксплуатации систем. Кроме того, приложения, уже находящихся в эксплуатации, нуждаются в эффективной защите от атак: более половины таких ресурсов (63%) оказались подвержены критически опасным уязвимостям. Эти недостатки могут привести не только к разглашению важных данных, но и к полной компрометации системы, либо выводу ее из строя. Для защиты от таких атак рекомендуется применять межсетевые экраны уровня приложений.
Полный текст исследования читайте на www.ptsecurity.ru/research/analytics/
Комментарии (18)
freetitelu
28.07.2016 18:47Возможно, это должен был быть «Маркетинг», т.к. кричать всю статью «волки-волки» (особенно умилило «100%» «чего-то там»для банковских сайтов), а потом кинуть ссылку на свой сайт — так делают «продавцы такие продавцы», а это другой поток. PS: на всякий случай позакрываю все свои «онлайн-клиенты», а то вдруг, вот прямо сейчас, все сайты всех банков начнут «армагедддец во всем мире». #ноэтожеблог
ptsecurity
28.07.2016 19:49+1Ссылка в конце поста ведет на полные тексты наших исследований. Там просто больше графиков и подробностей для тех, кому это интересно.
Кстати, следующее исследование, которое здесь будет опубликовано, посвящено именно уязвимым банковским приложениям. Зайдите на следующей неделе, если вы всё ещё не позакрывали свои банковские клиенты.
Что касается «маркетинга»: было бы интересно узнать, какие-такие «продавцы» давали вам ссылки на свои ежегодные исследования уязвимостей веб-приложений, АСУ ТП, мобильных операторов и ДБО. Может, это были продавцы мороженого?
freetitelu
28.07.2016 20:59+1Ок. Что продает продавец мороженого? Правильно — мороженое. И он говорит про него.
Что продаете вы? Системы обеспечения безопасности. И вы говорите про то, что продаете — про безопасность (точнее опасность, применяя старый как мир прием «сначала дай понять, что всё плохо, а потом предложи спасенье»).
То, что вы великодушно делитесь не исходными кодами или наработанными опытом и мудростью при построении ваших аналитических систем (наверно даже великолепных по архитектуре, но этого мы не узнаем из статьи и ссылок), не подходами и приемами во избежание вышеописанных проблем, а констатацией простого факта, что всё плохо и плохо везде, делают эту информацию просто очередным бесполезным шумом, которым невозможно воспользоваться в практических целях. А что у нас информационный шум? Реклама.
И никому (ок-ок — мне) в потоке «Разработка» не интересно, что вы обнаружили 100% абстрактной уязвимости в абстрактных «банковских» и «IT» приложениях, пока не будет реальных кейсов уязвимости — методах их обнаружения и далее я повторяюсь. Ну просто нерелевантно это всё.
Вот было бы неплохо услышать каким образом банкомат становится «тем самым банкоматом», о котором банковские «безопасники» передают из поколения в поколение опыт и боль потерянной репутации, или услышать про проблемы написания кода, который этого избежит на уровне программы (даже если злоумышленники умудряются воткнуть в картиридеры свои «подделия»). Вот тогда от вашей следующей статьи будет шикарный профит. В потоке «Разработка».
Уж извините, чтопомешал деньги прятатьслучайно не посчитал эту статью нерекламной и поделился мнением… ведь вам же интересно продвигать компанию почему-то именно в этой категории, а не просто поставить галочку об очередном посте на очередном ресурсе?ptsecurity
28.07.2016 21:28+1>И никому (ок-ок — мне) в потоке «Разработка» не интересно
Дело в том, что поток «Разработка» придуман недавно. Почему администрация Хабра впихнула туда наш блог, не очень понятно. Нас не спрашивали. В течение многих лет наш блог находится в хабе «Информационная безопасность». Вот это действительно соответствует нашей тематике.
Да, мы частенько публикуем материалы, которые связаны, например, с безопасной разработкой, с конкретными примерами кодов (полистайте блог). Но мы не собираемся ограничиваться одной лишь «разработческой» тематикой только потому, что месяц назад кто-то решил запихать наш блог в поток «Разработка».
Поэтому, если у вас есть претензии по поводу того, почему исследования, новости, анонсы конференций или разборы нормативных документов по безопасности попадают и будут попадать в «Разработку» — эти все претензии адресуйте администрации Хабра, которая придумала такую странную категоризацию материалов.
>Вот было бы неплохо услышать каким образом банкомат становится «тем самым банкоматом»
Скажите честно: у вас есть какие-то психологические блоки, которые мешают полистать наш блог, или просто через поиск найти наши материалы про банкомат? Вот например:
https://habrahabr.ru/company/pt/blog/244159/
https://habrahabr.ru/company/pt/blog/246449/
>или услышать про проблемы написания кода, который этого избежит
… Или может, это просто болезнь поколения — «вижу только последний пост в мобиле»? Вот вам про безопасную разработку банковских приложений. В два клика находится.
https://habrahabr.ru/company/pt/blog/271287/freetitelu
28.07.2016 22:08+1Посмотрел по ссылкам. Шикарные статьи есть и вы молодцы в этом, спасибо. Речь была лишь о текущей рекламной статье, ознакомившись с которой не случилось «углубиться» в ваш мир (далее последнего поста в мобиле) и которую вы в самом деле не могли категоризовать по иному. Да, вы правы, видимо тут уже не от вас зависит, т.к. в целом вы про разработку. ps: и нет — к сожалению, я уже давненько не школьник, а жаль — еще столько нужно успеть.
AndreyRubankov
28.07.2016 22:30+1У статьи должен быть эпиграф: «Бессмысленные графики дадут +10 к ощущению важности данных».
График
Каждое веб-приложение на PHP в среднем содержит 9,1 критически опасных уязвимостей, приложение на Java — 10,5. Для всех других языков программирования и средств разработки в среднем на каждую систему приходится лишь 2 критически опасные уязвимости.
На графике «какой-то показатель» уязвимостей среднего уровня равен 100% для всех языков!!!
А показатель для Критических уязвимостей противоречит комментарию. У Java этот показатель должен быть выше всех, а у Other — практически в ноль должен уходить, однако на графике совсем другая картина.ptsecurity
29.07.2016 03:51>На графике «какой-то показатель» уязвимостей среднего уровня
>равен 100% для всех языков!!!
Не для всех языков, а для всех протестированных систем. График показывает долю систем с уязвимостями данного уровня риска (по языкам). Это значит, что уязвимости среднего уровня найдены во всех приложениях — и на PHP, и на Java. При этом данный график не говорит, сколько таких уязвимостей в отдельной системе. Он просто говорит, есть они там или нет.
А если вам интересно, сколько именно уязвимостей среднего уровня найдено в системах на PHP и в системах на Java, посмотрите полный текст исследования. Там есть другой график. И сравнительная процентовка действительно разная получается.
>а у Other — практически в ноль должен уходить
Дело в том, что Other (Другие) — это не один, а несколько языков программирования, менее популярных, чем PHP и Java. Поэтому, если вам хочется узнать долю критических уязвимостей на *каждый* отдельный язык из Других, вам надо поделить общую долю в соответствующей пропорции.
Именно поэтому и получается, что общая доля уязвимостей Других языков — велика, но на каждый язык приходится гораздо меньше, чем в случае Java и PHP.
AndreyRubankov
29.07.2016 08:36Вы лишь подтвердили мое утверждение на счет бессмысленных графиков.
Ваш график показывает соотношение количества уязвимых систем из какой-то выборки сайтов с привязкой к языкам PHP, Java и с некоторому среднему показателю по больнице (по всем другим языкам).
Ваше сравнение можно описать как: Средний уровень каких-то разработчиков каких-то систем на каком-то языке Выше/Ниже, чем средний уровень каких-то других разработчиков каких-то других систем.
Стоимость систем, сроки разработки и уровень подготовки специалистов — эти переменные не учитываются.
В чем вообще смысл этого сравнения?
Выводов, резюме статьи вы не прикрепили, и если не сильно задумываться о правильности сравнения, то согласно вашей статье «PHP и Java — плохой выбор для реализации любых веб-систем», т.к. у остальных языков средний показатель ошибок ниже (согласно вашему комментарию), или же «На PHP — сейчас разрабатывают системы с наименьшим количеством уязвимостей».ptsecurity
29.07.2016 14:52Возможно, вы впервые сталкиваетесь с обобщенными статистическими исследованиями. В таком случае, вот суровая правда: такие исследования почти всегда представляют собой «среднюю температуру по больнице». Почитайте статистику FireEye (Mandriant Report) или Verizon DBIR.
Тем не менее, некоторые выводы из такой обобщенной аналитики сделать можно. Например, Mandiant Report 2013 рассказывается, что 100% взломанных в 2013 году компаний имели у себя регулярно обновляемый антивирус. Там не рассказано про «стоимость систем, сроки разработки и уровень подготовки специалистов». Но тем не менее, сам факт беспомощности антивирусов — интересный.
В нашем случае вывод состоит в том, что приложения на PHP в последние годы стали более безопасными. Это ровно то, что показывает обобщенная статистика. Ни больше, ни меньше.
mtt
29.07.2016 14:02Доля уязвимых ресурсов, функционирующих на базе Microsoft IIS, значительно возросла по сравнению с предыдущими периодами
исследований и достигла максимального значения 100%
Как это возможно? Вы утверждаете что 100% серверов на IIS уязвимы, но при этом не говорите в чем именно уязвимость. И при этом мир не рухнул, вся инфраструктура Microsoft работает, в облаке Azure все в порядке и похоже никто, кроме кроме вас не знает об этой супер дыре во всех абсолютно версиях IIS.ptsecurity
29.07.2016 14:40>но при этом не говорите в чем именно уязвимость.
Мы рассказали об этом владельцем тех систем, которые были исследованы. Относительно того, стоит ли рассказывать всему миру, у нас есть понятие «политика ответственного разглашения». Это значит, что мы расскажем о конкретных уязвимостях тогда, когда сочтём, что этот рассказ сам по себе не создаёт проблему безопасности.
Кстати, в нашем блоге вы можете найти множество подобных рассказов о конкретных уязвимостях. И можете заметить в них приписку типа «Уязвимость устранена производителем». Например:
https://habrahabr.ru/company/pt/blog/280095/
https://habrahabr.ru/company/pt/blog/276459/
https://habrahabr.ru/company/pt/blog/255929/
https://habrahabr.ru/company/pt/blog/250675/
>И при этом мир не рухнул
Лучший ответ на этот вопрос дала девочка из фильма «Семейка Адамсов»:
— Just wait.
mtt
29.07.2016 15:02Ну то есть вы нашли уязвимости в нескольких продуктах которые хостятся на IIS, не в самом сервере от Microsoft. При этом делаете заголовок «Дырявые сервера на Microsoft IIS»
zirix
29.07.2016 15:18Только меня смутили 23% sql инъекций для java? И что их больше чем у php.
Я понимаю что бывают проекты без JPA и хибернейта, но их не настолько много чтобы набрать такую статистику…
Чтобы на хибернейте сделать инъекцию надо быть редким гуанокодером.
zenkz
29.07.2016 23:10Жалко что в рейтинге нет C#/ASP.Net — у него из коробки уже часть частых уязвимостей закрыта.
А вообще не в языке дело, а в кривости рук разработчиков и ограничений сроков разработки.
Поразило 100% наличие уязвимостей в банковской сфере. Хотя в данном случае непонятно что означают проценты (как и в любой маркетинговой статье). По-идее именно в этой сфере уязвимости должны быть максимально закрыты.
pup_pupets
31.07.2016 18:43Какой порекомендуете сервис для небольшой проверки сайта на дырки?
По теме: странно, что у финансистов одни из самых дырявых мест, ведь как-никак бабки должны храниться «под семью замками»…zenkz
02.08.2016 17:03Попробуйте HP Fortify On Demand — если проект коммерческий/есть деньги
Или ручное тестирование по wiki c сайта OWASP (https://www.owasp.org) — как минимум Top 10 проверьте.
ptsecurity
03.08.2016 01:47Некоторые косяки можно бесплатно проверить с помощью утилиты Approof:
http://approof.ptsecurity.ru/
nikitasius
Рассуждать что сайты на Java дырявее чем на PHP, это в корне неверно. Не язык определяет безопасность, а программист, который на нем пишем.
На любом языка можно написать любой кривости приложение, и это не портит преимуществ языка.
И данный текст можно трактоват как:
А это замечательно!