Как стать автором
Обновить

Комментарии 18

По средствам разработки самыми дырявыми оказались в 2015 году приложения на Java

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

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

А это замечательно!
Возможно, это должен был быть «Маркетинг», т.к. кричать всю статью «волки-волки» (особенно умилило «100%» «чего-то там»для банковских сайтов), а потом кинуть ссылку на свой сайт — так делают «продавцы такие продавцы», а это другой поток. PS: на всякий случай позакрываю все свои «онлайн-клиенты», а то вдруг, вот прямо сейчас, все сайты всех банков начнут «армагедддец во всем мире». #ноэтожеблог
Ссылка в конце поста ведет на полные тексты наших исследований. Там просто больше графиков и подробностей для тех, кому это интересно.

Кстати, следующее исследование, которое здесь будет опубликовано, посвящено именно уязвимым банковским приложениям. Зайдите на следующей неделе, если вы всё ещё не позакрывали свои банковские клиенты.

Что касается «маркетинга»: было бы интересно узнать, какие-такие «продавцы» давали вам ссылки на свои ежегодные исследования уязвимостей веб-приложений, АСУ ТП, мобильных операторов и ДБО. Может, это были продавцы мороженого?

Ок. Что продает продавец мороженого? Правильно — мороженое. И он говорит про него.
Что продаете вы? Системы обеспечения безопасности. И вы говорите про то, что продаете — про безопасность (точнее опасность, применяя старый как мир прием «сначала дай понять, что всё плохо, а потом предложи спасенье»).

То, что вы великодушно делитесь не исходными кодами или наработанными опытом и мудростью при построении ваших аналитических систем (наверно даже великолепных по архитектуре, но этого мы не узнаем из статьи и ссылок), не подходами и приемами во избежание вышеописанных проблем, а констатацией простого факта, что всё плохо и плохо везде, делают эту информацию просто очередным бесполезным шумом, которым невозможно воспользоваться в практических целях. А что у нас информационный шум? Реклама.

И никому (ок-ок — мне) в потоке «Разработка» не интересно, что вы обнаружили 100% абстрактной уязвимости в абстрактных «банковских» и «IT» приложениях, пока не будет реальных кейсов уязвимости — методах их обнаружения и далее я повторяюсь. Ну просто нерелевантно это всё.

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

Уж извините, что помешал деньги прятать случайно не посчитал эту статью нерекламной и поделился мнением… ведь вам же интересно продвигать компанию почему-то именно в этой категории, а не просто поставить галочку об очередном посте на очередном ресурсе?
>И никому (ок-ок — мне) в потоке «Разработка» не интересно

Дело в том, что поток «Разработка» придуман недавно. Почему администрация Хабра впихнула туда наш блог, не очень понятно. Нас не спрашивали. В течение многих лет наш блог находится в хабе «Информационная безопасность». Вот это действительно соответствует нашей тематике.

Да, мы частенько публикуем материалы, которые связаны, например, с безопасной разработкой, с конкретными примерами кодов (полистайте блог). Но мы не собираемся ограничиваться одной лишь «разработческой» тематикой только потому, что месяц назад кто-то решил запихать наш блог в поток «Разработка».

Поэтому, если у вас есть претензии по поводу того, почему исследования, новости, анонсы конференций или разборы нормативных документов по безопасности попадают и будут попадать в «Разработку» — эти все претензии адресуйте администрации Хабра, которая придумала такую странную категоризацию материалов.

>Вот было бы неплохо услышать каким образом банкомат становится «тем самым банкоматом»

Скажите честно: у вас есть какие-то психологические блоки, которые мешают полистать наш блог, или просто через поиск найти наши материалы про банкомат? Вот например:

https://habrahabr.ru/company/pt/blog/244159/
https://habrahabr.ru/company/pt/blog/246449/

>или услышать про проблемы написания кода, который этого избежит

… Или может, это просто болезнь поколения — «вижу только последний пост в мобиле»? Вот вам про безопасную разработку банковских приложений. В два клика находится.

https://habrahabr.ru/company/pt/blog/271287/
Посмотрел по ссылкам. Шикарные статьи есть и вы молодцы в этом, спасибо. Речь была лишь о текущей рекламной статье, ознакомившись с которой не случилось «углубиться» в ваш мир (далее последнего поста в мобиле) и которую вы в самом деле не могли категоризовать по иному. Да, вы правы, видимо тут уже не от вас зависит, т.к. в целом вы про разработку. ps: и нет — к сожалению, я уже давненько не школьник, а жаль — еще столько нужно успеть.
У статьи должен быть эпиграф: «Бессмысленные графики дадут +10 к ощущению важности данных».

График
Каждое веб-приложение на PHP в среднем содержит 9,1 критически опасных уязвимостей, приложение на Java — 10,5. Для всех других языков программирования и средств разработки в среднем на каждую систему приходится лишь 2 критически опасные уязвимости.

