✖


Jump to content

Фаззинг

(Перенаправлено из Fuzz-тестирования )

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

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

История

[ редактировать ]

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

По словам профессора Бартона Миллера: «В процессе написания описания проекта мне нужно было дать этому виду тестирования название. Мне нужно было имя, которое вызывало бы ощущение случайных, неструктурированных данных. Опробовав несколько идей, я остановился на термине «фазз». [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] Это ядро ​​смогло обойти существующие проверки безопасности для выполнения команд кольца 0 из кольца 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] использует анализ программы для систематического увеличения покрытия кода или достижения определенных критических мест программы. Например, СЕЙДЖ [40] использует символьное выполнение для систематического исследования различных путей в программе (метод, известный как конколическое выполнение ).Если спецификация программы доступна, фаззер белого ящика может использовать методы тестирования на основе моделей для генерации входных данных и проверки выходных данных программы на соответствие спецификации программы.Фаззер «белого ящика» может быть очень эффективным при выявлении ошибок, спрятанных глубоко в программе. Однако время, затрачиваемое на анализ (программы или ее спецификации), может оказаться непомерно большим. Если фаззеру «белого ящика» требуется слишком много времени для генерации входных данных, фаззер «черного ящика» будет более эффективным. [41] Следовательно, предпринимаются попытки объединить эффективность фаззеров черного ящика и эффективность фаззеров белого ящика. [42]

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

Использование

[ редактировать ]

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

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

[ редактировать ]

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

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

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

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

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

[ редактировать ]

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

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

[ редактировать ]

Современные веб-браузеры подвергаются обширному фаззингу. Код Chromium Google Chrome постоянно анализируется командой безопасности Chrome с помощью 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]

[ редактировать ]
См. Также: Американский fuzzy lop (фаззер) § Вилки

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

