Статическое тестирование кода на уязвимости: каким должен быть идеальный анализатор?

Сейчас очень много говорят о методах статистического анализа кода на уязвимости. Мнений об этом явлении очень много: от рьяного отрицания эффективности способа до превознесения результативности до небес. Истина, как водится, где-то посередине. Поэтому давайте попробуем её найти, и заодно составить общее видение того, как должен выглядеть идеальный статический анализатор.

Сфера применения


Статические тестирование защищенности приложений (Static Application Security Testing, или сокращенно SAST) – это анализ кода или его части на наличие уязвимостей без реального запуска исследуемого приложения. Обычно для этого применяется специализированный софт. Люди, знакомые с работами Тьюринга, наверняка уже ехидно ухмыляются, ведь знаменитый информатик успешно доказал, что ни одна программа не может проанализировать другую и определить, будет ли её выполнение остановлено с каким-либо набором данных.

И в теории это на самом деле так. Однако на практике все несколько сложнее. Прежде всего потому, что в проблеме остановки речь идет о Машине Тьюринга – абстрактном компьютере, имеющем неограниченный запас и соответственно бесконечное количество состояний, в котором он может находиться. Отсюда и невозможность анализа.

Очевидно, что сейчас такие вычислительные системы не существуют и не будут существовать еще длительное время. Поэтому для того, чтобы рассмотреть практическое применение технологий SAST, теорию Тьюринга необходимо применить к конечным автоматам, или, проще говоря, обычным компьютерам, которые не имеют бесконечное количество состояний. И выполняемые в такой среде приложения вполне себе поддаются анализу другой программой.

Кроме того, статическому тестированию защищенности в принципе нет необходимости исследовать все возможные варианты выполнения кода, ведь для анализа безопасности необходимо исследовать лишь его часть, в которой могут содержаться уязвимости. Поэтому даже если речь идет о Машине Тьюринга, все равно будет возможно свети количество ее состояний к конечному числу для проведения SAST.

Методы статического анализа


Для анализа кода приложения на уязвимости обычно используют три подхода, как вместе, так и порознь.

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

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

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

Альтернативы SAST


Уже только исходя из названия анализа – статический – можно предположить, что он имеет и другую разновидность. Действительно, для программной проверки кода на уязвимости можно применять и динамическое тестирование (Dynamic Application Security Testing, или сокращенно DAST).

В этом случае исследуется уже выполняемое приложение. Оно запускается с определенными параметрами и переменными, после чего происходит его проверка на наличие потенциальных угроз. Недостатки способа очевидны: не всегда можно развернуть программу и прогнать на ней множество тестов. Кроме того, результаты анализа могут быть искажены предыдущими запусками исследования.

Другая разновидность тестирования – смешная, или интерактивная, IAST. В ней используется и динамический, а статический анализ. SAST моделирует потенциальные наборы входящих данных, способных привести к уязвимости, а DAST уже на основе этой информации проводит реальные тесты приложения.

Идеальный анализатор


Итак, мы рассмотрели возможности, методы и альтернативы анализаторов кода на уязвимости. Какими же характеристиками они должны обладать, чтобы максимально эффективно делать свою работу?

  • Объединение методов SAST и DAST. Как уже обсуждалось выше, одновременное использование динамического и статического тестирования существенно повышает эффективность анализа. Однако тут важно помнить, что применение обоих способов наследует и их недостатки. Поэтому программа-анализатор должна уметь гибко работать с конкретным кодом и поддерживать баланс между используемыми мощностями и временем работы.

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

  • Тестированию необходимо предоставлять возможность ручной проверки кода, особенно тех его участков, где не было получено ни подтверждения, ни опровержения наличия уязвимостей. Разумеется, во многом эти требования теоретические, и вряд ли сейчас удастся найти или создать подобный идеальный анализатор. Однако именно таким должен быть их общий вектор развития.

Что думаете?
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 1

  • UFO just landed and posted this here

    Only users with full accounts can post comments. Log in, please.