Многие компании ещё до конца не осознают плюсы использования фаззинга при разработке своих программных продуктов. А ведь безопасность продуктов должна идти рядом с разработкой. Потому что исправлять то, что уже сделано, трудозатратнее и гораздо дороже, чем сразу сделать хорошо.
И это при том, что в мире разработки достаточно давно появились такие понятия, как Security Development Life Cycle (SDLC), и сравнительно недавно такие, как DevSecOps или SecDevOps, но используются эти техники далеко не всеми. Суть у них одна — внедрять подходы к повышению безопасности с первых этапов разработки, а лучше начинать с обучения сотрудников. И, конечно, важно уделять внимание защищенности продукта от атак на протяжении всего его жизненного цикла. За подробностями — добро пожаловать под кат.
Одним из важнейших этапов безопасной разработки является фаззинг. Фаззинг — это методика тестирования программного обеспечения, суть которой заключается в автоматизированном обнаружении ошибок реализации путем отправки заведомо неверных данных и анализе реакции программы на них.
Как раз во время написания статьи в ленте твиттера мелькнули заметки на тему использования фаззинга от Дмитрия Вьюкова.
Он как раз обращает внимание на то, что с помощью фаззинга можно обнаружить большое количество ошибок в коде, которые в противном случае никуда не исчезнут даже по прошествии времени.
Обычно фаззингом завершают процесс разработки, но фаззить можно и отдельные функции разрабатываемого продукта.
Преимущества фаззинга перед другими методами тестирования:
- фаззер можно запустить и забыть о нём до момента окончания тестирования, а работать уже с результатами;
- автоматизированное тестирование может выявить те ошибки, которые не удалось найти методом ручного тестирования, за счёт бОльшего покрытия кода;
- позволяет собрать общее представление о защищенности тестируемого кода.
Одним из нашумевших случаев, когда фаззинг сделал своё доброе дело, можно назвать обнаружение пятидесяти CVE в Adobe Reader за 50 дней. Исследователи смогли найти такое количество уязвимостей, не имея доступа к исходному коду, и трудно предположить, сколько их обнаружилось бы, будь у них исходники.
Если поискать в открытых источниках информацию на тему использования фаззинга среди разработчиков, то первым попадется Microsoft. Эта компания — одна из пионеров фаззинга в SDLC. У них есть Security Risk Detection — сервис, позволяющий пользователям загружать бинарные файлы для их фаззинга. То, какие данные будут подаваться на вход, решает пользователь. Итогом работы фаззера являются найденные ошибки и данные, которые их породили.
Google тоже использует фаззинг, и у них есть очень много инструментов в открытом доступе. Наиболее интересный из них — OSS-Fuzz. Его суть в том, что любой человек может сделать пулл реквест со своим фаззером. Обычно это фаззеры, когда-то созданные разработчиками для своих небольших проектов. Помимо этих фаззеров, Google использует ClusterFuzz для обнаружения ошибок в Chrome. За несколько лет было обнаружено более 16 тысяч уязвимостей в браузере и более 11 тысяч в 160 опенсурсных проектах.
Некоторые компании, разрабатывающие софт, предоставляют всем желающим ночные сборки для фаззинга. Так делает Mozilla и VLC. Любой желающий может скачать сборку и попробовать поискать в ней ошибки и уязвимости.
Конечно, многие разработчики проприетарного софта умалчивают о том, какими способами они повышают защищенность своих продуктов. Но то, что многие из них не уделяют должного внимания безопасности своих продуктов, очевидно по количеству обнаруживаемых уязвимостей. Поэтому мы решили провести выборочный опрос разработчиков, чтобы узнать их отношение к фаззингу.
Вопросы мы задали следующие:
Используете ли вы fuzzing в процессе разработки своих продуктов?
На этот вопрос положительно ответила треть респондентов.
Если не используете, то почему? Или что, на ваш взгляд, обычно останавливает от включения этапа fuzzing в процесс разработки продукта?
Возможные варианты ответа:
- Нечего фаззить
- Безопасность продукта не является приоритетной задачей
- Отсутствуют подходящие инструменты
- Отсутствуют соответствующие специалисты
- Отсутствует соответствующая инфраструктура
- Другое
Респонденты могли выбрать сразу несколько причин отказа от использования фаззинга в процессе разработки.
На диаграмме показано процентное соотношение актуальности причин отказа от фаззинга в процессе разработки.
Наиболее распространенной причиной НЕ использования фаззинга стало отсутствие в компании квалифицированных сотрудников в этой области. Но не всегда необходимо иметь своих собственных экспертов информационной безопасности, можно привлекать сторонних специалистов, которые проведут аудит разрабатываемых продуктов.
Некоторые из опрошенных, выбравшие вариант ответа "Другое", дали интересные развернутые ответы. Вот некоторые из причин отказа от фаззинга:
- отдел информационной безопасности не оценил инициативу одного из разработчиков написать свой фаззер;
- отсутствие методик ФСТЭК по поиску уязвимостей.
Среди ответов были и уточнения о том, что используются AFL-фаззеры и libfuzzer-ы, что не может не радовать.
Мы, как эксперты в области безопасности, советуем не пренебрегать безопасной разработкой, в том числе и использованием фаззинга для повышения защищённости ваших продуктов.
