stringtranslate.com

Фаззинг

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

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

История

Термин «fuzz» берет свое начало в проекте 1988 года [2] в аспирантуре Advanced Operating Systems (CS736), которую преподавал профессор Бартон Миллер в Университете Висконсина , результаты которого были впоследствии опубликованы в 1990 году. [3] [4] Для тестирования утилиты UNIX методом fuzzing , которая автоматически генерировала случайные входные данные и параметры командной строки для утилиты. Проект был разработан для проверки надежности программ командной строки UNIX путем выполнения большого количества случайных входных данных в быстрой последовательности до тех пор, пока они не давали сбой. Команда Миллера смогла вызвать сбой от 25 до 33 процентов утилит, которые они протестировали. Затем они отладили каждый из сбоев, чтобы определить причину, и классифицировали каждый обнаруженный сбой. Чтобы позволить другим исследователям проводить аналогичные эксперименты с другим программным обеспечением, исходный код инструментов, процедуры тестирования и необработанные данные результатов были сделаны общедоступными. [5] Этот ранний фаззинг теперь будет называться черным ящиком, генерационным, неструктурированным (немым или «классическим») фаззингом.

По словам профессора Бартона Миллера, «В процессе написания описания проекта мне нужно было дать этому виду тестирования название. Я хотел название, которое вызывало бы ощущение случайных, неструктурированных данных. Перепробовав несколько идей, я остановился на термине fuzz» [4] .

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

В апреле 2012 года Google анонсировала ClusterFuzz — облачную инфраструктуру фаззинга для критически важных для безопасности компонентов веб-браузера Chromium . [6] Исследователи безопасности могут загружать собственные фаззеры и получать вознаграждения за ошибки, если ClusterFuzz обнаружит сбой с загруженным фаззером.

В сентябре 2014 года Shellshock [7] был раскрыт как семейство ошибок безопасности в широко используемой оболочке UNIX Bash ; большинство уязвимостей Shellshock были обнаружены с помощью фаззера AFL . [8] (Многие службы, выходящие в Интернет, такие как некоторые развертывания веб-серверов, используют Bash для обработки определенных запросов, что позволяет злоумышленнику заставить уязвимые версии Bash выполнять произвольные команды . Это может позволить злоумышленнику получить несанкционированный доступ к компьютерной системе. [9] )

В апреле 2015 года Ханно Бёк показал, как фаззер AFL мог обнаружить уязвимость Heartbleed 2014 года. [10] [11] ( Уязвимость Heartbleed была раскрыта в апреле 2014 года. Это серьезная уязвимость, которая позволяет злоумышленникам расшифровывать зашифрованные сообщения . Уязвимость была случайно внедрена в OpenSSL , который реализует TLS и используется большинством серверов в Интернете. Shodan сообщил о 238 000 все еще уязвимых машинах в апреле 2016 года; [12] 200 000 в январе 2017 года. [13] )

В августе 2016 года Агентство перспективных исследовательских проектов Министерства обороны США (DARPA) провело финал первого Cyber ​​Grand Challenge , полностью автоматизированного соревнования по захвату флага , которое длилось 11 часов. [14] Целью было разработать автоматические системы защиты, которые могут обнаруживать, эксплуатировать и исправлять недостатки программного обеспечения в режиме реального времени . Фаззинг использовался как эффективная стратегия нападения для обнаружения недостатков в программном обеспечении противников. Он показал огромный потенциал в автоматизации обнаружения уязвимостей. Победителем стала система под названием «Mayhem» [15], разработанная командой ForAllSecure во главе с Дэвидом Брамли .

В сентябре 2016 года Microsoft анонсировала Project Springfield — облачный сервис тестирования методом нечеткого тестирования для поиска критических ошибок безопасности в программном обеспечении. [16]

В декабре 2016 года Google анонсировала OSS-Fuzz, который позволяет проводить непрерывный фаззинг нескольких критически важных для безопасности проектов с открытым исходным кодом. [17]