На графике «какой-то показатель» уязвимостей среднего уровня равен 100% для всех языков!!!
А показатель для Критических уязвимостей противоречит комментарию. У Java этот показатель должен быть выше всех, а у Other — практически в ноль должен уходить, однако на графике совсем другая картина.
>На графике «какой-то показатель» уязвимостей среднего уровня
>равен 100% для всех языков!!!

Не для всех языков, а для всех протестированных систем. График показывает долю систем с уязвимостями данного уровня риска (по языкам). Это значит, что уязвимости среднего уровня найдены во всех приложениях — и на PHP, и на Java. При этом данный график не говорит, сколько таких уязвимостей в отдельной системе. Он просто говорит, есть они там или нет.

А если вам интересно, сколько именно уязвимостей среднего уровня найдено в системах на PHP и в системах на Java, посмотрите полный текст исследования. Там есть другой график. И сравнительная процентовка действительно разная получается.

>а у Other — практически в ноль должен уходить

Дело в том, что Other (Другие) — это не один, а несколько языков программирования, менее популярных, чем PHP и Java. Поэтому, если вам хочется узнать долю критических уязвимостей на *каждый* отдельный язык из Других, вам надо поделить общую долю в соответствующей пропорции.

Именно поэтому и получается, что общая доля уязвимостей Других языков — велика, но на каждый язык приходится гораздо меньше, чем в случае Java и PHP.

Вы лишь подтвердили мое утверждение на счет бессмысленных графиков.

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

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

В чем вообще смысл этого сравнения?

Выводов, резюме статьи вы не прикрепили, и если не сильно задумываться о правильности сравнения, то согласно вашей статье «PHP и Java — плохой выбор для реализации любых веб-систем», т.к. у остальных языков средний показатель ошибок ниже (согласно вашему комментарию), или же «На PHP — сейчас разрабатывают системы с наименьшим количеством уязвимостей».
Возможно, вы впервые сталкиваетесь с обобщенными статистическими исследованиями. В таком случае, вот суровая правда: такие исследования почти всегда представляют собой «среднюю температуру по больнице». Почитайте статистику FireEye (Mandriant Report) или Verizon DBIR.

Тем не менее, некоторые выводы из такой обобщенной аналитики сделать можно. Например, Mandiant Report 2013 рассказывается, что 100% взломанных в 2013 году компаний имели у себя регулярно обновляемый антивирус. Там не рассказано про «стоимость систем, сроки разработки и уровень подготовки специалистов». Но тем не менее, сам факт беспомощности антивирусов — интересный.

В нашем случае вывод состоит в том, что приложения на PHP в последние годы стали более безопасными. Это ровно то, что показывает обобщенная статистика. Ни больше, ни меньше.
Доля уязвимых ресурсов, функционирующих на базе Microsoft IIS, значительно возросла по сравнению с предыдущими периодами
исследований и достигла максимального значения 100%


Как это возможно? Вы утверждаете что 100% серверов на IIS уязвимы, но при этом не говорите в чем именно уязвимость. И при этом мир не рухнул, вся инфраструктура Microsoft работает, в облаке Azure все в порядке и похоже никто, кроме кроме вас не знает об этой супер дыре во всех абсолютно версиях IIS.
>но при этом не говорите в чем именно уязвимость.

Мы рассказали об этом владельцем тех систем, которые были исследованы. Относительно того, стоит ли рассказывать всему миру, у нас есть понятие «политика ответственного разглашения». Это значит, что мы расскажем о конкретных уязвимостях тогда, когда сочтём, что этот рассказ сам по себе не создаёт проблему безопасности.

Кстати, в нашем блоге вы можете найти множество подобных рассказов о конкретных уязвимостях. И можете заметить в них приписку типа «Уязвимость устранена производителем». Например:

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.

Ну то есть вы нашли уязвимости в нескольких продуктах которые хостятся на IIS, не в самом сервере от Microsoft. При этом делаете заголовок «Дырявые сервера на Microsoft IIS»
НЛО прилетело и опубликовало эту надпись здесь
Жалко что в рейтинге нет C#/ASP.Net — у него из коробки уже часть частых уязвимостей закрыта.

А вообще не в языке дело, а в кривости рук разработчиков и ограничений сроков разработки.
Поразило 100% наличие уязвимостей в банковской сфере. Хотя в данном случае непонятно что означают проценты (как и в любой маркетинговой статье). По-идее именно в этой сфере уязвимости должны быть максимально закрыты.
Какой порекомендуете сервис для небольшой проверки сайта на дырки?

По теме: странно, что у финансистов одни из самых дырявых мест, ведь как-никак бабки должны храниться «под семью замками»…
Попробуйте HP Fortify On Demand — если проект коммерческий/есть деньги
Или ручное тестирование по wiki c сайта OWASP (https://www.owasp.org) — как минимум Top 10 проверьте.
Некоторые косяки можно бесплатно проверить с помощью утилиты Approof:
http://approof.ptsecurity.ru/
Зарегистрируйтесь на Хабре , чтобы оставить комментарий