Фазинг

Інтерфейс програми AFL

Фазинг (англ. fuzzing,fuzz testing) — техніка автоматизованого тестування програмного забезпечення, яка полягає в тому, що на вхід програми подаються недійсні, невідповідні або випадково згенеровані дані. Таким чином відбувається перевірка на обробку виключних ситуацій, випадкові падіння тощо. Як правило, фазери використовуються для тестування програм, які сприймають на ввід визначені структури даних, наприклад, файли відомого формату. Ефективний фазер може згенерувати потік даних, який стане «досить валідним» для того, щоб пройти початкові перевірки парсера, але при подальшій обробці виявить поведінку програми при перевищенні допустимих значень для певних параметрів або інші неочікувані ситуації.

З міркувань безпеки найцікавішим є тестування коду, який порушує «рівні довіри». Наприклад, важливо перевірити код, який перевіряє формат файлів перед відправленням їх до сервера на обробку, або парсить конфігураційний файл, який задає налаштування користувача з підвищеними правами.

Історія

Історія фазингового тестування починається у 1950х, коли для введення даних використовувались перфокарти[1]. Програмісти застосовували використані перфокарти, взяті з контейнерів для сміття або випадковим чином пробиті карти для перевірки поточних програм на некоректну поведінку або баги.

Різновидом таких перевірок стало випадкове тестування або мавпячі тести.

У 1981 році з'явились наукові публікації, присвячені випадковому тестуванню ПЗ[2] [3]. Хоча воно визначалось неефективним, автори пропонували його як дешевшу альтернативу звичайному тестуванню.

У 1983 програміст Стів Каппс^[en] розробив програму «The Monkey», яка подавала потік випадково згенерованих даних програмам для класичної Mac OS[4]. Назва програми була відсилкою до теореми про те, що серед нескінченої кількості мавп, посаджених за клавіатури, знайдеться хоча б одна, здатна набрати літературний текст.

Термін «фазинг» з'явився у курсі, що викладався Бартоном Міллером в університеті Вісконсину в 1988[5].Курс передбачав створення програми для Unix, яка б генерувала випадкові файли та аргументи командного рядка. Передбачалось тестування надійності інших програм шляхом подавання на вхід великої кількості рандомізованих даних. Для заохочення подальших досліджень усі вихідні коди утиліти та інші матеріали проекту були зроблені публічно доступними [6].

У вересні 2014 року стало відомо про сімейство багів у командній оболонці bash, що отримало загальну назву Shellock^[en][7]. Більшість з цих багів було виявлено завдяки фазеру AFL («american fuzzy lop»)[8].

Різновиди

Умовно фазери можна поділити на такі групи:[9]

• За тим, як змінюються дані в процесі тестування: на основі мутацій або на основі поколінь.
• За наявністю знань про код програми: методом "чорної скриньки", білої або сірої[10]
• За використанням знань про структуру вхідних даних: прості (англ. dumb) та розумні (англ. smart)

Фазери з мутаційним підходом під час тестування модифікують деякий набір відомих зразків. Наприклад, для перевірки роботи бібліотеки, що обробляє зображення, користувач повинен буде підготувати ряд файлів; у процесі фазер буде їх змінювати, щоб знайти більше помилок. Відповідно до іншого підходу, фазери на основі поколінь генерують усі вхідні дані від самого початку, а тому їх результати не залежать від якості вхідного набору даних.

Простими називають фазери, що не використовують дані про структуру вводу програми, такі як формат файлу або мережевий протокол. При цьому ефективний фазер може «вгадати» правильну структуру вхідних даних і використовувати її у роботі. Розумні фазери з самого початку знайомі зі структурою вхідних даних і генерують тестові дані відповідно до певних правил.

Відомі проекти

• american fuzzy lop (AFL) — простий фазер, що використовує генетичні алгоритми для ефективнішого покриття коду тестами. Розробляється програмістом Michal Zalewski, назва походить від назви породи кроликів. Використовувався для пошуку багів у ряді проектів з відкритим кодом, таких як X.Org Server, PHP, OpenSSL, pngcrush, bash, Firefox, BIND та Qt.
• libFuzzer — бібліотека,що лінкується з кодом і може використовуватись для перевірки роботи окремих функцій. [11]
• radamsa — фазер, що генерує тест-кейси на основі заздалегідь підготованих файлів-зразків. [12]

Див. також

• Мутаційне тестування

Примітки

1. Gerald M. Weinberg. Fuzz Testing and Fuzz History. Архів оригіналу за 24 серпня 2017. Процитовано 6 лютого 2017.
2. Joe W. Duran; Simeon C. Ntafos (9 березня 1981). A report on random testing. Proceedings of the ACM SIGSOFT International Conference on Software Engineering (ICSE'81). Архів оригіналу за 5 травня 2019. Процитовано 26 серпня 2017.
3. Joe W. Duran; Simeon C. Ntafos (1 липня 1984). An Evaluation of Random Testing. IEEE Transactions on Software Engineering (TSE). Архів оригіналу за 28 травня 2018. Процитовано 26 серпня 2017.
4. Macintosh Stories: Monkey Lives. Folklore.org. 22 лютого 1999. Архів оригіналу за 21 березня 2021. Процитовано 28 травня 2010.
5. Barton Miller (2008). «Preface». In Ari Takanen, Jared DeMott and Charlie Miller, Fuzzing for Software Security Testing and Quality Assurance, ISBN 978-1-59693-214-2
6. Fuzz Testing of Application Reliability. University of Wisconsin-Madison. Архів оригіналу за 20 січня 2021. Процитовано 14 травня 2009.
7. Perlroth, Nicole (25 вересня 2014). Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant. New York Times. Архів оригіналу за 5 квітня 2019. Процитовано 25 вересня 2014.
8. Zalewski, Michal (1 жовтня 2014). Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78). lcamtuf's blog. Процитовано 13 березня 2017.
9. John Neystadt (February 2008). Automated Penetration Testing with White-Box Fuzzing. Microsoft. Архів оригіналу за 30 липня 2017. Процитовано 14 травня 2009.
10. Michael Sutton; Adam Greene; Pedram Amini (2007). Fuzzing: Brute Force Vulnerability Discovery. Addison-Wesley. ISBN 0-321-44611-9.
11. libFuzzer. Архів оригіналу за 23 серпня 2017. Процитовано 26 серпня 2017.
12. radamsa. Архів оригіналу за 1 квітня 2017. Процитовано 26 серпня 2017.