На конференции Black Hat 2018 Кристофер Домас продемонстрировал использование фаззинга для выявления наличия скрытого ядра RISC в процессоре. [18] Это ядро ​​смогло обойти существующие проверки безопасности для выполнения команд Ring 0 из Ring 3.

В сентябре 2020 года Microsoft выпустила OneFuzz , самостоятельную платформу фаззинга как услуги, которая автоматизирует обнаружение ошибок программного обеспечения . [19] Она поддерживает Windows и Linux. [20] Она была заархивирована три года спустя, 1 ноября 2023 года. [21]

Раннее выборочное тестирование

Тестирование программ со случайными входными данными началось в 1950-х годах, когда данные все еще хранились на перфокартах . [22] Программисты использовали перфокарты, которые вытаскивали из мусорной корзины, или колоды карт со случайными числами в качестве входных данных для компьютерных программ. Если выполнение обнаруживало нежелательное поведение, то ошибка была обнаружена.

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

В 1981 году Дюран и Нтафос официально исследовали эффективность тестирования программы со случайными входными данными. [23] [24] Хотя случайное тестирование широко считалось наихудшим способом тестирования программы, авторам удалось показать, что это экономически эффективная альтернатива более систематическим методам тестирования.

В 1983 году Стив Каппс из Apple разработал «Обезьянку» [25], инструмент, который будет генерировать случайные входные данные для классических приложений Mac OS , таких как MacPaint . [26] Образное «обезьяна» относится к теореме о бесконечной обезьяне , которая гласит, что обезьяна, нажимающая клавиши на клавиатуре пишущей машинки в случайном порядке в течение бесконечного количества времени, в конечном итоге напечатает все произведения Шекспира. В случае тестирования обезьяна будет записывать определенную последовательность входных данных, которая вызовет сбой.

В 1991 году был выпущен инструмент crashme, который был предназначен для проверки надежности Unix и Unix-подобных операционных систем путем случайного выполнения системных вызовов со случайно выбранными параметрами. [27]

Типы

Фаззер можно классифицировать несколькими способами: [28] [1]

  1. Фаззер может быть основан на генерации или мутации в зависимости от того, генерируются ли входные данные с нуля или путем изменения существующих входных данных.
  2. Фаззер может быть глупым (неструктурированным) или умным (структурированным) в зависимости от того, осознает ли он структуру входных данных.
  3. Фаззер может быть «белым», «серым» или «черным ящиком» в зависимости от того, распознает ли он структуру программы.

Повторное использование существующих исходных семян

Фаззер на основе мутаций использует существующий корпус начальных входов во время фаззинга. Он генерирует входы, изменяя (или, скорее, мутируя ) предоставленные начальные значения. [29] Например, при фаззинге библиотеки изображений libpng пользователь должен предоставить набор допустимых файлов изображений PNG в качестве начальных значений, в то время как фаззер на основе мутаций должен изменить эти начальные значения для получения полудопустимых вариантов каждого начального значения. Корпус начальных файлов может содержать тысячи потенциально похожих входных значений. Автоматический выбор начальных значений (или сокращение набора тестов) позволяет пользователям выбирать лучшие начальные значения, чтобы максимизировать общее количество ошибок, обнаруженных во время кампании фаззинга. [30]

Фаззер на основе поколения генерирует входные данные с нуля. Например, интеллектуальный фаззер на основе поколения [31] использует модель входных данных, предоставленную пользователем, для генерации новых входных данных. В отличие от фаззеров на основе мутаций, фаззер на основе поколения не зависит от наличия или качества корпуса начальных входных данных.

Некоторые фаззеры способны делать и то, и другое: генерировать входные данные с нуля и генерировать входные данные путем мутации существующих начальных значений. [32]

Осознавать структуру ввода

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

