API (общая стратегия)
- Проектируйте API с учётом явной ответственности за владение памятью и потокобезопасности. Документируйте, кто освобождает память, кто модифицирует аргументы, какие функции reentrant.
- Используйте явные размеры: всегда принимайте параметр длины буфера (типа $size\_t$) вместе с указателем и возвращайте количество записанных/необходимых байт. Не полагайтесь на терминаторы по умолчанию.
- Возвращайте полные статус-коды/errno-подобные значения; избегайте смешения ошибок и значений (например, возвращать $-1$ при успешном результате).
- Предпочитайте простые, малые функции с однозначной ответственностью; сложную логику разбивайте на приватные вспомогательные функции.
Минимизация экспозиции (интерфейс и сборка)
- Делайте типы опачными: в заголовке объявляйте только `typedef struct my_ctx my_ctx;`, реализацию держите в C-файле. Это предотвращает доступ к внутренним полям.
- Скрывайте символы сборкой: компилятор/линкер флаги `-fvisibility=hidden` и экспортируйте явный список API (version script). Это уменьшает поверхность атаки.
- Минимизируйте количество хедеров, которые вы включаете в публичный интерфейс. Не размещайте реализации в заголовках.
- Версионируйте API и поддерживайте обратную совместимость; помечайте устаревшее явно.
- Фейл-сейф по умолчанию: нежелательное поведение должно блокироваться, а не умалчиваться.
Проверка границ и безопасные практики написания
- Всегда проверяйте длины перед копированием/конкатенацией. При вычислении требуемого размера проверяйте переполнение: использовать `__builtin_mul_overflow`, `__builtin_add_overflow` или ручные проверки.
Пример проверки: при выделении буфера для $n$ элементов размера `elem_size`:
$$\text{if}\_\_builtin\_mul\_overflow(n,elem\_size,\&total)\text{— ошибка}$$ - Используйте `size_t` для размеров, проверяйте возвращаемые значения `malloc/calloc/realloc`. Не полагайтесь на `realloc(NULL, 0)` без проверки.
- Предпочитайте `memmove` для перекрывающихся областей; при копировании строк используйте явные длины, не `strcpy`/`strcat`.
- Явно обнуляйте/затирайте секреты перед освобождением (используйте `explicit_bzero`/`OPENSSL_cleanse` или встраиваемую функцию, помогающую избежать оптимизаций).
- Проверяйте входные данные: диапазоны индексов, корректность форматов, пределы глубины рекурсии/парсинга.
- Избегайте неограниченных выделений на основании внешних значений; устанавливайте разумные лимиты и параметры конфигурации.
- Минимизируйте использование макросов, varargs и нестандартных расширений, которые могут скрывать ошибки.
- Обрабатывайте все ошибки и ветки возврата; при ошибке оставляйте структуру/память в консистентном состоянии.
Сборка и эксплуатационные флаги для жёсткой защиты
- Компилируйте с защитными флагами: `-fstack-protector-strong`, `-D_FORTIFY_SOURCE=2`, `-fPIE -pie`, `-O2`, `-g`.
- Линкировка: `-Wl,-z,relro -Wl,-z,now`, `-Wl,--as-needed`.
- Включайте предупреждения компилятора и превращайте важные в ошибки: `-Wall -Wextra -Werror` (или частично).
- Используйте статическую проверку видимости: `-fvisibility=hidden` и экспорт контролируемого набора API.
Механизмы тестирования безопасности на этапе разработки
- Статический анализ: clang-tidy, clang static-analyzer, cppcheck, Coverity. Интегрировать в CI, фиксировать предупреждения заранее.
- Динамические анализаторы (санитайзеры): ASan (AddressSanitizer), UBSan (UndefinedBehaviorSanitizer), MSan (MemorySanitizer), TSAN (ThreadSanitizer). Запускать тесты с этими инструментами регулярно.
- Фуззинг: использовать libFuzzer, AFL, honggfuzz. Писать фузз‑таргеты для всех парсеров/десериализаторов; поддерживать и расширять corpus, добавлять словари и инварианты. Интегрировать покрытие (coverage-guided fuzzing).
- Тесты памяти/утечек: valgrind/helgrind, а также санитайзеры на CI.
- Модульные и интеграционные тесты: покрывать границы входных значений, отрицательные кейсы, стресс‑тесты (много последовательных вызовов, многопоточность).
- Property-based тестирование (например, QuickCheck-подобные инструменты) для проверки инвариантов.
- Символическое выполнение / тесты путей: KLEE или аналогичные инструменты для критичных функций.
- Regression/CI: автоматический сбор и прогон тестов при каждом PR; флагировать и блокировать мердж при новых предупреждениях санитайзеров/фаззера.
- API misuse tests: отрицательные проверки (передача NULL, коротких буферов, недопустимых размеров), тесты на повторное использование/двойное освобождение/вызовы в неправильном порядке.
- Threat modeling и code review: проводить обзоры безопасности, чеклист по CWE, проводить threat modeling до и после значительных изменений.
- Непрерывный фидбэк: собирать отчёты от статического анализа и фуззинга, triage и быстрые фиксы.
Краткий чеклист (быстрое напоминание)
- $1$ — явная ответственность за владение памятью и потокобезопасность.
- $2$ — всегда длина + указатель, проверки переполнений при вычислениях размеров.
- $3$ — опачные типы + скрытые символы.
- $4$ — санитайзеры и фуззинг в CI.
- $5$ — документировать ошибки, ограничения и безопасность API.
Если нужно — могу привести пример API-шаблона с объяснениями и примером защит при выделении/копировании.