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

Часть 3.

А у нас на очереди, принцип разделения интерфейсов (Interface Segregation Principle, ISP — пожалуй, один из наиболее простых в SOLID), гласящий:

Клиенты не должны зависеть от интерфейсов, которые они не используют.

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

С точки зрения безопасности, ISP напрямую перекликается с принципом наименьших привилегий (Least Privilege). «Толстый» интерфейс — это расширенная поверхность атаки: клиент получает доступ к методам, которые ему для работы не нужны. Если один из таких методов оказывается привилегированной операцией, а её защита оказывается слабее ожидаемой, то любой потребитель интерфейса внезапно получает доступ к критичному функционалу.

💡Тривиальный пример:

interface IUserService {
    User getProfile(Long id);
    void updateProfile(User u);
    void resetPassword(String email);
    void deleteUser(Long id);
    void assignRole(Long id, Role r);
    List<User> exportAll();
}

Потребитель, которому нужно лишь отображать профиль, вынужден зависеть от deleteUser, assignRole и exportAll. Если защита реализована на уровне имплементации, а не интерфейса, то одна ошибка авторизации — и профильный компонент может удалять пользователей.

❗Что делать?

Нарушения ISP порождают целый ряд CWE, связанных с чрезмерно широким доступом:

• CWE-749: Exposed Dangerous Method or Function
• CWE-306: Missing Authentication for Critical Function
• CWE-250: Execution with Unnecessary Privileges

В примере выше правильнее ввести два интерфейса, соответствующие уровням привилегий принятой в приложении модели доступа:

interface IUserProfile {
    User getProfile(Long id);
    void updateProfile(User u);
}

interface IUserAdmin {
    void deleteUser(Long id);
    void assignRole(Long id, Role r);
    List<User> exportAll();
}

Компоненту, работающему с профилями, IUserAdmin будет попросту недоступен, даже при наличии бага в авторизации.

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

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

💻 Go — не запрещает «толстые» интерфейсы, но поощряет их дробление через удобство композиции и интерфейсы потребителей. Стандартную библиотеку этого языка вполне можно рассматривать, как эталон соблюдения ISP.

👣 Rust — та же композиционная история, но через трейты и необходимость соблюдения «orphan rule».

Забавно, что в этих языках есть и явный анти-паттерн, который не запрещен: пустой интерфейс (interface{} в Go / dyn Any в Rust). Это нарушение ISP: клиент зависит от всего и ни от чего одновременно. Они существуют для низкоуровневых нужд, и их использования стоит по-возможности избегать.

🐛 Жизненное

CVE-2023-22515 — Atlassian Confluence (Broken Access Control, CVSS 10.0).

Confluence использовал фреймворк XWork2 для маршрутизации HTTP-запросов. Через единый веб-интерфейс были доступны как пользовательские действия (просмотр/редактирование страниц), так и привилегированные операции первичной настройки (/setup/setupadministrator.action). В терминах ISP — один «толстый» интерфейс маршрутизации обслуживал и рядовых пользователей, и административный мастер установки.

Атакующий отправлял запрос, манипулирующий свойством bootstrapStatusProvider.applicationConfig.setupComplete через механизм привязки параметров XWork2, «сбрасывая» флаг завершённости установки. После этого endpoint создания администратора становился доступен без аутентификации — атакующий создавал собственный админский аккаунт и получал полный контроль.

Если бы интерфейс маршрутизации был сегрегирован (setup-эндпоинты физически изолированы от пользовательских, с отдельным middleware авторизации), манипуляция параметрами одного интерфейса не открыла бы доступ к другому.

В патче (разбор) эндпоинты, относящиеся к установочным действиям, блокируются после первичной установки, а маршрутизация разделена.

Часть 5.

⚠ TL;DR: «Толстый» интерфейс — расширенная поверхность атаки. Если клиент видит метод, то рано или поздно кто-то найдёт способ его вызвать. Стоит разделять интерфейсы, как по привилегиям, так и по границам доверия.

#безопасность_кода #гайд