Интеллектуальный (основанный на модели, [32] основанный на грамматике, [31] [33] или основанный на протоколе [34] ) фаззер использует входную модель для генерации большей доли допустимых входных данных. Например, если входные данные можно смоделировать как абстрактное синтаксическое дерево , то интеллектуальный фаззер на основе мутаций [33] будет использовать случайные преобразования для перемещения полных поддеревьев из одного узла в другой. Если входные данные можно смоделировать с помощью формальной грамматики , то интеллектуальный фаззер на основе генерации [31] будет реализовывать правила производства для генерации входных данных, которые являются допустимыми относительно грамматики. Однако, как правило, входная модель должна быть явно указана, что трудно сделать, когда модель является частной, неизвестной или очень сложной. Если доступен большой корпус допустимых и недопустимых входных данных, метод индукции грамматики , такой как алгоритм L* Энглуина , сможет сгенерировать входную модель. [35] [36]

Глупый фаззер [37] [38] не требует входной модели и, таким образом, может использоваться для фаззинга более широкого спектра программ. Например, AFL — это глупый фаззер на основе мутаций, который изменяет начальный файл, переворачивая случайные биты , заменяя случайные байты «интересными» значениями и перемещая или удаляя блоки данных. Однако глупый фаззер может генерировать меньшую долю допустимых входных данных и нагружать код синтаксического анализатора, а не основные компоненты программы. Недостаток глупых фаззеров можно проиллюстрировать с помощью построения допустимой контрольной суммы для циклического избыточного кода (CRC). CRC — это код обнаружения ошибок , который гарантирует сохранение целостности данных, содержащихся во входном файле, во время передачи . Контрольная сумма вычисляется по входным данным и записывается в файл. Когда программа обрабатывает полученный файл, и записанная контрольная сумма не совпадает с повторно вычисленной контрольной суммой, файл отклоняется как недействительный. Теперь, фаззер, который не знает о CRC, вряд ли сгенерирует правильную контрольную сумму. Однако есть попытки идентифицировать и пересчитать потенциальную контрольную сумму в мутированном вводе, как только тупой фаззер на основе мутации изменил защищенные данные. [39]

Знание структуры программы

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

Фаззер черного ящика [37] [33] рассматривает программу как черный ящик и не знает о внутренней структуре программы. Например, случайный инструмент тестирования , который генерирует входные данные случайным образом, считается фаззером черного ящика. Следовательно, фаззер черного ящика может выполнять несколько сотен входных данных в секунду, может быть легко распараллелен и может масштабироваться до программ произвольного размера. Однако фаззеры черного ящика могут только царапать поверхность и выявлять «поверхностные» ошибки. Следовательно, существуют попытки разработать фаззеры черного ящика, которые могут постепенно узнавать о внутренней структуре (и поведении) программы во время фаззинга, наблюдая за выходными данными программы при заданных входных данных. Например, LearnLib использует активное обучение для генерации автомата , который представляет поведение веб-приложения.

Фаззер белого ящика [38] [32] использует анализ программы для систематического увеличения покрытия кода или для достижения определенных критических мест программы. Например, SAGE [40] использует символическое выполнение для систематического исследования различных путей в программе (метод, известный как concolic execution ). Если спецификация программы доступна, фаззер белого ящика может использовать методы из тестирования на основе модели для генерации входных данных и проверки выходных данных программы на соответствие спецификации программы. Фаззер белого ящика может быть очень эффективным для выявления ошибок, которые скрываются глубоко в программе. Однако время, используемое для анализа (программы или ее спецификации), может стать непомерно большим. Если фаззер белого ящика тратит относительно много времени на генерацию входных данных, фаззер черного ящика будет более эффективным. [41] Следовательно, есть попытки объединить эффективность фаззеров черного ящика и эффективность фаззеров белого ящика. [42]

Серый ящик фаззера использует инструментарий, а не программный анализ, чтобы собрать информацию о программе. Например, AFL и libFuzzer используют легкий инструментарий для отслеживания основных переходов блоков , осуществляемых входом. Это приводит к разумным накладным расходам производительности, но информирует фаззер об увеличении покрытия кода во время фаззинга, что делает серые ящики фаззеров чрезвычайно эффективными инструментами обнаружения уязвимостей. [43]

Использует

