Современные среды разработки, как правило, обладают встроенными инструментами анализа качества кода, в том числе и с точки зрения безопасности. Нередко применяют и отдельные анализаторы с подобными функциями. Часть программистов уверена, что их достаточно. С другой стороны, все больше разработчиков используют специальные анализаторы защищенности исходных кодов. Давайте разберемся, зачем нужны такие специальные продукты.
- Введение
- Об анализе качества кода
- Важность точности и полноты анализа
- Гибкое встраивание в среду разработки
- Выводы
Введение
Уязвимые приложения — бомба замедленного действия. Год назад хакеры взломали сайт British Airways и модифицировали один из скриптов, добавив в него собственный код (JavaScript-сниффер). Были украдены данные о 380 тыс. транзакций, а British Airways оштрафовали на 183 млн фунтов стерлингов (229 млн долларов США). Ранее был похожий случай с британским провайдером TalkTalk. Эта проблема глобальна: в прошлом году доля веб-приложений с критически опасными уязвимостями увеличилась до 67%. Что делать, и как может помочь специальный анализатор защищенности? Расскажем.
Спойлер: штатные анализаторы качества кода не всегда справляются с обнаружением уязвимостей.
Об анализе качества кода
Цель анализа качества кода — выявление проблем, усложняющих его компиляцию и исполнение, таких как избыточная цикломатическая сложность (вложенные операторы, ветвления, циклы и т.п.) или дубликаты строк, а также проверка покрытия всех строк тестами. При этом некоторые системы анализа позволяют находить уязвимости на основе сопоставления фрагментов кода с сигнатурами известных недостатков безопасности и осуществлять их категоризацию в соответствии с общепринятыми классификаторами уязвимостей — OWASP Top 10, CWE, SANS Top 20.
Классические инструменты, реализующие описанный подход: SonarQube, PMD.
Однако сигнатуры — это не всё. Почему использование сигнатур уязвимостей (синтаксический анализ) является необходимым, но не достаточным?
Исследователи Positive Technologies создали фрагмент кода, где были приведены 20 абсолютно нормальных конструкций, которые используются в реальных приложениях (обращение к полям объектов, разыменование ссылочных типов, работа с переменными-замыканиями, условия, вызов преобразующих функций и т.п.). Но каждая из таких конструкций может привести к возникновению опасных уязвимостей (XSS, SQL injection, path traversal, LFI, RFI и т.п.). Мы не рассчитывали, что инструменты с синтаксическим анализом уязвимостей что-либо смогут выявить, — так и получилось. Более того, анализатор качества кода, в котором для обнаружения ошибок безопасности применяется уже более продвинутый семантический анализ, также не обнаружил в этих конструкциях ничего опасного.
Стоит отметить, что и специализированные анализаторы защищенности не одинаково полезны. Несколько уязвимостей (из 20 конструкций, упомянутых выше) обнаружил еще один популярный анализатор, однако он добавил к истинным результатам немало ложных срабатываний (т.н. false positive).
Важность точности и полноты анализа
Мы часто видим отчеты об анализе защищенности наших клиентов, сделанные популярными на рынке продуктами; в некоторых из них пропущены десятки уязвимостей. Такие неполные результаты не совсем пригодны для дальнейшего исправления сканируемых приложений. Но зачастую даже больше раздражают сообщения об уязвимостях, которые таковыми вовсе не являются, а ведь на их разбор приходится тратить драгоценное время специалистов высокого класса.
До недавних пор существовало два популярных подхода к анализу кода. Классический статический анализ (SAST) не только показывает реальные проблемы безопасности, но и дает ошибки как первого рода («ложная тревога»), так и второго («пропуск цели»). Средства динамического анализа (DAST) позволяют методом «черного ящика» проанализировать развернутое приложение с учетом специфики его конфигурации, конкретных версий используемых сторонних библиотек и фреймворков, но наиболее эффективен этот метод на этапе тестирования или в аналогичных ситуациях, когда по тем или иным причинам нет возможности анализа исходных кодов. Сами по себе, в чистом виде, эти подходы не дают должного уровня точности и полноты сканирования.
Одним из методов повышения как точности, так и полноты анализа является технология абстрактной интерпретации, которая объединяет вышеназванные подходы путем проверки динамических свойств программ во время компиляции. Для повышения точности эта технология дает возможность задействовать инструменты автоматического подтверждения уязвимости (так называемые тестовые запросы-эксплойты) и вычислить условия ее эксплуатации. Это позволяет быстро проверить возможность использования каждой уязвимости и сосредоточиться на наиболее опасных из них.
Для повышения полноты анализа с помощью технологии абстрактной интерпретации можно осуществлять поиск так называемых уязвимостей нулевого дня, то есть изъянов, отсутствующих в базах данных сигнатур.
Нужно понимать, что анализаторы защищенности не призваны искать уязвимости нулевого дня в Windows и других популярных продуктах, за обнаружение которых платят десятки тысяч долларов в рамках bug bounty (хотя в нашей практике был случай обнаружения заказчиком именно такой уязвимости, за которую известный разработчик заплатил премию). Речь идет об анализе тех систем, к которым приковано гораздо меньше внимания исследователей, вследствие чего они нередко изобилуют уязвимостями разной степени сложности. (Например, в 2018 году крайне низкий уровень защищенности имели 61% исследованных нами онлайн-банков.) В базах уязвимостей таких брешей нет, и простые анализаторы не располагают возможностями по обнаружению подобных ошибок. В свою очередь, более сложные инструменты зачастую недостаточно эффективны и грешат ложными срабатываниями.
Технология абстрактной интерпретации объединяет лучшие стороны SAST и DAST. Использующих эту технологию анализаторов защищенности пока немного, и почти все они созданы в научно-исследовательских целях, не отличаясь удобством использования (исключением можно назвать PT Application Inspector). Абстрактная интерпретация позволяет смоделировать потоки данных и управления в приложении, включая поведенческие свойства программы (ее семантику), и выявить уязвимости с минимумом ложных срабатываний.
Гибкое встраивание в среду разработки
Разработчики часто полагают, что при внедрении анализатора защищенности им придется удалять или дорабатывать другие средства анализа кода. Но это не так. Современный анализатор защищенности должен быстро и бесшовно встраиваться в среду разработки. Никаких конфликтов со средствами анализа качества кода быть не должно.
Опасения разработчиков можно понять. Процесс создания кода, несмотря на общие черты, в каждой компании уникален. Интеграция в цикл разработки дополнительного звена сопряжена с риском — если это звено непригодно к встраиванию в существующие процессы. Поэтому в анализаторе исходных кодов крайне желательна штатная поддержка интеграции с современными системами CI/CD: Jenkins, TFS, TeamCity и другими. Это позволяет автоматизировать процесс поиска уязвимостей на этапе сборки приложения.
Важна интеграция анализатора и с баг-трекерами (например, Jira). Это позволяет автоматически создавать для разработчиков задачи по исправлению уязвимостей.
Выводы
Производители универсальных «комбайнов» по проверке качества кода не обеспечивают его безопасность в полном объеме. В лучшем случае это — лишь номинальная и сильно устаревшая функциональность, поэтому разумно применять специализированные анализаторы защищенности, которые позволяют обнаружить по-настоящему опасные уязвимости, легко интегрируются в процесс разработки ПО и не конфликтуют с другими средствами, задействованными в этом процессе.
При этом надо помнить, что не все специализированные анализаторы защищенности обеспечивают необходимую точность. Это приводит к частым ложным срабатываниям и к необходимости тратить массу времени на ручной анализ полученных результатов. Эффективными механизмами повышения точности на сегодняшний день являются технология абстрактной интерпретации, а также тестовые запросы-эксплойты, позволяющие доказать возможность атаки и сосредоточиться на устранении действительно опасных угроз.