Имя Белый/серый/черный ящик Умный/тупой Описание Написано в Лицензия
АФЛ [61] [62] Серый Тупой С Апач 2.0
АФЛ++ [63] Серый Тупой С Апач 2.0
AFLFбыстрый [64] Серый Тупой С Апач 2.0
Ангора [65] Серый Тупой С++ Апач 2.0
хонгфузз [66] [67] Серый Тупой С Апач 2.0
КСИМ [68] [ ? ] [ ? ] [ ? ] [ ? ]
СимСС [69] Белый [70] [ ? ] С++ Лицензионная лицензия , LGPL
Т-Фузз [71] [ ? ] [ ? ] [ ? ] [ ? ]
ВУззер [72] [ ? ] [ ? ] [ ? ] [ ? ]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Jump up to: а б Джон Нейштадт (февраль 2008 г.). «Автоматическое тестирование на проникновение с фаззингом белого ящика» . Майкрософт . Проверено 14 мая 2009 г.
  2. ^ Бартон П. Миллер (сентябрь 1988 г.). «Список проектов CS736 осенью 1988 г.» (PDF) . Факультет компьютерных наук Университета Висконсин-Мэдисон . Проверено 30 декабря 2020 г.
  3. ^ Бартон П. Миллер; Ларс Фредриксен; Брайан Со (декабрь 1990 г.). «Эмпирическое исследование надежности утилит UNIX» . Коммуникации АКМ . 33 (11): 32–44. дои : 10.1145/96267.96279 . S2CID   14313707 .
  4. ^ Jump up to: а б Миллер, Бартон (апрель 2008 г.). «Предисловие к книге по фазз-тестированию» . Компьютерные науки Университета Висконсина в Мэдисоне . Проверено 29 марта 2024 г.
  5. ^ «Нечеткое тестирование надежности приложений» . Университет Висконсин-Мэдисон . Проверено 30 декабря 2020 г.
  6. ^ Jump up to: а б «Анонсируем ClusterFuzz» . Проверено 9 марта 2017 г.
  7. ^ Перлрот, Николь (25 сентября 2014 г.). «Эксперты по безопасности ожидают, что программная ошибка Shellshock в Bash будет серьезной» . Нью-Йорк Таймс . Проверено 25 сентября 2014 г.
  8. ^ Залевский, Михал (1 октября 2014 г.). «Ошибка Bash: два других RCE, или как мы урезали оригинальное исправление (CVE-2014-6277 и '78)» . Блог lcamtuf . Проверено 13 марта 2017 г.
  9. ^ Зельцер, Ларри (29 сентября 2014 г.). «Shellshock делает Heartbleed незначительным» . ЗДНет . Проверено 29 сентября 2014 г.
  10. ^ Бёк, Ханно. «Фуззинг: как можно было найти Heartbleed (на немецком языке)» . Golem.de (на немецком языке) . Проверено 13 марта 2017 г.
  11. ^ Бёк, Ханно. «Как можно было найти Heartbleed (на английском языке)» . Блог Ханно . Проверено 13 марта 2017 г.
  12. ^ «Поисковая система Интернета вещей — устройства по-прежнему уязвимы к Heartbleed» . shodan.io . Проверено 13 марта 2017 г.
  13. ^ «Отчет о кровотечении (2017-01)» . shodan.io . Архивировано из оригинала 23 января 2017 года . Проверено 10 июля 2017 г.
  14. ^ Уокер, Майкл. «Грандиозный кибервызов DARPA» . darpa.mil . Проверено 12 марта 2017 г.
  15. ^ «Mayhem занимает первое место в CGC» . Проверено 12 марта 2017 г.
  16. ^ Jump up to: а б «Анонсируем проект Спрингфилд» . 26 сентября 2016 г. Проверено 8 марта 2017 г.
  17. ^ Jump up to: а б с д «Анонсируем OSS-Fuzz» . Проверено 8 марта 2017 г.
  18. ^ Кристофер Домас (август 2018 г.). «РЕЖИМ БОГА РАЗБЛОКИРОВАН — Аппаратные бэкдоры в процессорах x86» . Проверено 3 сентября 2018 г.
  19. ^ «Microsoft: Windows 10 усилена этими запутанными инструментами безопасности – теперь они с открытым исходным кодом» . ЗДНет . 15 сентября 2020 г.
  20. ^ «Среда тестирования фаззинга с открытым исходным кодом Microsoft» . Инфомир . 17 сентября 2020 г.
  21. ^ microsoft/onefuzz , Microsoft, 03 марта 2024 г. , получено 6 марта 2024 г.
  22. ^ Джеральд М. Вайнберг (05 февраля 2017 г.). «Нечеткое тестирование и история фаззинга» . Проверено 06 февраля 2017 г.
  23. ^ Джо В. Дюран; Симеон К. Нтафос (9 марта 1981 г.). Отчет о случайном тестировании . Айсе '81. Материалы Международной конференции ACM SIGSOFT по программной инженерии (ICSE'81). стр. 179–183. ISBN  9780897911467 .
  24. ^ Джо В. Дюран; Симеон К. Нтафос (1 июля 1984 г.). «Оценка случайного тестирования». Транзакции IEEE по разработке программного обеспечения (4). Транзакции IEEE по разработке программного обеспечения (TSE): 438–444. дои : 10.1109/TSE.1984.5010257 . S2CID   17208399 .
  25. ^ Энди Херцфельд (2004). Революция в долине: безумно великая история о том, как был создан Mac? . О'Рейли Пресс. ISBN  978-0596007195 .
  26. ^ «Истории Macintosh: Обезьяны живы» . Фольклор.орг. 22 февраля 1999 г. Проверено 28 мая 2010 г.
  27. ^ "разбей меня" . КодПлекс . Проверено 21 мая 2021 г.
  28. ^ Майкл Саттон; Адам Грин; Педрам Амини (2007). Фаззинг: обнаружение уязвимостей методом грубой силы . Аддисон-Уэсли. ISBN  978-0-321-44611-4 .
  29. ^ Оффатт, Джефф; Сюй, Учжи (2004). «Создание тестовых примеров для веб-сервисов с использованием искажения данных» . Семинар по тестированию, анализу и верификации веб-сервисов . 29 (5): 1–10. дои : 10.1145/1022494.1022529 . S2CID   52854851 .
  30. ^ Ребер, Александр; Ча, Санг Киль; Авгеринос, Танассис; Фут, Джонатан; Уоррен, Дэвид; Греко, Густаво; Брамли, Дэвид (2014). «Оптимизация выбора начального числа для фаззинга» (PDF) . Материалы 23-й конференции USENIX по симпозиуму по безопасности : 861–875.
  31. ^ Jump up to: а б с Патрис Годфруа; Адам Киезун; Майкл Ю. Левин. «Фаззинг белого ящика на основе грамматики» (PDF) . Исследования Майкрософт.
  32. ^ Jump up to: а б с Ван-Туан Фам; Марсель Бёме; Абхик Ройчоудхури (07 сентября 2016 г.). «Фаззинг белого ящика на основе моделей для двоичных файлов программ». Материалы 31-й Международной конференции IEEE/ACM по автоматизированной разработке программного обеспечения — ASE 2016 . Труды по автоматизированной разработке программного обеспечения (ASE'16). стр. 543–553. дои : 10.1145/2970276.2970316 . ISBN  9781450338455 . S2CID   5809364 .
  33. ^ Jump up to: а б с «Персиковый фаззер» . Проверено 8 марта 2017 г.
  34. ^ Грег Бэнкс; Марко Кова; Виктория Фельметсгер; Кевин Альмерот ; Ричард Кеммерер; Джованни Винья. SNOOZE: на пути к фаззеру сетевого протокола с отслеживанием состояния . Материалы конференции по информационной безопасности (ISC'06).
  35. ^ Осберт Бастани; Рахул Шарма; Алекс Эйкен; Перси Лян (июнь 2017 г.). Синтез грамматик ввода программы . Материалы конференции ACM SIGPLAN по проектированию и реализации языков программирования (PLDI 2017). arXiv : 1608.01723 . Бибкод : 2016arXiv160801723B .
  36. ^ «VDA Labs — Система эволюционного фаззинга» . Архивировано из оригинала 05.11.2015 . Проверено 14 мая 2009 г.
  37. ^ Jump up to: а б Ари Таканен; Джаред Д. Демотт; Чарльз Миллер (31 января 2018 г.). Фаззинг для тестирования безопасности и обеспечения качества программного обеспечения, второе издание . Артех Хаус. п. 15. ISBN  978-1-63081-519-6 . полный документ доступен ( архивировано 19 сентября 2018 г.)
  38. ^ Jump up to: а б Виджай Ганеш; Тим Лик; Мартин Ринар (16 мая 2009 г.). «Направленный фаззинг белого ящика на основе Taint» . ИИЭЭ . Материалы Международной конференции ACM SIGSOFT по программной инженерии (ICSE'09).
  39. ^ Ван, Т.; Вэй, Т.; Гу, Г.; Цзоу, В. (май 2010 г.). «TaintScope: инструмент направленного фаззинга с учетом контрольной суммы для автоматического обнаружения уязвимостей программного обеспечения». Симпозиум IEEE 2010 по безопасности и конфиденциальности . стр. 497–512. CiteSeerX   10.1.1.169.7866 . дои : 10.1109/SP.2010.37 . ISBN  978-1-4244-6894-2 . S2CID   11898088 .
  40. ^ Патрис Годфруа; Майкл Ю. Левин; Дэвид Молнар (8 февраля 2008 г.). «Автоматическое нечеткое тестирование Whitebox» (PDF) . Материалы симпозиума по сетям и распределенным системам (NDSS'08).
  41. ^ Марсель Бёме; Сумья Пол (05.10.2015). «Вероятностный анализ эффективности автоматизированного тестирования программного обеспечения». Транзакции IEEE по разработке программного обеспечения . 42 (4): 345–360. дои : 10.1109/TSE.2015.2487274 . S2CID   15927031 .
  42. ^ Ник Стивенс; Джон Грозен; Кристофер Саллс; Эндрю Датчер; Жоюй Ван; Якопо Корбетта; Ян Шошитаишвили; Кристофер Крюгель; Джованни Винья (24 февраля 2016 г.). Бурильщик: Дополняю. Фаззинг посредством выборочного символического выполнения (PDF) . Материалы симпозиума по сетям и распределенным системам (NDSS'16).
  43. ^ Марсель Бёме; Ван-Туан Фам; Абхик Ройчоудхури (28 октября 2016 г.). «Фаззинг Greybox на основе покрытия как цепь Маркова». Материалы конференции ACM SIGSAC 2016 г. по компьютерной и коммуникационной безопасности . Материалы конференции ACM по компьютерной и коммуникационной безопасности (CCS'16). стр. 1032–1043. дои : 10.1145/2976749.2978428 . ISBN  9781450341394 . S2CID   3344888 .
  44. ^ Гамлет, Ричард Г.; Тейлор, Росс (декабрь 1990 г.). «Тестирование разделов не внушает доверия». Транзакции IEEE по разработке программного обеспечения . 16 (12): 1402–1411. дои : 10.1109/32.62448 .
  45. ^ Вейкер, Элейн Дж. (1 ноября 1982 г.). «О тестировании нетестируемых программ» . Компьютерный журнал . 25 (4): 465–470. дои : 10.1093/comjnl/25.4.465 .
  46. ^ Барр, Эрл Т.; Харман, Марк; Макминн, Фил; Шахбаз, Музаммил; Ю, Шин (1 мая 2015 г.). «Проблема Oracle в тестировании программного обеспечения: опрос» (PDF) . Транзакции IEEE по разработке программного обеспечения . 41 (5): 507–525. дои : 10.1109/TSE.2014.2372785 . S2CID   7165993 .
  47. ^ «Документация компилятора Clang» . clang.llvm.org . Проверено 13 марта 2017 г.
  48. ^ «Параметры дезинфицирующего средства GNU GCC» . gcc.gnu.org . Проверено 13 марта 2017 г.
  49. ^ Орсо, Алессандро; Се, Тао (2008). "БЕРТ". Материалы международного семинара по динамическому анализу 2008 г.: проведенного совместно с Международным симпозиумом ACM SIGSOFT по тестированию и анализу программного обеспечения (ISSTA 2008) . АКМ. стр. 36–42. дои : 10.1145/1401827.1401835 . ISBN  9781605580548 . S2CID   7506576 .
  50. ^ Маккиман, Уильям М. (1998). «Дифференциальное тестирование программного обеспечения» (PDF) . Цифровой технический журнал . 10 (1): 100–107. Архивировано из оригинала (PDF) 31 октября 2006 г.
  51. ^ Бабич, Домагой; Мартиньони, Лоренцо; МакКамант, Стивен; Песня, Рассвет (2011). «Статически-направленное динамическое автоматизированное создание тестов». Материалы Международного симпозиума по тестированию и анализу программного обеспечения 2011 г. АКМ. стр. 12–22. дои : 10.1145/2001420.2001423 . ISBN  9781450305624 . S2CID   17344927 .
  52. ^ Jump up to: а б Сестерхенн, Эрик; Вевер, Беренд-Ян; Орру, Микеле; Вервье, Маркус (19 сентября 2017 г.). «Информационный документ по безопасности браузера» (PDF) . X41D SEC GmbH.
  53. ^ «Усовершенствования безопасности для Microsoft Edge (Microsoft Edge для ИТ-специалистов)» . Майкрософт . 15 октября 2017 г. Проверено 31 августа 2018 г.
  54. ^ «Инструменты сортировки CERT» . Подразделение CERT Института программной инженерии (SEI) Университета Карнеги-Меллон (CMU) . Проверено 14 марта 2017 г.
  55. ^ «Microsoft !exploitable Crash Analyzer» . КодПлекс . Проверено 14 марта 2017 г.
  56. ^ «Сокращение тестовых примеров» . 18 июля 2011 г.
  57. ^ «Методы сокращения тестовых случаев IBM» . 18 июля 2011 г. Архивировано из оригинала 10 января 2016 г. Проверено 18 июля 2011 г.
  58. ^ Целлер, Андреас; Хильдебрандт, Ральф (февраль 2002 г.). «Упрощение и изоляция входных данных, вызывающих сбои» . Транзакции IEEE по разработке программного обеспечения . 28 (2): 183–200. CiteSeerX   10.1.1.180.3357 . дои : 10.1109/32.988498 . ISSN   0098-5589 . Проверено 14 марта 2017 г.
  59. ^ Хазиме, Ахмад; Эррера, Адриан; Пайер, Матиас (15 июня 2021 г.). «Магма: эталон фаззинга на основе истины» . Труды АКМ по измерению и анализу вычислительных систем . 4 (3): 49:1–49:29. arXiv : 2009.01120 . дои : 10.1145/3428334 . S2CID   227230949 .
  60. ^ Ли, Ювэй; Чэнь, Юань; Ли, Вэй-Хань; Лю, Чэньян; Бэй, Рахим; Ченг, Канцзе; 2021). {UNIFUZZ}: Целостная и прагматичная {управляемая метриками} платформа для оценки фаззеров стр. 2777–2794. ,  978-1-939133-24-3 .
  61. ^ Хазиме, Herrera & Payer 2021 , стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (AFL, ...)».
  62. ^ Ли и др. 2021 , с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,…».
  63. ^ Хазиме, Herrera & Payer 2021 , стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (..., AFL++, ...)».
  64. ^ Ли и др. 2021 , с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, AFLFast, ...».
  65. ^ Ли и др. 2021 , с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., Angora,...».
  66. ^ Хазиме, Herrera & Payer 2021 , стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (..., honggfuzz, ...)».
  67. ^ Ли и др. 2021 , с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., Honggfuzz,...».
  68. ^ Ли и др. 2021 , с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., QSYM,...».
  69. ^ Хазиме, Herrera & Payer 2021 , стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (... и SymCC-AFL)».
  70. ^ Хазиме, Blacksmith & Payer 2021 , стр. 14.
  71. ^ Ли и др. 2021 , с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., T-Fuzz,...».
  72. ^ Ли и др. 2021 , с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ... и VUzzer64».

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

[ редактировать ]
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Fuzzing&oldid=1237994458"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 0d51b87d72d9d7bf4c0d43127f9f1231__1722513720
URL1:https://arc.ask3.ru/arc/aa/0d/31/0d51b87d72d9d7bf4c0d43127f9f1231.html
Заголовок, (Title) документа по адресу, URL1:
Fuzzing - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)