Фаззинг в основном используется как автоматизированный метод выявления уязвимостей в критически важных для безопасности программах, которые могут быть использованы со злым умыслом. [6] [16] [17] В более общем смысле фаззинг используется для демонстрации наличия ошибок, а не их отсутствия. Проведение кампании фаззинга в течение нескольких недель без обнаружения ошибки не доказывает правильность программы. [44] В конце концов, программа все еще может давать сбой для ввода, который еще не был выполнен; выполнение программы для всех вводов непомерно дорого. Если цель состоит в том, чтобы доказать правильность программы для всех вводов, должна существовать формальная спецификация и должны использоваться методы из формальных методов .

Выявление ошибок

Чтобы выявить ошибки, фаззер должен уметь отличать ожидаемое (нормальное) от неожиданного (с ошибками) поведения программы. Однако машина не всегда может отличить ошибку от функции. В автоматизированном тестировании программного обеспечения это также называется проблемой тестового оракула . ​​[45] [46]

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

Чтобы сделать фаззер более чувствительным к сбоям, отличным от сбоев, можно использовать санитайзеры для внедрения утверждений, которые приводят к сбою программы при обнаружении сбоя. [47] [48] Существуют различные санитайзеры для разных видов ошибок:

Фаззинг также может использоваться для обнаружения «дифференциальных» ошибок, если доступна эталонная реализация . Для автоматизированного регрессионного тестирования [49] сгенерированные входные данные выполняются на двух версиях одной и той же программы. Для автоматизированного дифференциального тестирования [50] сгенерированные входные данные выполняются на двух реализациях одной и той же программы (например, lighttpd и httpd являются реализациями веб-сервера). Если два варианта выдают разные выходные данные для одного и того же входа, то один из них может быть глючным и его следует изучить более внимательно.

Проверка отчетов статического анализа

Статический анализ программы анализирует программу, фактически не выполняя ее. Это может привести к ложным срабатываниям , когда инструмент сообщает о проблемах с программой, которых на самом деле не существует. Фаззинг в сочетании с динамическим анализом программы может использоваться для попытки сгенерировать входные данные, которые фактически свидетельствуют о выявленной проблеме. [51]

Безопасность браузера

Современные веб-браузеры подвергаются обширному фаззингу. Код Chromium Google Chrome постоянно фаззингится командой Chrome Security Team с 15 000 ядер. [52] Для Microsoft Edge и Internet Explorer Microsoft провела фаззинговое тестирование с 670 машино-лет во время разработки продукта, сгенерировав более 400 миллиардов манипуляций DOM из 1 миллиарда HTML-файлов. [53] [52]

Набор инструментов

Фаззер производит большое количество входов за относительно короткое время. Например, в 2016 году проект Google OSS-fuzz производил около 4 триллионов входов в неделю. [17] Таким образом, многие фаззеры предоставляют цепочку инструментов , которая автоматизирует в противном случае ручные и утомительные задачи, которые следуют за автоматизированной генерацией вызывающих сбои входов.

Автоматизированная сортировка ошибок

Автоматизированная сортировка ошибок используется для группировки большого количества вводов, вызывающих сбои, по первопричине и для приоритизации каждой отдельной ошибки по серьезности. Фаззер создает большое количество вводов, и многие из выводов, вызывающих сбои, могут эффективно выявлять одну и ту же программную ошибку . Только некоторые из этих ошибок являются критическими для безопасности и должны быть исправлены с более высоким приоритетом. Например, Координационный центр CERT предоставляет инструменты сортировки Linux, которые группируют вводы, вызывающие сбой, по полученной трассировке стека и перечисляют каждую группу в соответствии с вероятностью их эксплуатации . [ 54] Исследовательский центр безопасности Microsoft (MSEC) разработал инструмент "!exploitable", который сначала создает хэш для ввода, вызывающего сбой, чтобы определить его уникальность, а затем присваивает рейтинг эксплуатируемости: [55]

