Безопасность приложений

Приложение — целостная программная система, выполняющая функции для пользователей или других систем: веб-приложение, сервисный интерфейс, мобильная программа, корпоративная система, распределённая служба, встраиваемое управляющее ПО. Защищаются конфиденциальность персональных и служебных данных, их целостность и доступность сервиса, а также целостность кода и конфигурации, изменение которых искажает смысл остальных операций^[10].

Специфика прикладного уровня — опора на смыслы, а не на адреса: по порту 443 могут идти и запрос на оплату, и попытка изменить чужой профиль. Прикладной контроль различает операции, субъектов и объекты, проверяя допустимость конкретного действия конкретного участника над конкретными данными^[11].

Безопасность приложения оценивается по достижимым цепочкам, а не по наличию отдельных средств: правильная аутентификация бесполезна, если функция импорта файлов исполняет загруженный код с привилегиями службы, а надёжное шифрование теряет смысл при доступности ключа для модуля отладки^[7].

Для веб-приложений предмет охватывает разделение клиентской и серверной частей, сессии, файлы, межсайтовые взаимодействия, шаблонизацию и интерфейсы взаимодействия^[11]. В мобильных приложениях добавляется недоверие к среде устройства: локальное хранение, межприложенное взаимодействие, секреты на ненадёжных носителях^[12]. В корпоративных системах и интерфейсных службах главное — границы между службами: кто вправе вызывать операцию, как передаётся идентичность пользователя и как ограничиваются привилегии промежуточного сервиса^[7]. Во встраиваемых устройствах классические меры дополняются защитой прошивки и каналов диагностики^[10]. Независимо от формы задачи одинаковы: границы доверия, модель угроз, разграничение в архитектуре, обработка недоверенных данных, защита каналов, проверка, обновления и наблюдение^[7].

1960—1970-е: появление базовых принципов защиты (наименьшие привилегии, экономность механизма, полное посредничество) в системах разделения времени (Multics)^[3][13].

1980—1990-е: осознание масштаба угроз после инцидентов (Червь Морриса), начало фаззинга и систематизация классов уязвимостей^[14][15].

2000-е: оформление дисциплины. Внедрение Security Development Lifecycle (SDL), появление OWASP и переход к принципу «безопасность как качество кода»^[16][17].

2010—2020-е: стандартизация протоколов (OAuth, JWT, HSTS), рост внимания к мобильной безопасности, автоматизированному анализу (символьное исполнение) и защите цепочек поставки^[18][19].

Архитектура начинается с перечня свойств, обеспечиваемых механизмами: наименьшие привилегии, полное посредничество, разрешительные политики по умолчанию, разделение обязанностей, простота проверяемого ядра, открытость проекта при секретности ключей, приемлемость для пользователей^[3].

Разделение на компоненты держит опасные функции в узких областях: разбор загрузок не пересылает почту, рассылка не читает хранилище. Чем меньше пересечений привилегий, тем меньше доверенная вычислительная база каждой угрозы^[7]. Изоляция дополняется границами — пространства исполнения, песочницы, отдельные записи служб, — но прикладная логика не полагается на них как на единственную проверку^[10].

Отказоустойчивость защиты: ошибка одного механизма не приводит к полному обходу политики. Отсюда многослойность — фильтры и параметризация, проверка прав в сервисе и в хранилище, лимиты операций, целостность журналов, — и наблюдаемость: каждый отказ проверки фиксируется так, чтобы быть полезным при разборе^[7], — и наблюдаемость: каждый отказ проверки фиксируется так, чтобы быть полезным при разборе^[17].

Криптография применяется по готовым библиотекам с явным управлением ключами; «самодельная криптография» относится к каноническим антипаттернам^[24]. Проектирование различает подлинность источника, целостность, конфиденциальность, неотказуемость — и не подменяет одно другим^[7]. Безопасность по умолчанию и при отказе — требования к конфигурации и деградации: поведение при недоступности проверки, невыдаче маркера, переполнении журнала^[17]. Модель отказов — часть проектной документации, а не импровизация^[7].

Работа с вводом унифицируется на уровне инфраструктуры: единые типы, лимиты размеров, явные кодировки, отказ при неопознанном представлении. Противопоставление «данные vs код» реализуется библиотеками доступа, форматированием вывода и запретом конкатенации там, где значение попадает в интерпретатор^[22]. Проверка вводимых данных ограничивает и ресурсные последствия: размер, вложенность, скорость обработки^[15].

Обработка ошибок — часть политики: сообщения не раскрывают структур хранения и стеков, детали — в защищённом журнале, состояние при отказе последовательно^[17]. Журналирование охватывает события безопасности — входы, отказы права, смену ключей, административные действия — с защитой записей от модификации^[10]. Секреты отделяются от кода и конфигурации, ограничиваются областью действия и подлежат регулярной замене по сроку и событиям; их утечка в репозиторий — компрометация^[7]. Работа с памятью ведётся по правилам платформы: границы, валидация целочисленных значений, освобождение, контроль сериализуемых форм^[23].

