Методическая рекомендация № 2025-04-007 | Уровень критичности: 3

Область: Фаззинг-тестирование

Тип недостатка: Отсутствие путей выполнения программы, обнаруженных фаззером.

Описание: На рис. 1 представлена статистика работы фаззера afl++ (UI-представление). Параметр last new find: none yet говорит о том, что за всё время работы фаззер не смог обнаружить ни одного нового пути выполнения программы.

При выполнении фаззинг-тестирования фаззер анализирует поведение программы, подавая на вход различные варианты тестовых данных (семплов). Основной метрикой эффективности работы фаззера afl++ является количество найденных уникальных путей выполнения исследуемой программы (объекта оценки). Если в процессе работы фаззера значение параметра last new find остается равным none yet, это указывает на то, что фаззер не может обнаружить ни одного нового пути выполнения программы. Полное отсутствие найденных путей выполнения программы является показателем неэффективности процедуры фаззинг-тестирования, так как основная цель фаззинг-тестирования заключается в исследовании различных сценариев работы программы для выявления потенциальных уязвимостей и ошибок. Такое тестирование не достигает своей цели и, как правило, не имеет практической ценности. В соответствии с требованиями Методики выявления уязвимостей и недекларированных возможностей, утвержденной ФСТЭК России 25 декабря 2020 года (далее - Методика ВУ НДВ), одним из критериев завершения фаззинг-тестирования является следующее условие:

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

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

Дополнительное предупреждение (odd, check syntax!) может свидетельствовать о проблемах с форматом или синтаксисом входных данных, которые передаются фаззеру.

Возможные причины отсутствия найденных путей:
- некорректный формат входных данных. Если семплы, передаваемые фаззеру, имеют неправильный формат или не соответствуют ожидаемому синтаксису, программа может игнорировать их или обрабатывать некорректно (например, если программа ожидает JSON, а входные данные содержат недопустимые символы или неверную структуру, фаззер не сможет обнаружить новые пути);

- ограниченность начального корпуса. Начальный набор тестовых данных (корпус) слишком мал или не покрывает достаточное количество состояний программы. Это ограничивает возможности фаззера по исследованию новых путей (например, если корпус содержит только один или несколько однотипных семплов, фаззер может не иметь достаточно разнообразных входных данных для анализа). На рис. 1 значение параметра corpus count равно 1 - это значит, что на вход исследуемой программе был передан всего один семпл, что противоречит требованиям Методики ВУ НДВ.

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

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

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

- необходимо анализировать значения last new finds и corpus count для оценки эффективности работы фаззера

Дополнительные информационные материалы:

- описание основных параметров UI-представления AFL++

Методическая рекомендация № 2025-05-008 | Уровень критичности: 2

Область: Статический анализ

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

