Анализ программы

В информатике программ анализ ^[1] Это процесс автоматического анализа поведения компьютерных программ относительно таких свойств, как правильность, надежность, безопасность и живучесть. Анализ программы фокусируется на двух основных областях: оптимизации программы и корректности программы . Первый фокусируется на повышении производительности программы при одновременном сокращении использования ресурсов, а второй — на обеспечении того, чтобы программа делала то, что должна делать.

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

Статический анализ программы [ править ]

Что касается корректности программы, статический анализ может обнаружить уязвимости на этапе разработки программы. ^[2] Эти уязвимости легче исправить, чем обнаруженные на этапе тестирования, поскольку статический анализ позволяет выявить корень уязвимости.

Поскольку многие формы статического анализа неразрешимы с вычислительной точки зрения, механизмы его выполнения не всегда завершаются правильным ответом – либо потому, что иногда они возвращают ложный отрицательный результат («проблем не обнаружено», когда в коде действительно есть проблемы), либо ложное срабатывание или потому, что они никогда не возвращают неправильный ответ, но иногда никогда не завершаются. Несмотря на свои ограничения, первый тип механизмов может уменьшить количество уязвимостей, тогда как второй иногда может дать надежную гарантию отсутствия определенного класса уязвимостей.

Неправильные оптимизации крайне нежелательны. Итак, в контексте оптимизации программы существует две основные стратегии обработки вычислительно неразрешимого анализа:

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

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

Поток управления [ править ]

Целью анализа потока управления является получение информации о том, какие функции можно вызывать в различных точках выполнения программы. Собранная информация представлена графом потока управления (CFG), где узлы представляют собой инструкции программы, а ребра представляют поток управления. Определяя блоки кода и циклы, CFG становится отправной точкой для оптимизации, выполняемой компилятором.

Анализ потока данных [ править ]

Анализ потока данных — это метод, предназначенный для сбора информации о значениях в каждой точке программы и о том, как они меняются с течением времени. Этот метод часто используется компиляторами для оптимизации кода.Одним из наиболее известных примеров анализа потока данных является проверка на наличие искажений , которая заключается в рассмотрении всех переменных, содержащих предоставленные пользователем данные (которые считаются «испорченными», т. е. небезопасными), и предотвращении использования этих переменных до тех пор, пока они не будут проверены. продезинфицирован. Этот метод часто используется для предотвращения атак с использованием SQL-инъекций . Проверка на наличие вредоносных данных может выполняться статически или динамически.

Абстрактная интерпретация [ править ]

Абстрактная интерпретация позволяет извлечь информацию о возможном выполнении программы без фактического выполнения программы. Эта информация может использоваться компиляторами для поиска возможных оптимизаций или для сертификации программы на наличие определенных классов ошибок.

Типовые системы [ править ]

Системы типов связывают типы с программами, которые удовлетворяют определенным требованиям. Их цель — выбрать подмножество программ языка, которые считаются правильными по свойству.

Проверка типа — проверьте, принята ли программа системой типов.

Проверка типов используется в программировании для ограничения того, как используются программные объекты и что они могут делать. Это делается компилятором или интерпретатором . Проверка типов также может помочь предотвратить уязвимости, гарантируя, что знаковое значение не будет присвоено беззнаковой переменной.Проверка типов может выполняться статически (во время компиляции), динамически (во время выполнения) или комбинацией того и другого.

Информация о статическом типе (либо выведенная , либо явно предоставленная аннотациями типов в исходном коде) также может использоваться для оптимизации, например замены упакованных массивов неупакованными массивами.

Системы эффектов [ править ]

Системы эффектов — это формальные системы, предназначенные для представления эффектов, которые может иметь выполнение функции или метода. Эффект кодифицирует то, что делается, и с чем это делается — обычно его называют типом эффекта и областью эффекта соответственно. ^{[ нужны разъяснения ]}

Проверка модели [ править ]

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

Динамический анализ программы [ править ]

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

Тестирование [ править ]

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

Мониторинг [ править ]

Мониторинг программы записывает и регистрирует различную информацию о программе, такую как использование ресурсов, события и взаимодействия, чтобы ее можно было просмотреть для поиска или определения причин ненормального поведения. Кроме того, его можно использовать для проведения аудита безопасности. Автоматический мониторинг программ иногда называют проверкой времени выполнения .

Нарезка программы [ править ]

Для данного подмножества поведения программы нарезка программы состоит из сведения программы к минимальной форме, которая по-прежнему обеспечивает выбранное поведение. Сокращенная программа называется «срезом» и является точным представлением исходной программы в области указанного подмножества поведения. Как правило, поиск среза является неразрешимой проблемой, но, задав подмножество целевого поведения значениями набора переменных, можно получить приблизительные срезы, используя алгоритм потока данных. Эти фрагменты обычно используются разработчиками во время отладки для определения источника ошибок.

См. также [ править ]

Ссылки [ править ]

^ Нильсон, Ф., Нильсон, HR, и Ханкин, К. (2015). Принципы программного анализа . Спрингер.
^ Йованович Н., Крюгель К. и Кирда Э. (2006, май). Pixy: инструмент статического анализа для обнаружения уязвимостей веб-приложений. В книге «Безопасность и конфиденциальность», симпозиум IEEE 2006 г. (стр. 6 стр.). IEEE.

Дальнейшее чтение [ править ]

Агравал, Хиралал; Хорган, Джозеф Р. Динамическое нарезка программ (PDF) .
Чунлей, Ван; Банда, Чжао; Ици, Дай (2009). «Эффективный подход к анализу безопасности потока управления для двоичных исполняемых файлов». 2009 г. 2-я Международная конференция IEEE по компьютерным наукам и информационным технологиям . стр. 272–276. дои : 10.1109/ICCSIT.2009.5234950 . ISBN 978-1-4244-4519-6 . S2CID 10551500 .
Нильсон, Флемминг; Нильсон, Ханне Риис; Хэнкин, Крис (2005). Принципы анализа программ . Springer Science+Business Media .

Внешние ссылки [ править ]

СМИ, связанные с анализом программы, на Викискладе?

[1] Нильсон, Ф., Нильсон, HR, и Ханкин, К. (2015). Принципы программного анализа . Спрингер.

[2] Йованович Н., Крюгель К. и Кирда Э. (2006, май). Pixy: инструмент статического анализа для обнаружения уязвимостей веб-приложений. В книге «Безопасность и конфиденциальность», симпозиум IEEE 2006 г. (стр. 6 стр.). IEEE.

[1]

[2]