Принципы и паттерны безопасной разработки: SRP

Хоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First» ✝️ В лучших традициях Shift Left Security, начинать стоит с базовых принципов разработки, таких, как SOLID, YAGNI, DRY, KISS, чистый код с архитектурой и т.п. Именно они позволяют заложить в архитектуру и реализацию приложения правильный фундамент, на котором будет гораздо проще и дешевле реализовывать прочие решения и этапы внедрения DevSecOps.

Начнём с принципа единственной ответственности (Single Responsibility Principle, SRP — первая буква в SOLID), утверждающему, что каждый класс или модуль должен иметь единственную ответственность (только одну причину для изменения). С точки зрения безопасности SRP способствует изолированности компонентов и чётким границам доверия в коде, что существенно облегчает последующую работу с моделью угроз. Когда компонент сконцентрирован на одной задаче, его легче проверять на уязвимости и логические ошибки. Это снижает риск скрытых багов, возникающих при смешении разных обязанностей (например, проверка прав доступа вперемешку с бизнес-логикой). Как отмечают эксперты, соблюдение SRP «ограничивает случайную эскалацию привилегий и упрощает поиск ошибок», а также уменьшает общую поверхность атаки за счёт уменьшения сложности компонентов.

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

Нарушение SRP может выглядеть так:

class UserAuth {
    public Session Authenticate(string username, string password) {
        if (!PasswordChecker.IsStrong(password)) {
            throw new Exception("Weak password");
        }

        var user = userRepository.CreateUser(username, password);
        return sessionManager.StartSession(user);
    }
}

В этом коде смешаны проверки безопасности (надежность пароля) и бизнес-логика сессии. Если разработчик решит изменить логику создания сессии, есть риск ненароком ослабить или обойти шаг проверки пароля. Правильнее разделить эти обязанности на отдельные классы (например, PasswordChecker, UserRepository, SessionManager), а UserAuth сделать оркестратором. Тогда код станет понятнее и безопаснее: каждая часть легко проверяется и тестируется отдельно.

Забавно, что «живым» примером последствий нарушения SRP является одна из наиболее нашумевших уязвимостей в библиотеке логирования Apache Log4j 2 CVE-2021-44228, известная как Log4Shell. Логирование — это задача записи сообщений, но Log4j помимо этого выполнял ещё и роль интерпретатора/поисковика ресурсов (JNDILookup). Фактически, в библиотеку логирования «просочилась» функциональность, выходящая за рамки её единственной ответственности — она не только записывала логи, но и могла выполнять сетевые запросы и загружать код. Если бы Log4j ограничился исключительно записью логов, без вычисления каких-либо lookup-выражений, уязвимость бы не возникла. И действительно, исправление проблемы заключалось в отключении/удалении функции JNDI Lookup из Log4j.

Соблюдение SRP помогает избежать многих CWE, связанных с логическими ошибками и неправильной проверкой условий, которые трудно выявить в нагромождённом коде. Например, SRP предотвращает появление скрытых дефектов управления доступом, из разряда CWE-732, CWE-862, возникающих, когда проверка прав смешана с другими функциями и может быть пропущена.

В целом, SRP укрепляет принцип «secure by design»: мелкие простые модули легче защитить и проверить.

🔍 Наиболее интересные уязвимости

🐛 CVE-2025-57822, обнаруженная в Next.js (версии до 14.2.32 и 15.4.7), приводит к Server-Side Request Forgery (SSRF). При использовании next() без явной передачи объекта запроса возможно некорректное перенаправление пользовательских заголовков в self-hosted приложениях. В патче была изменена логика resolve-routes.ts: обработка Location выполняется только при статусах из allowedStatusCodes (redirect), иначе заголовок просто пробрасывается без переписывания URL

🐛 CVE-2025-58158, обнаруженная в Harness Open Source (версии до 3.3.0), приводит к Path Traversal. Из-за некорректной фильтрации пути загрузки API для git LFS позволяет аутентифицированному пользователю записывать файлы в любую директорию на сервере. В патче была добавлена проверка существования LFS-объекта, а также метод записи изменен на bytes.Reader()

🐛 CVE-2025-58048, обнаруженная в Paymenter (версии до 1.2.11), приводит к Unrestricted File Upload. Уязвимость позволяет злоумышленнику, имеющему аутентификацию, загружать произвольные файлы через функциональность вложений в тикетах, что может привести к выполнению произвольных системных команд в контексте пользователя веб-сервера. В патче загрузка вложений полностью отключена: из Livewire-компонентов удалены WithFileUploads, массив $attachments и метод completeUpload(); в клиентском шаблоне EasyMDE выключен uploadImage: false и убрана кнопка/обработчик imageUploadFunction

🐛 CVE-2025-57818, обнаруженная в Firecrawl до версии 2.0.1, представляет собой уязвимость типа Server-Side Request Forgery (SSRF). Уязвимость возникает из-за недостаточной проверки URL-адресов, используемых в функциональности вебхуков, что позволяет аутентифицированным пользователям отправлять запросы на внутренние URL. В патче была заменена отправка через axios на undici.fetch() с использованием secureDispatcher из safeFetch

🐛 CVE-2025-57820, обнаруженная в sveltejs/devalue в версиях до 5.3.2, приводит к Prototype Pollution. Проблема заключалась в том, что devalue.parse позволял задавать свойство proto в объектах, что приведет к загрязнению прототипов. В исправлении была добавлена проверка типа индекса (typeof index !== "number" → throw) и явный запрет ключа proto