Описание: На рис. 1-5 представлены размеченные предупреждения о потенциальных уязвимостях кода, полученные от статического анализатора. При этом результаты проведения разметки не содержат достаточного обоснования, позволяющего подтвердить корректность вынесенных вердиктов (Won't fix - истинное срабатывание, которое по тем или иным причинам исправлять нецелесообразно; False Positive - ложное срабатывание инструмента статического анализа).

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

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

- необходимо каждое размеченное предупреждение сопровождать индивидуальным комментарием, содержащим обоснование вынесенного вердикта

- при формировании комментариев необходимо избегать общих фраз, таких как «Не эксплуатируемо» или «Не применимо». Вместо этого необходимо приводить конкретные аргументы и обоснования (рис. 6-7 - пример корректной разметки)

- в случае, если срабатывание статического анализатора является False Positive - настоятельно рекомендуется заводить заявку (Issue) на исправление бага в трекер инструмента статического анализа. Также необходимо указать в комментарии к разметке ссылку на данную заявку, если трекер является публичным

Дополнительные информационные материалы:

- Инструкция по проведению разметки результатов статического анализа
- ГОСТ Р 71207-2024

Методическая рекомендация № 2025-05-009 | Уровень критичности: 2

Область: Фаззинг-тестирование

Тип недостатка: Игнорирование необходимости анализа сэмплов, приведших к зависанию фаззинг-цели.

Описание: На рис. 1-2 представлены сведения о том, что фаззер обнаружил варианты входных данных, подача которых в фаззинг-цель приводит к "зависанию" (hang) фаззера - выполнению кода цели больше отведенного времени. На рис. 3 представлен пример итогового отчета по анализу (триажу) результатов запуска одной из упомянутых выше фаззинг-целей, в котором игнорируется факт обнаружения фаззером зависаний цели.

По умолчанию фаззеры семейста AFL трактуют факты выполнения фаззинг-цели более чем 1 секунду в качестве зависаний. В соответствии с лучшими практиками фаззинг-цель формируются таким образом, чтобы среднее время выполнения составляло не более десятков миллисекунд. Это позволяет выполнять миллиарды запусков цели на достаточно стандартном аппаратном обеспечении, доступном средней организации - генетический фаззинг по своей природе наиболее эффективен именно при большом числе запуском. Если цель выполняется существенно дольше, это может в т. ч. свидетельствовать об обнаружении ситуации перерасхода ресурсов, либо бесконечного цикла, что может являться признаком ошибки кода цели.

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

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

- необходимо исследовать ситуации и приводить результаты анализа в материалах сертификационных испытаний для тех вариантов входных данных, подача которых в фаззинг-цель приводит к "зависанию" фаззера

- рекомендуется стремиться к времени выполнения одной фаззинг-цели, не превышающем 10 миллисекунд на одном ядре современной серверной вычислительной системы

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

Дополнительные информационные материалы:

- трактовка результатов зависаний для фаззера AFL
- трактовка результатов зависаний для фаззера Crusher

Коллеги, доброго дня!

В пятницу состоится интереснейший эфир, посвященный теме РБПО. В качестве специального гостя - Ирина Сергеевна Гефнер, и она точно ответит на несколько волнующих всех вопросов (например - требуется ли сертификат ФСТЭК России на инструменты статического и динамического анализа 😎). Охват тем максимально широкий - сколько можно втолкнуть в мимолетные два часа! Вопросы - как драгоценные камни-самоцветы! Вместе с участниками дискуссии, в т. ч. великим&ужасным @Dmitry_Shmol, постараемся сделать уважаемой аудитории интересно&полезно - заглядывайте к нам на огонёк.

Также не пропустите второй эфир в этот день - важнейшая тема практической безопасности в наше время это защита цепочек поставок и композиционный анализ как часть этой процедуры. Список участников пока не опубликован, но по слухам ожидается Лёша-КАПО @alsmirn собственной персоной по ВКС 🤗

Коллеги, добрый день!

Пока готовимся к завтрашнему большому эфиру, спешим уже оповестить о следующем событии. 10 июля состоится Kaspersky Certification Day, да не простой, а золотой юбилейный - 10й!

На мой личный взгляд это одно из трёх главных отечественных мероприятий по безопасной и качественной разработке в году - наравне с зимними ТБФорум и ISPRASOPEN. Как всегда заявлены интереснейшие темы и традиционное большое выступление ФСТЭК России (Дмитрий Николаевич Шевцов), как всегда - теплейшие компания и кулуары, поскольку проход на конференцию "по спискам по рекомендации".

Что важно - уже второй год конференция будет транслироваться онлайн.

Что ещё важнее - несмотря на традиционный аншлаг и вход только по спискам и рекомендациям, глубокоуважаемая-неподражаемая Карина Олеговна ❤️‍🔥 - идеолог и организатор CertDay, участник РБПО-сообщества и просто чудесный человек - в этом году, в связи с юбилеем, приняла решение выделить небольшой батч мест для потенциальных новых участников - участников РБПО-сообщества ФСТЭК России и ИСП РАН!

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

Важно! Необходимо подать ваши заявки до 13:00 пятницы 27 июня, а лучше - прямо сейчас!

P.S. Вот как это было в таком далёком 2024м.

P.S.S. Пока трек докладов доформировывается на сайте, анонсирую доклад про ход испытаний инструментом статического анализа под патронажем ФСТЭК России 🔥

Методическая рекомендация № 2025-07-010 | Уровень критичности: 3

Область: Фаззинг-тестирование

Тип недостатка: Применение средств фаззинг-тестирования, не реализующих генетические алгоритмы фаззинг-тестирования (в том числе за счет инструментирования тестируемого кода).

Описание: На рис. 1-3 представлены протоколы сертификационных испытаний (4 уровень доверия) с применением инструментов (BurpSuite, OWASP ZAP, RestlerFuzz), не предназначенных для проведения фаззинг-тестирования с инструментированием кода и не реализующих генетические алгоритмы фаззинг-тестирования.

Что такое генетические алгоритмы в фаззинге?
Генетические алгоритмы в фаззинге применяются для автоматической генерации и оптимизации тестовых входных данных, на основе отобранных входных данных, которые максимизируют покрытие кода или вызывают аномальное поведение программы. Примеры популярных фаззеров, реализующих генетические алгоритмы фаззинг-тестирования: AFL++, libFuzzer, go-fuzz, SharpFuzz, JQF.

Что такое фаззинг с инструментированием кода?
Инструментирование кода – это процесс внедрения минимально возможных изменений в код программы для сбора информации о её выполнении. Может проводиться как до запуска программного обеспечения (статическое инструментирование, выполняется на этапе компиляции), так и во время выполнения исполняемого кода программного обеспечения (динамическое инструментирование, например с помощью Pin, Valgrind или DynamoRIO).

BurpSuite, OWASP ZAP и подобные инструменты анализа уязвимостей и тестирования безопасности веб-приложений не подходят для мутационного фаззинга с инструментированием кода и реализации генетических алгоритмов тестирования. Данные инструменты выполняют сканирование на основе сигнатур и заранее определенных шаблонов атак (SQL-инъекции, XSS, CSRF). В состав данных инструментов входят базовые фаззеры для автоматизации тестирования веб-приложений методом подстановки значений из заранее заданных словарей (payloads). Функция Grep-Extract не осуществляет мутации полученных данных, а позволяет автоматически извлекать данные из HTTP-ответов и использовать их в качестве payloads для последующих запросов по заданному правилу (regex, позиции текста, HTML-атрибуты). Для мутации (автоматизированной генерации) значений в BurpSuite / OWASP ZAP могут интегрироваться сторонние инструменты, такие как Radamsa. Однако инструменты не содержат функциональных возможностей по инструментированию кода тестируемых веб-приложений, и как следствие, не обеспечивают возможность проведения фаззинг-тестирования, реализующего генетические алгоритмы.

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

- в соответствии с требованиями Методики выявления уязвимостей и недекларированных возможностей, утвержденной ФСТЭК России 25 декабря 2020 года, начиная с 5 уровня доверия, необходимо проводить мутационное фаззинг-тестирование объекта оценки с инструментированием кода, обеспечивающим реализацию генетических алгоритмов фаззинг-тестирования.

- для фаззинг-тестирования веб-приложения с инструментированием кода и использованием генетических алгоритмов необходимо выделить участки кода, непосредственно доступные потенциальному нарушителю для взаимодействия с ними и передачи значений аргументов в них (например: обработка JSON-запросов; обработка входных данных через API или веб-интерфейсы; обработка данных, передаваемых через HTTP-запросы), создать минимальный тестируемый интерфейс (fuzz target) — функцию, которая: принимает входные данные от фаззера → передает их в тестируемый участок кода (функцию, библиотеку, модуль).

- применение генетических инструментирующих фаззеров и REST-фаззеров не противоречит друг-другу. Данные типы инструментов ориентированы на нахождение различных типов дефектов, рекомендуется применять их совместно. В дальнейшем развитии методической базы запланировано расширение разделов, описывающих подходы к динамическому тестированию API.

Дополнительные информационные материалы:

- чат сообщества ФСТЭК России и ИСП РАН. Динамика.
- методическая рекомендация № 2025-04-004
- методическая рекомендация № 2025-04-007
- документация на AFL++
- документация на libfuzzer