Ранее не сообщенные, сортированные ошибки могут быть автоматически сообщены в систему отслеживания ошибок . Например, OSS-Fuzz запускает крупномасштабные, долгосрочные кампании фаззинга для нескольких критически важных для безопасности программных проектов, где каждая ранее не сообщенная, определенная ошибка сообщается непосредственно в баг-трекер. [17] Баг-трекер OSS-Fuzz автоматически информирует сопровождающего уязвимого программного обеспечения и регулярно проверяет, была ли ошибка исправлена ​​в последней версии, используя загруженные минимизированные входные данные, вызывающие сбои.

Автоматическая минимизация ввода

Автоматическая минимизация ввода (или сокращение тестового случая) — это автоматизированная техника отладки , позволяющая изолировать ту часть ввода, которая на самом деле вызывает сбой. [56] [57] Если ввод, вызывающий сбой, большой и в основном неправильно сформирован, разработчику может быть сложно понять, что именно вызывает ошибку. Учитывая ввод, вызывающий сбой, автоматизированный инструмент минимизации удалит как можно больше байтов ввода, при этом все еще воспроизводя исходную ошибку. Например, дельта-отладка — это автоматизированная техника минимизации ввода, которая использует расширенный алгоритм двоичного поиска для поиска такого минимального ввода. [58]

Список популярных фаззеров

Ниже приведен список фаззеров, описанных в академической литературе как «популярные», «широко используемые» или аналогичные. [59] [60]

Смотрите также

