Расплывание - Fuzzing

Часть серии по
Информационная безопасность
Связанные категории безопасности
Угрозы
Защиты

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

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

История

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

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

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

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

Термин «фаззинг» возник в результате классного проекта 1988 года, который преподавал Бартон Миллер в Университете Висконсина.[6] Для нечеткого теста Unix Утилита предназначена для автоматической генерации случайных файлов и параметров командной строки для утилиты. Проект был разработан для проверки надежности Unix программы, выполняя большое количество случайных входных данных в быстрой последовательности, пока они не сломались. Он также предоставил ранние отладка инструменты для определения причины и категории каждой обнаруженной неисправности. Чтобы другие исследователи могли проводить аналогичные эксперименты с другим программным обеспечением, исходный код инструментов, процедуры тестирования и необработанные данные о результатах были обнародованы.[7] Позже термин фаззинг не ограничивался только утилитами командной строки.

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

В 1995 году фаззер использовался для тестирования инструментов с графическим интерфейсом (таких как X Window System ), сетевые протоколы и API системных библиотек.[9]

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

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

В апреле 2015 года Ханно Бек показал, как фаззер AFL мог обнаружить уязвимость Heartbleed 2014 года.[14][15] (The Heartbleed уязвимость была обнаружена в апреле 2014 года. Это серьезная уязвимость, которая позволяет злоумышленникам иначе расшифровать зашифрованная связь. Уязвимость случайно попала в OpenSSL который реализует TLS и используется большинством серверов в Интернете. Shodan сообщила, что в апреле 2016 года уязвимостью оставалось 238 000 машин;[16] 200000 в январе 2017 года.[17])

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

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

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

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

Типы фаззеров

Фаззеры можно разделить на несколько категорий:[9][1]

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

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

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

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

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

Зная о структуре ввода

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

Умный (модельный,[26] на основе грамматики,[25][27] или на основе протокола[28]) fuzzer использует входную модель для генерации большей части действительных входных данных. Например, если вход можно смоделировать как абстрактное синтаксическое дерево, затем умный фаззер на основе мутаций[27] будет использовать случайные трансформации для перемещения полных поддеревьев с одного узла на другой. Если вход может быть смоделирован формальная грамматика, интеллектуальный фаззер на основе поколения[25] создаст экземпляр правила производства для генерации входных данных, которые действительны с точки зрения грамматики. Однако, как правило, входная модель должна быть явно указана, что трудно сделать, если модель является частной, неизвестной или очень сложной. Если доступен большой корпус действительных и недопустимых входных данных, грамматическая индукция техника, такая как Angluin алгоритм L * сможет сгенерировать входную модель.[29][30]

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

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

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

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

А белая коробка фаззер[31][26] рычаги программный анализ систематически увеличивать покрытие кода или для достижения определенных критических точек программы. Например, SAGE[33] рычаги символическая казнь систематически исследовать различные пути в программе. спецификация программы доступен, фаззер белого ящика может использовать методы из модельное тестирование для генерации входных данных и проверки выходных данных программы на соответствие спецификации программы. Фаззер белого ящика может быть очень эффективным для выявления ошибок, которые прячутся глубоко в программе. Однако время, затрачиваемое на анализ (программы или ее спецификации), может стать непомерно высоким. Если фаззеру белого ящика требуется относительно слишком много времени для создания входных данных, фаззер черного ящика будет более эффективным.[34] Следовательно, есть попытки объединить эффективность фаззеров черного ящика и эффективность фаззеров белого ящика.[35]

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

Использует

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

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

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

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

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

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

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

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

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

Современные веб-браузеры подвергаются обширному фаззингу. В Хром код Гугл Хром Команда безопасности Chrome постоянно обрабатывает 15 000 ядер.[45] За Microsoft Edge и Internet Explorer, Microsoft провела нечеткое тестирование с 670 машино-годами во время разработки продукта, создав более 400 миллиардов DOM-манипуляций из 1 миллиарда HTML-файлов.[46][45]

Набор инструментов для фаззинга

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

Автоматическая сортировка ошибок

Основная статья: Сортировка ошибок

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

  • Пригодный для использования
  • Возможно использование
  • Вероятно, не может использоваться, или
  • Неизвестный.

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

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

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

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

Рекомендации

  1. ^ а б Джон Нейштадт (февраль 2008 г.). «Автоматизированное тестирование на проникновение с фаззингом белого ящика». Microsoft. Получено 2009-05-14.
  2. ^ Джеральд М. Вайнберг (2017-02-05). "Тестирование Fuzz и история Fuzz". Получено 2017-02-06.
  3. ^ Джо В. Дюран; Симеон К. Нтафос (1981-03-09). Отчет о случайном тестировании. Icse '81. Труды Международной конференции по программной инженерии ACM SIGSOFT (ICSE'81). С. 179–183. ISBN  9780897911467.
  4. ^ Джо В. Дюран; Симеон К. Нтафос (1 июля 1984 г.). «Оценка случайного тестирования». IEEE Transactions по разработке программного обеспечения. IEEE Transactions по разработке программного обеспечения (TSE) (4): 438–444. Дои:10.1109 / TSE.1984.5010257. S2CID  17208399.
  5. ^ "Истории Macintosh: Жизни обезьян". Folklore.org. 1999-02-22. Получено 2010-05-28.
  6. ^ а б c Ари Таканен; Джаред Д. Демотт; Чарльз Миллер (31 января 2018 г.). Фаззинг для тестирования безопасности программного обеспечения и обеспечения качества, второе издание. Артек Хаус. п. 15. ISBN  978-1-63081-519-6. полный документ имеется в наличии (в архиве 19 сентября 2018 г.)
  7. ^ «Fuzz-тестирование надежности приложений». Университет Висконсин-Мэдисон. Получено 2009-05-14.
  8. ^ "crashme". CodePlex. Получено 2012-06-26.
  9. ^ а б Майкл Саттон; Адам Грин; Педрам Амини (2007). Фаззинг: обнаружение уязвимости грубой силы. Эддисон-Уэсли. ISBN  978-0-321-44611-4.
  10. ^ а б "Объявление о ClusterFuzz". Получено 2017-03-09.
  11. ^ Перлрот, Николь (25 сентября 2014 г.). «Эксперты по безопасности ожидают, что программная ошибка Shellshock в Bash будет значительной». Нью-Йорк Таймс. Получено 25 сентября 2014.
  12. ^ Залевский, Михал (1 октября 2014 г.). «Ошибка Bash: два других RCE, или как мы отказались от исходного исправления (CVE-2014-6277 и '78)». Блог lcamtuf. Получено 13 марта 2017.
  13. ^ Зельцер, Ларри (29 сентября 2014 г.). "Shellshock делает Heartbleed незначительным". ZDNet. Получено 29 сентября 2014.
  14. ^ Бёк, Ханно. "Fuzzing: Wie man Heartbleed hätte finden können (на немецком языке)". Golem.de (на немецком). Получено 13 марта 2017.
  15. ^ Бёк, Ханно. «Как можно было найти Heartbleed (на английском языке)». Блог Ханно. Получено 13 марта 2017.
  16. ^ «Поисковая система Интернета вещей - устройства по-прежнему уязвимы для Heartbleed». shodan.io. Получено 13 марта 2017.
  17. ^ «Отчет Heartbleed (2017-01)». shodan.io. Получено 10 июля 2017.
  18. ^ Уокер, Майкл. "DARPA Cyber ​​Grand Challenge". darpa.mil. Получено 12 марта 2017.
  19. ^ «Mayhem занимает первое место в CGC». Получено 12 марта 2017.
  20. ^ а б "Объявление о проекте Springfield". 2016-09-26. Получено 2017-03-08.
  21. ^ а б c d "Объявление OSS-Fuzz". Получено 2017-03-08.
  22. ^ Кристофер Домас (август 2018). «РЕЖИМ БОГА РАЗБЛОКИРОВАН - Аппаратные лазейки в процессорах x86». Получено 2018-09-03.
  23. ^ Оффатт, Джефф; Сюй, Учжи (2004). «Создание тестовых примеров для веб-служб с использованием возмущения данных». Семинар по тестированию, анализу и проверке веб-сервисов.
  24. ^ Реберт, Александр; Ча, Санг Кил; Авгеринос, Танассис; Фут, Джонатан; Уоррен, Дэвид; Гриеко, Густаво; Брамли, Дэвид (2014). «Оптимизация отбора семян для расплывания» (PDF). Материалы 23-й конференции USENIX по безопасности симпозиума: 861–875.
  25. ^ а б c Патрис Годфройд; Адам Кизун; Михаил Юрьевич Левин. "Фаззинг белого ящика на основе грамматики" (PDF). Microsoft Research.
  26. ^ а б c Ван-Туан Фам; Марсель Бёме; Абхик Ройчоудхури (07.09.2016). «Основанный на модели фаззинг белого ящика для двоичных файлов программ». Материалы 31-й Международной конференции IEEE / ACM по автоматизированной разработке программного обеспечения - ASE 2016. Труды по автоматизированной разработке программного обеспечения (ASE'16). С. 543–553. Дои:10.1145/2970276.2970316. ISBN  9781450338455. S2CID  5809364.
  27. ^ а б c "Персиковый фаззер". Получено 2017-03-08.
  28. ^ Грег Бэнкс; Марко Кова; Виктория Фельметсгер; Кевин Альмерот; Ричард Кеммерер; Джованни Винья. SNOOZE: к фаззеру сетевого протокола с отслеживанием состояния. Материалы конференции по информационной безопасности (ISC'06).
  29. ^ Осберт Бастани; Рахул Шарма; Алекс Айкен; Перси Лян (июнь 2017 г.). Синтез входных грамматик программы. Труды конференции ACM SIGPLAN по проектированию и реализации языков программирования (PLDI 2017). arXiv:1608.01723. Bibcode:2016arXiv160801723B.
  30. ^ "VDA Labs - Эволюционная система фаззинга". Архивировано из оригинал на 2015-11-05. Получено 2009-05-14.
  31. ^ а б Виджай Ганеш; Тим Лик; Мартин Ринард (16 мая 2009 г.). "Направленный фаззинг белого ящика на основе искажений". Материалы Международной конференции по программной инженерии ACM SIGSOFT (ICSE'09).
  32. ^ Wang, T .; Wei, T .; Gu, G .; Цзоу, В. (май 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.
  33. ^ Патрис Годфройд; Михаил Юрьевич Левин; Дэвид Мольнар (2008-02-08). «Автоматизированное тестирование методом« белого ящика »» (PDF). Труды симпозиума по сетям и распределенным системам (NDSS'08).
  34. ^ Марсель Бёме; Сумья Пол (2015-10-05). «Вероятностный анализ эффективности автоматизированного тестирования программного обеспечения». IEEE Transactions по разработке программного обеспечения. 42 (4): 345–360. Дои:10.1109 / TSE.2015.2487274. S2CID  15927031.
  35. ^ Ник Стивенс; Джон Гросен; Кристофер Саллс; Эндрю Датчер; Жоюй Ван; Якопо Корбетта; Ян Шошитаишвили; Кристофер Крюгель; Джованни Винья (24.02.2016). Бурильщик: Дополнение. Фаззинг посредством выборочного символьного исполнения (PDF). Труды симпозиума по сетям и распределенным системам (NDSS'16).
  36. ^ Марсель Бёме; Ван-Туан Фам; Абхик Ройчоудхури (28.10.2016). «Фаззинг серого ящика на основе покрытия как цепь Маркова». Фаззинг серого ящика на основе покрытия как цепь Маркова. Труды конференции ACM по компьютерной и коммуникационной безопасности (CCS'16). С. 1032–1043. Дои:10.1145/2976749.2978428. ISBN  9781450341394. S2CID  3344888.
  37. ^ Гамлет, Ричард Дж .; Тейлор, Росс (декабрь 1990). «Тестирование перегородок не внушает доверия». IEEE Transactions по разработке программного обеспечения. 16 (12): 1402–1411. Дои:10.1109/32.62448.
  38. ^ Вейкер, Элейн Дж. (1 ноября 1982 г.). «О тестировании непроверяемых программ». Компьютерный журнал. 25 (4): 465–470. Дои:10.1093 / comjnl / 25.4.465.
  39. ^ Барр, Эрл Т .; Харман, Марк; Макминн, Фил; Шахбаз, Музаммил; Ю, Шин (1 мая 2015 г.). «Проблема Oracle в тестировании программного обеспечения: обзор» (PDF). IEEE Transactions по разработке программного обеспечения. 41 (5): 507–525. Дои:10.1109 / TSE.2014.2372785. S2CID  7165993.
  40. ^ "Документация компилятора Clang". clang.llvm.org. Получено 13 марта 2017.
  41. ^ "Параметры дезинфицирующего средства GNU GCC". gcc.gnu.org. Получено 13 марта 2017.
  42. ^ Орсо, Алессандро; Се, Тао (2008). BERT: поведенческое регрессионное тестирование. Материалы Международного семинара по динамическому анализу 2008 г. (WODA 2008). ACM. С. 36–42. Дои:10.1145/1401827.1401835. ISBN  9781605580548. S2CID  7506576.
  43. ^ МакКиман, Уильям М. (1998). «Дифференциальное тестирование программного обеспечения» (PDF). Цифровой технический журнал. 10 (1): 100–107.
  44. ^ Бабич, Домагой; Мартиньони, Лоренцо; Маккамант, Стивен; Песня, Рассвет (2011). Статически управляемая динамическая автоматическая генерация тестов. Материалы Международного симпозиума по тестированию и анализу программного обеспечения 2011 г.. ACM. С. 12–22. Дои:10.1145/2001420.2001423. ISBN  9781450305624. S2CID  17344927.
  45. ^ а б Сестерхенн, Эрик; Вевер, Беренд-Ян; Орро, Микеле; Вервье, Маркус (19 сентября 2017 г.). "Белая книга по безопасности браузера" (PDF). X41D SEC GmbH.
  46. ^ «Улучшения безопасности для Microsoft Edge (Microsoft Edge для ИТ-специалистов)». Microsoft. 15 октября 2017 г.. Получено 31 августа 2018.
  47. ^ "CERT Triage Tools". Подразделение CERT Института программной инженерии (SEI) Университета Карнеги-Меллона (CMU). Получено 14 марта 2017.
  48. ^ «Microsoft! Эксплуатируемый анализатор сбоев». CodePlex. Получено 14 марта 2017.
  49. ^ «Сокращение контрольных примеров». 2011-07-18.
  50. ^ «Методы сокращения тестовых случаев IBM». 2011-07-18. Архивировано из оригинал на 2016-01-10. Получено 2011-07-18.
  51. ^ Зеллер, Андреас; Хильдебрандт, Ральф (февраль 2002 г.). «Упрощение и изоляция входа, вызывающего отказ». IEEE Transactions по разработке программного обеспечения. 28 (2): 183–200. CiteSeerX  10.1.1.180.3357. Дои:10.1109/32.988498. ISSN  0098-5589. Получено 14 марта 2017.

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

внешняя ссылка