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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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

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

Что думаете?
  • –8
  • 4.2k
  • 1
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 1

    +14
    Что думаете?

    Лично я думаю, что если уж заниматься вольным пересказыванием чужого материала, то стоит давать ссылку на первоисточники (раз, два, три, четыре — видите, это совсем не сложно). Кроме того, я также думаю, что для пересказывания нужно иметь хотя бы приблизительное представление о предметной области пересказываемого. А то ведь может как-то неудобно выйти:

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

    Интересно, насколько длительное время требуется для разработки вычислительной системы, имеющий неограниченный запас памяти?

    теорию Тьюринга необходимо применить к конечным автоматам, или, проще говоря, обычным компьютерам, которые не имеют бесконечное количество состояний

    А еще проще говоря — к программам обычных компьютеров, имеющим (раз уж мы отважно применяем к ним «теорию Тьюринга») S^n*m состояний, где S — размер входного алфавита, n — объем памяти, x — число допустимых состояний программы. Пусть S — 65535b (UTF-16), n — 1073741824b (1Gb) а приложение может находиться, ну скажем, в десятке допустимых состояний (т.е. что-то совершенно примитивное). Сами посчитаете размер конечного автомата, который вы предлагаете анализировать таким образом?

    К примеру, такой анализ может обнаружить уязвимость функции к XSS-инъекции

    XSS-инъекция — это свежо. А переполнение буфера — это ROP-инъекция по вашей классификации, так?

    Основан на использовании символических вычислений – преобразования конкретного кода в его абстрактную интерпретацию

    «Нахождение корней уравнения — это преобразование некоторого утверждения к процессу его решения» — звучит примерно так же.

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

    Символическим языком, уж просите, написана эта статья, а модель формализуемой уязвимости вполне себе выражается на языке логики высказываний.

    Другая разновидность тестирования – смешная, или интерактивная

    Смешная — не то слово. Каждый раз ржу как конь, когда занимаюсь интерактивным тестирование.

    Про пунктуацию и грамматику скромно умолчу.

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