Основы безопасного кода

8 мин чтения·Для руководителя разработки и лидера безопасности

Большинство взломов — не результат изощрённых атак. Это эксплуатация давно известных классов уязвимостей, которые тем не менее продолжают появляться в новом коде. По данным Positive Technologies, уязвимости веб-приложений остаются одним из главных векторов атак на российские компании.

Эта глава не учит разработчиков писать код. Она объясняет руководителю, какие категории рисков существуют, чего требовать от команды — и как убедиться, что требования выполнены. Именно это является задачей лидер безопасности (лидера безопасности — сотрудника, ответственного за вопросы ИБ в команде как дополнительную зону ответственности): перевести технические риски в управленческие требования.

OWASP Top 10: классы уязвимостей в деловых терминах

OWASP (Open Web Application Security Project) — международный некоммерческий проект, ведущий список десяти наиболее критичных классов уязвимостей веб-приложений. Список обновляется раз в несколько лет на основе реальных данных с тысяч аудитов и пентестов.

Текущая версия (2021) — фактический стандарт для технических требований к безопасности кода. На него ссылаются корпоративные клиенты в опросниках по ИБ и регуляторы при оценке мер защиты.

A01: нарушение контроля доступа

Что происходит: пользователь получает доступ к данным или функциям, которые ему не предназначены. Классический пример: меняя user_id=123 в адресной строке на user_id=124, он видит данные другого клиента.

Бизнес-риск: утечка персональных данных и ответственность по 152-ФЗ «О персональных данных», доступ к финансовой информации или коммерческой тайне конкурентов.

Что требовать: проверка прав доступа происходит на стороне сервера при каждом запросе — не только в интерфейсе. Принцип «запрещено по умолчанию»: доступ явно разрешается, а не явно запрещается. Ошибки авторизации фиксируются в журнале.

A02: сбои криптографии

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

Бизнес-риск: при взломе базы данных злоумышленник сразу получает все пароли пользователей в читаемом виде. С ними он попробует войти в личный кабинет, корпоративную почту и банковское приложение — где пользователи зачастую используют тот же пароль.

Что требовать: пароли хэшируются алгоритмами bcrypt или Argon2 (не MD5 и не SHA1 — они устарели). Все соединения — только по HTTPS/TLS 1.2+. Секреты (API-ключи, пароли к базам данных) хранятся в менеджере секретов — Пассворк или HashiCorp Vault/OpenBao — и никогда в коде или конфигурационных файлах.

A03: инъекции

Что происходит: данные, введённые пользователем, попадают в запрос к базе данных, операционной системе или другому интерпретатору без проверки.

Бизнес-риск: полная компрометация базы данных. Атакующий читает, изменяет или удаляет данные. SQL-инъекция была причиной большинства громких утечек последних двадцати лет.

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

-- Уязвимо: входные данные вставляются напрямую в запрос
SELECT * FROM users WHERE login = 'admin' OR '1'='1'
-- Результат: вернёт все записи — база данных скомпрометирована

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

A04: небезопасный дизайн

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

Бизнес-риск: такие проблемы не исправляются точечным патчем — требуется переработка функциональности. Это дорого и занимает недели.

Что требовать: новые функции, связанные с аутентификацией, обработкой персональных данных или платёжными операциями, проходят анализ угроз (threat modeling) до начала разработки. Лидер безопасности участвует в проектировании.

A05: небезопасная конфигурация

Что происходит: стандартные настройки оставлены без изменений: не изменены пароли по умолчанию, включён режим отладки в продакшне, открыты лишние сервисы, отсутствуют HTTP-заголовки безопасности.

Бизнес-риск: атакующий использует известные уязвимости конфигурации по умолчанию — для этого не нужна высокая квалификация, достаточно автоматического сканера.

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

A06: уязвимые и устаревшие компоненты

Что происходит: ваше приложение использует библиотеки и фреймворки с опубликованными уязвимостями. Уязвимость в Log4Shell (2021) затронула тысячи приложений по всему миру — атакующие автоматически сканировали интернет в поисках уязвимых систем.

Бизнес-риск: атаки на цепочку поставок. Одна уязвимая зависимость компрометирует всё приложение. По данным российских ИБ-компаний, значительная доля инцидентов связана именно с устаревшими компонентами.

Что требовать: автоматическая проверка зависимостей при каждой сборке (инструменты SCA). Критичные уязвимости в зависимостях блокируют выход в продакшн. Политика: обновления безопасности применяются в течение 72 часов для критичных CVE.

A07: сбои идентификации и аутентификации

Что происходит: слабая защита процесса входа: нет защиты от перебора паролей, сессии не истекают, токены восстановления пароля действительны неограниченно долго.

