Основы безопасного кода
Большинство взломов — не результат изощрённых атак. Это эксплуатация давно известных классов уязвимостей, которые тем не менее продолжают появляться в новом коде. По данным 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:
- Проверка входных данных на сервере — для любого пользовательского ввода, без исключений. Клиентская валидация не считается защитой.
- Параметризованные запросы — к базам данных всегда; подстановка строк через конкатенацию запрещена.
- Централизованное управление секретами — никаких паролей и ключей в коде; Пассворк или HashiCorp Vault/OpenBao для хранения и ротации.
- Проверка прав доступа на бэкенде — при каждом запросе, не только в интерфейсе.
- Безопасное хэширование паролей — bcrypt или Argon2; MD5 и SHA1 запрещены.
- Журналирование событий безопасности — вход, выход, изменение прав, критичные действия с данными.
- Автоматическая проверка зависимостей — SCA-инструмент в CI/CD-пайплайне, критичные CVE блокируют сборку.
Как проверить выполнение требований
Руководитель не проверяет код лично. Задайте лидеру безопасности эти контрольные вопросы на ежемесячном статусе:
- Работает ли SAST-сканер (статический анализ кода) в пайплайне? Сколько открытых критичных находок прямо сейчас?
- Проводилось ли сканирование репозитория на наличие секретов? Когда в последний раз?
- Какой процент зависимостей проверен на уязвимости?
- Есть ли журнал событий безопасности? Покажите последние 30 дней.
- Были ли инциденты или подозрительная активность за последний месяц?
Эти вопросы создают управленческий контроль без погружения в технические детали.
Перед переходом к следующей главе убедитесь, что в команде реализовано следующее:
- Лидер безопасности ознакомлен с OWASP Top 10 и знает, что требовать от разработчиков
- Принято командное соглашение: пароли хэшируются bcrypt/Argon2
- Секреты не хранятся в коде — проведено сканирование репозитория (включая историю)
- Введено обязательное правило: параметризованные запросы к базам данных
- Автоматическая проверка зависимостей (SCA) запущена в пайплайне
- Определён процесс: как команда реагирует на критичную находку SAST
- Настроен журнал событий безопасности с хранением не менее 90 дней
См. также
- Требования безопасности — как превратить риски в требования
- Учебная программа — обучение разработчиков
- Безопасность CI/CD — автоматические проверки кода
Что дальше
Вы понимаете, какие классы уязвимостей существуют и что требовать. Следующий шаг — как превратить эти требования в проверяемые критерии приёмки и встроить их в процесс разработки так, чтобы выполнение можно было доказать аудитору или корпоративному клиенту.