Сейчас очень много говорят о методах статистического анализа кода на уязвимости. Мнений об этом явлении очень много: от рьяного отрицания эффективности способа до превознесения результативности до небес. Истина, как водится, где-то посередине. Поэтому давайте попробуем её найти, и заодно составить общее видение того, как должен выглядеть идеальный статический анализатор.
Сфера применения
Статические тестирование защищенности приложений (Static Application Security Testing, или сокращенно SAST) – это анализ кода или его части на наличие уязвимостей без реального запуска исследуемого приложения. Обычно для этого применяется специализированный софт. Люди, знакомые с работами Тьюринга, наверняка уже ехидно ухмыляются, ведь знаменитый информатик успешно доказал, что ни одна программа не может проанализировать другую и определить, будет ли её выполнение остановлено с каким-либо набором данных.
И в теории это на самом деле так. Однако на практике все несколько сложнее. Прежде всего потому, что в проблеме остановки речь идет о Машине Тьюринга – абстрактном компьютере, имеющем неограниченный запас и соответственно бесконечное количество состояний, в котором он может находиться. Отсюда и невозможность анализа.
Очевидно, что сейчас такие вычислительные системы не существуют и не будут существовать еще длительное время. Поэтому для того, чтобы рассмотреть практическое применение технологий SAST, теорию Тьюринга необходимо применить к конечным автоматам, или, проще говоря, обычным компьютерам, которые не имеют бесконечное количество состояний. И выполняемые в такой среде приложения вполне себе поддаются анализу другой программой.
Кроме того, статическому тестированию защищенности в принципе нет необходимости исследовать все возможные варианты выполнения кода, ведь для анализа безопасности необходимо исследовать лишь его часть, в которой могут содержаться уязвимости. Поэтому даже если речь идет о Машине Тьюринга, все равно будет возможно свети количество ее состояний к конечному числу для проведения SAST.
Методы статического анализа
Для анализа кода приложения на уязвимости обычно используют три подхода, как вместе, так и порознь.
- Сигнатурный поиск. Самый простой метод. Основан на поиске в основном коде вхождений заданной синтаксической модели, которая приводит к возникновению уязвимостей. Очевидно, что из-за этого в качестве основного этот способ не может быть использован – слишком велика вероятность как ложных срабатываний, так и пропущенных угроз. В основном метод используется для выявления подозрительных участков кода, нуждающихся в дополнительном анализе.
- Исследование моделей выполнения кода. Куда более продвинутый способ. Основан на поиске такой комбинации обрабатываемых приложением данных, которые способны привести к возникновению уязвимости. Метод не учитывает многие факторы кода и зачастую дает ложноположительные результаты. К примеру, такой анализ может обнаружить уязвимость функции к XSS-инъекции, в то время как на самом деле поток данных успешно фильтруется и осуществление такой атаки невозможно.
- Исследование потока вычислений. Основан на использовании символических вычислений – преобразования конкретного кода в его абстрактную интерпретацию, способную эффективно работать не только с четко заданными, но и с неизвестными переменными. В дальнейшем на основе этой методики разрабатывается модель уязвимости к определенному типу атак, записанная символическим языком, что значительно упрощает и уточняет поиск проблемных мест в коде.
Альтернативы SAST
Уже только исходя из названия анализа – статический – можно предположить, что он имеет и другую разновидность. Действительно, для программной проверки кода на уязвимости можно применять и динамическое тестирование (Dynamic Application Security Testing, или сокращенно DAST).
В этом случае исследуется уже выполняемое приложение. Оно запускается с определенными параметрами и переменными, после чего происходит его проверка на наличие потенциальных угроз. Недостатки способа очевидны: не всегда можно развернуть программу и прогнать на ней множество тестов. Кроме того, результаты анализа могут быть искажены предыдущими запусками исследования.
Другая разновидность тестирования – смешная, или интерактивная, IAST. В ней используется и динамический, а статический анализ. SAST моделирует потенциальные наборы входящих данных, способных привести к уязвимости, а DAST уже на основе этой информации проводит реальные тесты приложения.
Идеальный анализатор
Итак, мы рассмотрели возможности, методы и альтернативы анализаторов кода на уязвимости. Какими же характеристиками они должны обладать, чтобы максимально эффективно делать свою работу?
- Объединение методов SAST и DAST. Как уже обсуждалось выше, одновременное использование динамического и статического тестирования существенно повышает эффективность анализа. Однако тут важно помнить, что применение обоих способов наследует и их недостатки. Поэтому программа-анализатор должна уметь гибко работать с конкретным кодом и поддерживать баланс между используемыми мощностями и временем работы.
- Система должна по завершению анализа четко указывать, каким образом может быть осуществлена атака, чтобы затем можно было самостоятельно убедиться, что это не ложное срабатывание.
- Тестированию необходимо предоставлять возможность ручной проверки кода, особенно тех его участков, где не было получено ни подтверждения, ни опровержения наличия уязвимостей. Разумеется, во многом эти требования теоретические, и вряд ли сейчас удастся найти или создать подобный идеальный анализатор. Однако именно таким должен быть их общий вектор развития.
Что думаете?
Автор: prince86