Требования к коду закрепляются стандартами проекта, а не пересказываются в каждом модуле; отступления требуют обоснования и регистрации^[35]. Интеграционные конвенции (версионирование, идемпотентность, лимиты) — часть безопасности: они определяют поверхность злоупотреблений^[11].

Методы различаются доступом к коду и средой исполнения. Ревью проверяет семантику и согласованность с моделью угроз; статический анализ ищет шаблоны небезопасных операций и подозрительные потоки^[21]. Статические методы дают и ложные срабатывания, и пропуски; их ценность — в массовом охвате и воспроизводимости^[36][37].

Динамическое тестирование исполняет приложение: сценарии из модели угроз, сканирование сервиса, фаззинг с ориентацией на покрытие^[18]. Фаззинг связали с символьным исполнением, порождающим тесты для глубоких ветвей^[38][39]; промышленные движки показали достижимость автоматического поиска через распараллеливание и обратную связь по покрытию^[40]. Классические эксперименты с псевдослучайным вводом остаются методологическим основанием^[15].

Испытание на проникновение ищет достижимые цепочки; его результат — описание пройденных путей, а не гарантия отсутствия прочих^[21]. Приёмочная проверка — чек-лист по модели угроз: расхождение останавливает выпуск^[35].

Проверка сборки и состава: воспроизводимость образов, контроль зависимостей, сканирование слоёв, проверка подписей и сроков^[7]. Встроенные компоненты требуют дополнительных приёмов, включая аппаратные ограничения^[10].

Формальная верификация доказывает свойства критических компонентов для выбранной модели; области применения — протоколы, ядерные подсистемы, средства разграничения^[7]. Для прикладного уровня полнота разбивается о три факта: модель среды (компиляторы, библиотеки, ОС) сама требует допущений; спецификация может быть неверной; произвольная проверка программ неразрешима, и автоматизм ограничен эвристикой^[3]. Практическая ценность формальных подходов — дисциплина спецификации: граничные условия, инварианты, свойства отказов. Прикладная инженерия использует их фрагментарно: для протоколов, схем ключей, критичных состояний, отдельных механизмов разграничения^[34]. Где доказательство слишком дорого, его заменяют сужением области доверия и проверяемой изоляцией^[41].

В промышленной практике «безопасность встраивается, а не добавляется» — контрольные точки расставляются по фазам жизненного цикла^[21]. Требования — классификация данных; проектирование — модель угроз; реализация — стандарты и ревью; испытания — описанные методы; внедрение — эталон конфигурации; эксплуатация — наблюдение, патчи, пересмотр прав^[35].

Классификаторы CLASP ставят вопросы к архитектуре: кто обращается к данным, как проверяются входные сообщения, где границы доменов, что защищается криптографией, что журналируется^[42]. Методика превращает заботу о «надёжности» в список решений^[16].

Контрольные точки дают право остановить выпуск: непроверенные изменения интерфейсов, новые источники ввода, перенос данных, смена поставщика аутентификации требуют возврата к предыдущей фазе^[35]. Автоматизация переносит проверки в непрерывную интеграцию: сборка невозможна без дешёвых тестов, дорогие выполняются по регламенту^[18].

Обучение — организационная часть дисциплины: результаты проверок возвращаются в стандарты и шаблоны^[21]. Зрелость измеряется воспроизводимостью: один класс изменений проходит одни проверки вне зависимости от команды^[35].

Безопасность начинается до запуска: конвейер — часть доверенной вычислительной базы. Настройки компиляции включаются на уровне стандарта проекта; компилятор и линковщик — проверяемая часть сборки^[7]. Зависимости фиксируют точные версии и контрольные значения, а повторная сборка обязана воспроизводить артефакт, иначе расхождение «проверенного» и «выпущенного» неотличимо от подмены^[23]. Секреты сборки и доступы к реестрам ограничиваются ролями и сроком^[35]. Среда, в которой осуществляется запуск, отделяет права сервиса от администратора, ограничивает хранилища, исключает инструменты разработки^[10]. Поведение при недоступности внешних служб проверяется отдельно: деградация не открывает «аварийный» путь с пониженной проверкой^[7].

Уязвимость — не только дефект кода, но и процесс: приём сообщений, подтверждение, оценка воздействия, выпуск исправления, уведомление зависимых^[21]. Координация оформилась после первых крупных инцидентов с червями и фиксирует роли групп реагирования и сроки^[43]. Совместное раскрытие балансирует защиту пользователей и открытость исследований: ранняя публикация расширяет окно риска^[14][44]. Критичность опирается на достижимость, права, данные и последствия: распространённая ошибка без пути эксплуатации не тождественна редкой с полным захватом^[10]. Шкалы дают общий язык, но не заменяют контекстного разбора^[23]. Для потребителя важны наличие исправления, обходных мер и сведений о затронутых версиях^[21].