Бизнес-риск: захват аккаунтов клиентов или сотрудников. Скомпрометированный аккаунт администратора — это полный доступ к данным всех пользователей.

Что требовать: ограничение количества попыток входа, тайм-ауты сессий, MFA для привилегированных аккаунтов (разобрано в модуле 2). Обязательно проверьте, закрыты ли эти базовые меры в вашем приложении.

A08: нарушения целостности программного обеспечения

Что происходит: в процессе разработки или доставки кода используются небезопасные компоненты — скомпрометированный пакет, библиотека с бэкдором, уязвимый CI/CD-пайплайн.

Бизнес-риск: атака на цепочку поставок. Злоумышленник встраивает вредоносный код не в ваше приложение напрямую, а в инструментарий разработки или зависимости. Компании с автоматической проверкой обнаружили вредоносные версии пакетов в течение часов; те, у кого такой проверки не было, выпустили скомпрометированные сборки.

Что требовать: проверка целостности зависимостей при сборке, изолированные среды CI/CD, минимальные привилегии для пайплайна. Детально — в главе о безопасности CI/CD.

A09: недостаточное журналирование и мониторинг

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

Бизнес-риск: невозможно обнаружить атаку в процессе и провести расследование после инцидента. Кроме того, это прямое нарушение обязательных требований: Приказ ФСТЭК России № 21 требует регистрации событий безопасности для систем, обрабатывающих персональные данные.

Что требовать: централизованный журнал событий безопасности (успешный и неудачный вход, изменение прав доступа, критичные действия с данными). Журналы хранятся отдельно от приложения и защищены от изменения. Алерты на подозрительные паттерны.

A10: подделка запросов на стороне сервера (SSRF)

Что происходит: приложение принимает URL от пользователя и обращается к нему от имени сервера. Атакующий подставляет адреса внутренних сервисов — баз данных, сервисов конфигурации, внутреннего API.

Бизнес-риск: доступ к внутренней инфраструктуре, которая не предназначена для внешних запросов. Особенно опасно при использовании облачных платформ (Yandex Cloud, VK Cloud, Selectel), где метаданные инстанса доступны по предсказуемым внутренним адресам.

Что требовать: любые URL, принимаемые от пользователей, проверяются по белому списку разрешённых доменов.

Что требовать от команды: семь принципов

Сведите требования к ключевым практикам, которые закрывают большинство рисков из OWASP Top 10:

1. Проверка входных данных на сервере — для любого пользовательского ввода, без исключений. Клиентская валидация не считается защитой.
2. Параметризованные запросы — к базам данных всегда; подстановка строк через конкатенацию запрещена.
3. Централизованное управление секретами — никаких паролей и ключей в коде; Пассворк или HashiCorp Vault/OpenBao для хранения и ротации.
4. Проверка прав доступа на бэкенде — при каждом запросе, не только в интерфейсе.
5. Безопасное хэширование паролей — bcrypt или Argon2; MD5 и SHA1 запрещены.
6. Журналирование событий безопасности — вход, выход, изменение прав, критичные действия с данными.
7. Автоматическая проверка зависимостей — SCA-инструмент в CI/CD-пайплайне, критичные CVE блокируют сборку.

Как проверить выполнение требований

Руководитель не проверяет код лично. Задайте лидеру безопасности эти контрольные вопросы на ежемесячном статусе:

• Работает ли SAST-сканер (статический анализ кода) в пайплайне? Сколько открытых критичных находок прямо сейчас?
• Проводилось ли сканирование репозитория на наличие секретов? Когда в последний раз?
• Какой процент зависимостей проверен на уязвимости?
• Есть ли журнал событий безопасности? Покажите последние 30 дней.
• Были ли инциденты или подозрительная активность за последний месяц?

Эти вопросы создают управленческий контроль без погружения в технические детали.

✓Управленческий чек-лист

Перед переходом к следующей главе убедитесь, что в команде реализовано следующее:

• Лидер безопасности ознакомлен с OWASP Top 10 и знает, что требовать от разработчиков
• Принято командное соглашение: пароли хэшируются bcrypt/Argon2
• Секреты не хранятся в коде — проведено сканирование репозитория (включая историю)
• Введено обязательное правило: параметризованные запросы к базам данных
• Автоматическая проверка зависимостей (SCA) запущена в пайплайне
• Определён процесс: как команда реагирует на критичную находку SAST
• Настроен журнал событий безопасности с хранением не менее 90 дней

См. также

• Требования безопасности — как превратить риски в требования
• Учебная программа — обучение разработчиков
• Безопасность CI/CD — автоматические проверки кода

Что дальше

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