Ссылки

  1. ^ ab Джон Нейштадт (февраль 2008 г.). "Автоматизированное тестирование на проникновение с помощью метода белого ящика". Microsoft . Получено 14 мая 2009 г.
  2. ^ Barton P. Miller (сентябрь 1988 г.). "Fall 1988 CS736 Project List" (PDF) . Computer Sciences Department, University of Wisconsin-Madison . Получено 2020-12-30 .
  3. ^ Бартон П. Миллер; Ларс Фредриксен; Брайан Со (декабрь 1990 г.). «Эмпирическое исследование надежности утилит UNIX». Сообщения ACM . 33 (11): 32–44. doi : 10.1145/96267.96279 . S2CID  14313707.
  4. ^ ab Miller, Barton (апрель 2008 г.). «Предисловие к книге Fuzz Testing». UW-Madison Computer Sciences . Получено 29 марта 2024 г.
  5. ^ "Fuzz-тестирование надежности приложений". Университет Висконсин-Мэдисон . Получено 2020-12-30 .
  6. ^ ab "Анонс ClusterFuzz" . Получено 2017-03-09 .
  7. ^ Перлрот, Николь (25 сентября 2014 г.). «Эксперты по безопасности ожидают, что программная ошибка „Shellshock“ в Bash будет значительной». The New York Times . Получено 25 сентября 2014 г.
  8. ^ Залевский, Михал (1 октября 2014 г.). «Ошибка Bash: два других RCE, или как мы урезали оригинальное исправление (CVE-2014-6277 и '78)». Блог lcamtuf . Получено 13 марта 2017 г.
  9. ^ Сельцер, Ларри (29 сентября 2014 г.). «Shellshock заставляет Heartbleed выглядеть незначительным». ZDNet . Получено 29 сентября 2014 г.
  10. ^ Бёк, Ханно. «Фуззинг: Wie man Heartbleed hätte finden können (на немецком языке)». Golem.de (на немецком языке) . Проверено 13 марта 2017 г.
  11. ^ Бёк, Ханно. «Как Heartbleed мог быть найден (на английском)». Блог Ханно . Получено 13 марта 2017 г.
  12. ^ "Поисковая система для Интернета вещей – устройства по-прежнему уязвимы для Heartbleed". shodan.io . Получено 13 марта 2017 г. .
  13. ^ "Heartbleed Report (2017-01)". shodan.io . Архивировано из оригинала 23 января 2017 года . Получено 10 июля 2017 года .
  14. ↑ Уокер, Майкл. «DARPA Cyber ​​Grand Challenge». darpa.mil . Получено 12 марта 2017 г. .
  15. ^ "Mayhem занимает первое место на CGC" . Получено 12 марта 2017 г.
  16. ^ ab "Анонс проекта Springfield". 2016-09-26 . Получено 2017-03-08 .
  17. ^ abcd "Анонс OSS-Fuzz" . Получено 2017-03-08 .
  18. ^ Кристофер Домас (август 2018 г.). "GOD MODE UNLOCKED - Аппаратные бэкдоры в процессорах x86" . Получено 03.09.2018 .
  19. ^ «Microsoft: Windows 10 усилена этими инструментами нечеткой безопасности — теперь они с открытым исходным кодом». ZDNet . 15 сентября 2020 г.
  20. ^ "Фреймворк фаззинга Microsoft с открытым исходным кодом". InfoWorld . 17 сентября 2020 г.
  21. ^ microsoft/onefuzz, Microsoft, 2024-03-03 , получено 2024-03-06
  22. ^ Джеральд М. Вайнберг (2017-02-05). "Fuzz-тестирование и история Fuzz" . Получено 2017-02-06 .
  23. ^ Джо В. Дюран; Симеон К. Нтафос (1981-03-09). Отчет о случайном тестировании. Icse '81. Труды Международной конференции ACM SIGSOFT по программной инженерии (ICSE'81). стр. 179–183. ISBN 9780897911467.
  24. ^ Джо В. Дюран; Симеон К. Нтафос (1984-07-01). «Оценка случайного тестирования». Труды IEEE по программной инженерии (4). Труды IEEE по программной инженерии (TSE): 438–444. doi :10.1109/TSE.1984.5010257. S2CID  17208399.
  25. ^ Энди Херцфельд (2004). Революция в Долине: Безумно Великая История О том, Как Был Сделан Mac? . O'Reily Press. ISBN 978-0596007195.
  26. ^ "Истории Macintosh: Monkey Lives". Folklore.org. 1999-02-22 . Получено 2010-05-28 .
  27. ^ "crashme". CodePlex . Получено 2021-05-21 .
  28. ^ Майкл Саттон; Адам Грин; Педрам Амини (2007). Фаззинг: обнаружение уязвимостей методом грубой силы . Эддисон-Уэсли. ISBN 978-0-321-44611-4.
  29. ^ Оффутт, Джефф; Сюй, Вучжи (2004). «Создание тестовых случаев для веб-сервисов с использованием возмущения данных». Практикум по тестированию, анализу и проверке веб-сервисов . 29 (5): 1–10. doi :10.1145/1022494.1022529. S2CID  52854851.
  30. ^ Реберт, Александр; Ча, Санг Кил; Авгеринос, Танассис; Фут, Джонатан; Уоррен, Дэвид; Грико, Густаво; Брамли, Дэвид (2014). «Оптимизация выбора начальных значений для фаззинга» (PDF) . Труды 23-й конференции USENIX по симпозиуму по безопасности : 861–875.
  31. ^ abc Патрис Годфруа; Адам Кизан; Майкл Ю. Левин. «Грамматически-ориентированный фаззинг белого ящика» (PDF) . Microsoft Research.
  32. ^ abc Van-Thuan Pham; Marcel Böhme; Abhik Roychoudhury (2016-09-07). "Модельно-ориентированный фаззинг белого ящика для двоичных программ". Труды 31-й Международной конференции IEEE/ACM по автоматизированной программной инженерии - ASE 2016. Труды автоматизированной программной инженерии (ASE'16). стр. 543–553. doi :10.1145/2970276.2970316. ISBN 9781450338455. S2CID  5809364.
  33. ^ abc "Peach Fuzzer" . Получено 2017-03-08 .
  34. ^ Грег Бэнкс; Марко Кова; Виктория Фельметсгер; Кевин Альмерот ; Ричард Кеммерер; Джованни Винья. SNOOZE: На пути к фаззеру сетевых протоколов с отслеживанием состояния. Труды конференции по информационной безопасности (ISC'06).
  35. ^ Osbert Bastani; Rahul Sharma; Alex Aiken; Percy Liang (июнь 2017 г.). Синтез грамматик входных данных программ . Труды конференции ACM SIGPLAN по проектированию и реализации языков программирования (PLDI 2017). arXiv : 1608.01723 . Bibcode :2016arXiv160801723B.
  36. ^ "VDA Labs - Evolutionary Fuzzing System". Архивировано из оригинала 2015-11-05 . Получено 2009-05-14 .
  37. ^ ab Ари Таканен; Джаред Д. Демотт; Чарльз Миллер (31 января 2018 г.). Фаззинг для тестирования безопасности программного обеспечения и обеспечения качества, второе издание. Artech House. стр. 15. ISBN 978-1-63081-519-6.полный документ доступен (архив 19 сентября 2018 г.)
  38. ^ ab Виджай Ганеш; Тим Лик; Мартин Ринард (2009-05-16). "Направленный фаззинг белого ящика на основе taint". IEEE . Труды Международной конференции ACM SIGSOFT по программной инженерии (ICSE'09).
  39. ^ Ван, Т.; Вэй, Т.; Гу, Г.; Цзоу, В. (май 2010 г.). «TaintScope: ориентированный инструмент фаззинга с учетом контрольной суммы для автоматического обнаружения уязвимостей программного обеспечения». Симпозиум IEEE по безопасности и конфиденциальности 2010 г. . стр. 497–512. CiteSeerX 10.1.1.169.7866 . doi :10.1109/SP.2010.37. ISBN  978-1-4244-6894-2. S2CID  11898088.
  40. ^ Патрис Годфруа; Майкл Ю. Левин; Дэвид Молнар (2008-02-08). "Автоматизированное тестирование методом белого ящика" (PDF) . Труды симпозиума по сетевым и распределенным системам (NDSS'08).
  41. ^ Марсель Бёме; Соумья Пол (2015-10-05). «Вероятностный анализ эффективности автоматизированного тестирования программного обеспечения». Труды IEEE по программной инженерии . 42 (4): 345–360. doi :10.1109/TSE.2015.2487274. S2CID  15927031.
  42. ^ Ник Стивенс; Джон Гросен; Кристофер Саллс; Эндрю Датчер; Руоюй Ван; Якопо Корбетта; Ян Шошитаишвили; Кристофер Крюгель; Джованни Винья (2016-02-24). Driller: Augmenting. Fuzzing Through Selective Symbolic Execution (PDF) . Труды симпозиума по сетевым и распределенным системам (NDSS'16).
  43. ^ Марсель Бёме; Ван-Туан Фам; Абхик Ройчоудхури (2016-10-28). "Coverage-based Greybox Fuzzing as Markov Chain". Труды конференции ACM SIGSAC 2016 года по компьютерной и коммуникационной безопасности . Труды конференции ACM по компьютерной и коммуникационной безопасности (CCS'16). стр. 1032–1043. doi :10.1145/2976749.2978428. ISBN 9781450341394. S2CID  3344888.
  44. ^ Гамлет, Ричард Г.; Тейлор, Росс (декабрь 1990 г.). «Тестирование разделов не внушает доверия». Труды IEEE по программной инженерии . 16 (12): 1402–1411. doi :10.1109/32.62448.
  45. ^ Weyuker, Elaine J. (1 ноября 1982 г.). «О тестировании нетестируемых программ». The Computer Journal . 25 (4): 465–470. doi : 10.1093/comjnl/25.4.465 .
  46. ^ Барр, Эрл Т.; Харман, Марк; Макминн, Фил; Шахбаз, Музаммил; Ю, Шин (1 мая 2015 г.). «Проблема Oracle в тестировании программного обеспечения: обзор» (PDF) . IEEE Transactions on Software Engineering . 41 (5): 507–525. doi : 10.1109/TSE.2014.2372785 . S2CID  7165993.
  47. ^ "Документация компилятора Clang". clang.llvm.org . Получено 13 марта 2017 г. .
  48. ^ "Параметры санитайзера GNU GCC". gcc.gnu.org . Получено 13 марта 2017 г. .
  49. ^ Орсо, Алессандро; Кси, Тао (2008). "BERT". Труды международного семинара 2008 года по динамическому анализу: Проведен совместно с Международным симпозиумом ACM SIGSOFT по тестированию и анализу программного обеспечения (ISSTA 2008) . ACM. стр. 36–42. doi :10.1145/1401827.1401835. ISBN 9781605580548. S2CID  7506576.
  50. ^ Маккиман, Уильям М. (1998). "Дифференциальное тестирование программного обеспечения" (PDF) . Цифровой технический журнал . 10 (1): 100–107. Архивировано из оригинала (PDF) 2006-10-31.
  51. ^ Бабич, Домагой; Мартиньони, Лоренцо; Маккамант, Стивен; Сонг, Дон (2011). "Статически направленная динамическая автоматизированная генерация тестов". Труды Международного симпозиума по тестированию и анализу программного обеспечения 2011 года . ACM. стр. 12–22. doi :10.1145/2001420.2001423. ISBN 9781450305624. S2CID  17344927.
  52. ^ ab Sesterhenn, Eric; Wever, Berend-Jan; Orrù, Michele; Vervier, Markus (19 сентября 2017 г.). «Browser Security WhitePaper» (PDF) . X41D SEC GmbH.
  53. ^ "Улучшения безопасности для Microsoft Edge (Microsoft Edge для ИТ-специалистов)". Microsoft . 15 октября 2017 г. . Получено 31 августа 2018 г. .
  54. ^ "CERT Triage Tools". CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) . Получено 14 марта 2017 г.
  55. ^ "Microsoft !exploitable Crash Analyzer". CodePlex . Получено 14 марта 2017 г. .
  56. ^ «Сокращение тестовых случаев». 2011-07-18.
  57. ^ "IBM Test Case Reduction Techniques". 2011-07-18. Архивировано из оригинала 2016-01-10 . Получено 2011-07-18 .
  58. ^ Целлер, Андреас; Хильдебрандт, Ральф (февраль 2002 г.). «Упрощение и изоляция ввода, вызывающего сбои». IEEE Transactions on Software Engineering . 28 (2): 183–200. CiteSeerX 10.1.1.180.3357 . doi :10.1109/32.988498. ISSN  0098-5589 . Получено 14 марта 2017 г. 
  59. ^ Хазимех, Ахмад; Эррера, Адриан; Пайер, Матиас (15.06.2021). «Магма: эталонный тест фаззинга». Труды ACM по измерению и анализу вычислительных систем . 4 (3): 49:1–49:29. arXiv : 2009.01120 . doi : 10.1145/3428334. S2CID  227230949.
  60. ^ Ли, Ювэй; Цзи, Шулин; Чен, Юань; Лян, Сычжуан; Ли, Вэй-Хан; Чен, Юэяо; Лю, Чэньян; У, Чуньмин; Бейя, Рахим; Ченг, Пэн; Лу, Канцзе; Ван, Тин (2021). {UNIFUZZ}: целостная и прагматичная {управляемая метриками} платформа для оценки фаззеров. стр. 2777–2794. ISBN 978-1-939133-24-3.
  61. ^ Hazimeh, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (AFL, ...)».
  62. ^ Ли и др. 2021, стр. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ...».
  63. ^ Hazimeh, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (..., AFL++, ...)».
  64. ^ Ли и др. 2021, стр. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, AFLFast, ...».
  65. ^ Ли и др. 2021, стр. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ..., Angora, ...».
  66. ^ Hazimeh, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (..., honggfuzz, ...)».
  67. ^ Ли и др. 2021, стр. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ..., Honggfuzz, ...».
  68. ^ Ли и др. 2021, стр. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ..., QSYM, ...».
  69. ^ Hazimeh, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (... и SymCC-AFL)».
  70. ^ Хазимех, Эррера и Пайер 2021, стр. 14.
  71. ^ Ли и др. 2021, стр. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ..., T-Fuzz, ...».
  72. ^ Ли и др. 2021, стр. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ... и VUzzer64».

Дальнейшее чтение

Внешние ссылки