Хабрахабр

Фаззинг — важный этап безопасной разработки

А ведь безопасность продуктов должна идти рядом с разработкой. Многие компании ещё до конца не осознают плюсы использования фаззинга при разработке своих программных продуктов. Потому что исправлять то, что уже сделано, трудозатратнее и гораздо дороже, чем сразу сделать хорошо.

Суть у них одна — внедрять подходы к повышению безопасности с первых этапов разработки, а лучше начинать с обучения сотрудников. И это при том, что в мире разработки достаточно давно появились такие понятия, как Security Development Life Cycle (SDLC), и сравнительно недавно такие, как DevSecOps или SecDevOps, но используются эти техники далеко не всеми. За подробностями — добро пожаловать под кат. И, конечно, важно уделять внимание защищенности продукта от атак на протяжении всего его жизненного цикла.

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

Как раз во время написания статьи в ленте твиттера мелькнули заметки на тему использования фаззинга от Дмитрия Вьюкова.

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

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

Преимущества фаззинга перед другими методами тестирования:

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

Исследователи смогли найти такое количество уязвимостей, не имея доступа к исходному коду, и трудно предположить, сколько их обнаружилось бы, будь у них исходники. Одним из нашумевших случаев, когда фаззинг сделал своё доброе дело, можно назвать обнаружение пятидесяти CVE в Adobe Reader за 50 дней.

Эта компания — одна из пионеров фаззинга в SDLC. Если поискать в открытых источниках информацию на тему использования фаззинга среди разработчиков, то первым попадется Microsoft. То, какие данные будут подаваться на вход, решает пользователь. У них есть Security Risk Detection — сервис, позволяющий пользователям загружать бинарные файлы для их фаззинга. Итогом работы фаззера являются найденные ошибки и данные, которые их породили.

Наиболее интересный из них — OSS-Fuzz. Google тоже использует фаззинг, и у них есть очень много инструментов в открытом доступе. Обычно это фаззеры, когда-то созданные разработчиками для своих небольших проектов. Его суть в том, что любой человек может сделать пулл реквест со своим фаззером. За несколько лет было обнаружено более 16 тысяч уязвимостей в браузере и более 11 тысяч в 160 опенсурсных проектах. Помимо этих фаззеров, Google использует ClusterFuzz для обнаружения ошибок в Chrome.

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

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

Вопросы мы задали следующие:

Используете ли вы fuzzing в процессе разработки своих продуктов?

На этот вопрос положительно ответила треть респондентов.

Или что, на ваш взгляд, обычно останавливает от включения этапа fuzzing в процесс разработки продукта? Если не используете, то почему?

Возможные варианты ответа:

  1. Нечего фаззить
  2. Безопасность продукта не является приоритетной задачей
  3. Отсутствуют подходящие инструменты
  4. Отсутствуют соответствующие специалисты
  5. Отсутствует соответствующая инфраструктура
  6. Другое

Респонденты могли выбрать сразу несколько причин отказа от использования фаззинга в процессе разработки.

На диаграмме показано процентное соотношение актуальности причин отказа от фаззинга в процессе разработки.

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

Вот некоторые из причин отказа от фаззинга: Некоторые из опрошенных, выбравшие вариант ответа "Другое", дали интересные развернутые ответы.

  • отдел информационной безопасности не оценил инициативу одного из разработчиков написать свой фаззер;
  • отсутствие методик ФСТЭК по поиску уязвимостей.

Среди ответов были и уточнения о том, что используются AFL-фаззеры и libfuzzer-ы, что не может не радовать.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть