Комментарии 17
Если исследование проводилось по принципу, берем apk, смотрим зависимости и прогоняем по базе owasp, то это абсолютно ничего не значит, пшик. Должны сойтись звезды и планеты выстроиться в ряд, чтобы задействовать критические уязвимости.
Требуем подробности, а не перепост новости
Сообщает РИА Новости со ссылкой на исследование российской компании по безопасности разработок мобильных приложений «Стингрей Технолоджиз».
Стингрей – платформа автоматизированного анализа защищённости мобильных приложений.
Ну да, так и было. Ссылка на новость, но полный текст исследования только по запросу.
Добрый день!
Исследование проводилось методом черного ящика, без доступа к исходному коду (что логично, учитывая, что мы скачивали приложения из публичных источников).
Проверяли при помощи нашего динамического сканера мобильных приложений "Стингрей". Если кратко описать процесс проведения исследования, то инструмент загружал приложение, устанавливал его, запускал, смотрел в динамике как оно работает и на основе собранных данных определял недостатки и уязвимости приложения. Среди всех выявленных уязвимостей мы отобрали 20-ть категорий, которые провалидировали вручную и описали подробно в отчете.
К моему большому сожалению, посмотреть зависимости в собранном приложении под Android достаточно проблематично, а вернее однозначно идентифицировать их версию (чтобы потом поискать известные уязвимости). Поэтому пока что (пока мы не нашли способ сделать достаточно качественно), результаты анализа библиотек ни в нашем сканере, ни в отчете не фигурируют, как уязвимости.
20 пишется без "-ть".
Буквенные наращения используются только с порядковыми числительными.
Буквенные наращения нужны для того, чтобы различать количественные и порядковые числительные: «2 человека» — это «два человека», а «2‑го человека» — это «второго человека».
Порядковые числительные отвечают на вопрос «Который по счёту?»: «первый», «десятый». Количественные числительные отвечают на вопрос «Сколько?»: «два», «пять». Как бы ни склонялись количественные числительные, буквенные наращения им не нужны.
По 15 уязвимостей в каждом приложении. Очень интересно узнать метод анализа.
Поиск информации по компании дал что в среднем в компании работает 1 человек. И как долго этот человек проверял 790 приложений?
Добрый день!
1 человек это давненько устаревшая информация)
Плюс, мы используем для автоматического анализа наш собственный инструмент, поэтому затраты на скачивание, анализ, запуск и всю работу с приложением, получением данных и их анализом занимался именно он. А вот провалидировать на ложные срабатывания, на это порядком времени ушло, конечно.
По методу анализа чуть более подробно есть в самом исследовании, его можно достаточно просто скачать на нашем сайте.
Интересно, а если убрать "российских"?
Думаю, если действительно как выше писали, взять апк и прогнать на зависимости с известными уязвимостями, то будет у всех приложений будет так. Особенно учитывая, что вообще 80% приложений в маркете/сторе это условный мусор. Не говорят же, что 80% от 1000 самых скачиваемых. В общем новость просто вбросили и ушли...
Интересно, а если убрать "российских"?
Вряд ли что-то сильно изменится.
Думаю, если действительно как выше писали, взять апк и прогнать на
зависимости с известными уязвимостями, то будет у всех приложений будет
так
Я в другой экосистеме, но такого типа сканеры тоже есть. Большая часть реальных проблем решается просто обновлением только версии зависимостей.
Но есть еще куча нереальных, например MD5 и псевдо рэндом может быть не безопастно в некоторых случаях, но инструмент не может понять, какой случай у тебя.
Или моё любимое, нельзя в SQL запросы вставлять значение через форматирование строк, можно только через специальные методы это делать. Только вот для имени таблицы таких методов нет и обманывай линтер как хочешь.
Когда у нас появился клиент, который гоняет свои проверки, мы дофиксили и реальные и нереальные проблемы.
Вообще надо стартовать все проекты с набором проверок. Первый раз настраивать тяжело, но потом просто таскаешь это и проекта в проект.
Абсолютно тут согласен, все сканеры из коробки работают, конечно, но их нужно очень тщательно "тюнить" и работать с запросами, по которым они уязвимости ищут.
Но если начинать все проекты сразу с практиками безопасной разработки бок о бок, то это может быть очень и очень полезно. У нас есть несколько статей на Хабр, посвященные практикам безопасной разработки, да и Application Security в целом.
Интересно, а если убрать "российских"?
Если честно, то прям вот такой же анализ мы не проводили, но по ощущениям от проектов, которые проводили по анализу защищенности приложений, все так же, а часто и хуже.
Россия на самом деле одна из лидеров в мобильных приложениях (на мой взгляд), по качеству/удобству и функционалу. Так и в части безопасности, я бы сказал, что мы одни из лидеров этого сегмента, в плане защищенности мобилок.
По способу анализа я выше чуть более подробно написал, а в самом отчет подробно разбирается каждая из 20-ти категорий, выбранных для отчета.
Ну а так в подборке много разных приложений было, конечно. И топовые и самые обычные и мусор, наверняка тоже попадался.
Реклама от каких-то непонятных чудил. Текст "исследования" только по запросу. Так не делается...
Добрый день!
Нет, ну конечно не без этого :)
Но, как один из тех, кто проводил исследование и один из главных чудил в нашей компании, что это не только реклама, но и попытка донести до разных участников процесса разработки (бизнеса, безопасности, тестирования, разработчиков), что уделять внимание безопасности мобильных приложений необходимо и это важная составляющая всей системы (особенно, учитывая, что она выполняется на устройстве пользователя).
Текст исследования не совсем по запросу, на сайте достаточно несколько полей в форме заполнить и свободно скачать отчет. Мы его не скрываем, скорее наоборот, столько труда в него вложено, что не хотелось его вообще закрывать за формой, но решили сделать так.
Выяснилось, что хозяева сервиса знают ваши логин и пароль от этого сервиса.
Да вполне логично. Еще лет 5 назад анализировали закрытые репозитории и в них были древнегреческие OpenSource библиотеки с версиями времен Царя Гороха.
Некоторые среды разработки требуют дополнительную настройку перед использованием и их обновление может быть проблематичными. Обновил одну библиотеку, перестала работать другая или устарел какой нибудь метод или функция и его убрали в новой версии - переписывай код. Многие разработчики в этом плане не могут найти время на аудит версий библиотек в силу лени, либо в силу большой нагрузки, а если учесть, что часть таких уязвимых функций разработанного приложения могут использоваться раз в столетие, но, тем не менее, времени на переработку нужно потратить не мало.
Я с данной позицией не согласен и считаю, что все библиотеки должны быть актуальной версии и подход к разработке должен быть ответственный (сейчас ведь множество средств анализа кода). Просто хотел объяснить почему так происходит.
«финансы» критические уязвимости содержат 85% приложений (117)
«развлечения» — 75% (79 приложений)
«утилиты» — 78% (96 приложений),
То есть приложения, которые связаны с финансами имеющие иногда огромный штат персонала, который занимается их разработкой и обеспечением средств защиты - более уязвимы, чем развлекательные приложения и всякого рода мелкие программы, которые делали полтора программиста? Мягко говоря - верится в это плохо.
Исследование: более 80% российских мобильных приложений содержат уязвимости высокой и наивысшей степени критичности