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

Обзор и мотивация

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

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

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

См. также: глава 4.1 (основы безопасности, моделирование угроз и жизненный цикл безопасной разработки), глава 10.3 (цепочка поставки открытого исходного кода и лицензирование) и глава 10.2 (SBOM, риск и гарантии).

Ключевые принципы

Никогда не доверяйте вводу. Воспринимайте все данные, пересекающие границу доверия, как враждебные, пока они не проверены.
Безопасные значения по умолчанию. Безопасный путь должен быть лёгким; небезопасное поведение должно требовать намеренных заметных усилий.
Отказывайте закрытым. Когда проверка безопасности не может завершиться, отказывайте в доступе, а не разрешайте его.
Эшелонированная защита на уровне приложения. Сочетайте проверку, кодирование, параметризацию и защиты фреймворка; не полагайтесь на одно.
Наименьшие привилегии для идентичностей и токенов. Ограничивайте учётные данные узко и быстро истекайте их.
Ваши зависимости это ваш код. Вы отвечаете за безопасность всего, что поставляете, включая сторонние компоненты и компоненты с открытым кодом.
Стандарты вместо импровизации. Используйте проверенные рамки вроде ASVS проекта OWASP (Open Worldwide Application Security Project), а не изобретайте собственные средства безопасности.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Купить/принять провайдера идентичности (OIDC)	Проверен боем, MFA встроен, меньше кода для защиты	Зависимость от поставщика, усилия интеграции, цена
Построить собственную аутентификацию	Полный контроль, нет внешней зависимости	Чрезвычайно легко ошибиться, высокое сопровождение
Строгая проверка по списку разрешённого	Блокирует целые классы уязвимостей	Может сломать законные крайние случаи, больше работы заранее
Краткоживущие учётные данные	Малое окно взлома, автоматический отзыв	Требует надёжной инфраструктуры выдачи
Агрессивные обновления зависимостей	Меньше известных уязвимостей	Отток, возможные ломающие изменения, бремя тестирования
SBOM + подпись + происхождение	Быстрый отклик на инциденты, проверяемое доверие	Вложения в инструменты и процесс, смена культуры

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

Вопросы для обсуждения с командой

Какие средства контроля ASVS вы встроите в свой фреймворк «проторённой дороги», чтобы инженеры получали их даром? Самый рычажный ход для большой команды сделать безопасный путь значением по умолчанию, чтобы средство контроля, написанное один раз в общем фреймворке, защищало каждый принявший его сервис. Решите, какие требования ASVS (параметризованные запросы, кодирование вывода, безопасные флаги сессий, проверки авторизации на сервере) принадлежат шаблону, а не памяти каждого инженера. Для корпоративных и государственных портфелей также решите, каким приложениям нужен ASVS уровня 2, а каким уровня 3, и свяжите это с чувствительностью данных, которых касается каждое. Принесите список ваших сервисов и отметьте, какие уже наследуют эти умолчания, а какие реализуют безопасность вручную, потому что самодельные это места, где прячутся внедрение и сломанный контроль доступа. Если безопасные умолчания живут только на странице вики, их пропустят под давлением поставки, поэтому положите их в код.
Как вы найдёте и исправите нарушенную авторизацию на уровне объектов по каждому API, а не только по новым? Доступ к записи другого пользователя заменой идентификатора один из самых частых и серьёзных дефектов API, и он прячется в старых конечных точках, предшествующих вашим текущим стандартам. Авторизация на сервере для каждого запроса и каждого объекта это правило, но трудно проверить, что оно держится по разросшейся многолетней кодовой базе, написанной многими руками. Решите, будете ли вы централизовать логику авторизации, добавлять автоматические тесты, пытающиеся получить доступ между арендаторами, или сначала запустите целевое тестирование против ваших наиболее рискованных API. Принесите опись конечных точек, открывающих идентификаторы объектов, и ранжируйте их по чувствительности возвращаемого. Без намеренной проверки вы будете продолжать поставлять этот дефект и обнаружите его, только когда его найдёт исследователь или атакующий.
Каков ваш план на следующую широко распространённую уязвимость зависимости: как быстро вы можете найти и пропатчить каждый затронутый сервис? Когда критичный дефект появляется в популярной библиотеке, компании с точной SBOM определяют затронутые сервисы за часы, тогда как другие ищут недели, и этот разрыв в скорости решает, сколько ущерба вы понесёте. Решите сейчас, производите ли вы спецификацию состава программного обеспечения для каждого артефакта, работает ли сканирование зависимостей в каждом конвейере и кто владеет решением об аварийном патче. Для регулируемых и государственных покупателей SBOM и подписанное происхождение всё чаще условие ведения бизнеса, поэтому эта готовность также защищает выручку. Принесите честный ответ на учение: выберите широко используемую библиотеку и засеките, сколько времени займёт перечисление каждого сервиса, который её поставляет. Если ответ измеряется днями, вложитесь в опись и подпись, прежде чем следующий инцидент вас к этому вынудит.
Как вы перейдёте от долгоживущих статических секретов к краткоживущим автоматически выдаваемым учётным данным и какие системы блокируют это сегодня? Зашитые и долгоживущие секреты вечная причина взломов, а исправление, краткоживущие учётные данные, выдаваемые по требованию, зависит от инфраструктуры выдачи, которой старые системы нередко не могут пользоваться. Для большой команды опасность в неравномерном принятии: современная платформа ротирует ключи ежечасно, а унаследованный сервис всё ещё поставляет статический пароль базы данных в файле конфигурации. Решите, какие нагрузки могут потреблять менеджер секретов или систему идентичности нагрузок уже сейчас, каким нужны сначала вложения и кто владеет ранбуком ротации в миг подозрения на утечку ключа. Принесите опись каждых используемых учётных данных, их срока жизни, радиуса поражения при раскрытии и поймало бы ли их сканирование коммитов до слияния. В корпоративной и государственной среде свяжите это с аудитом: проверяющие всё чаще ожидают свидетельств ротации, ограниченного доступа и журналирования доступа для каждого секрета, а статические учётные данные, которые нельзя ротировать без простоя, находка, ждущая оформления.
Где вы всё ещё запускаете самодельную или несогласованную аутентификацию и каков план консолидации на проверенных протоколах? Построение аутентификации один из легчайших способов внести тонкие эксплуатируемые дефекты, однако большинство больших хозяйств несёт хотя бы один унаследованный поток входа, предшествующий решению стандартизироваться на OAuth 2.0 и OIDC. Конкурирующие давления реальны: миграция старого потока рискует сломать существующих пользователей и интеграции, а его оставление держит высокоценную мишень недозащищённой. Решите, консолидируетесь ли вы на единственном провайдере идентичности, единообразно принуждаете ли к MFA и задаёте ли срок вывода каждого заказного потока или принимаете документированные исключения с компенсирующими средствами контроля. Принесите карту каждого пути аутентификации в парке: какие принуждают к MFA, какие хранят пароли современным требовательным к памяти хэшем, а какие заказные. Для корпоративных и государственных портфелей добавьте угол соответствия: стандарты вроде NIST SP 800-63 задают конкретные ожидания по гарантии идентичности, а самодельный поток, не способный их продемонстрировать, не переживёт аудита или рецензии разрешения на эксплуатацию.
Как вы проверяете, что эти средства контроля действительно держатся в эксплуатации, и можете ли вы доказать это свидетельствами, а не утверждением? Написать безопасное умолчание не то же самое, что знать, что каждый сервис всё ещё его соблюдает, а средства контроля тихо гниют по мере изменения кода, накопления исключений и выпуска новых конечных точек. Для большой команды вопрос в покрытии: какие сервисы запускают статический анализ, сканирование зависимостей и динамическое тестирование или тестирование на проникновение и как вы знаете, что те, что их пропускают, не ваши самые рискованные приложения? Решите, какая проверка обязательна в конвейере, а какая периодична, кто сортирует находки и какие свидетельства вы сохраняете, чтобы показать, что средство контроля было протестировано и проходило на данную дату. Принесите вашу текущую карту покрытия, среднее время устранения по серьёзности и список приложений без недавнего теста. В регулируемых и государственных контекстах эти свидетельства не необязательны: аудиторы, уполномоченные должностные лица и расследователи взломов все спрашивают доказательство того, что средства контроля проверялись, а политика без записей тестов редко их удовлетворяет.

Взгляд по секторам

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

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

Крупная организация. По многим командам трудность в согласованности: встраивайте средства контроля ASVS в фреймворки «проторённой дороги», чтобы каждый новый сервис получал параметризованные запросы, кодирование вывода, безопасные сессии и авторизацию на сервере даром. Ведите точные SBOM и сканирование зависимостей по всему парку, чтобы следующая широко распространённая уязвимость библиотеки решалась за часы, а не недели, и централизуйте политику авторизации, чтобы доступ между арендаторами стал тестируемым. Стандартизируйтесь на одном провайдере идентичности с принудительной MFA и управляйте безопасностью приложений как управляемым портфелем с уровнями ASVS по риску и проверяемыми свидетельствами.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность определяют средства контроля, которые вы должны демонстрировать, а не просто реализовывать. Проверяйте сервисы для граждан по OWASP ASVS на уровне, соответствующем чувствительности данных, подписывайте каждый развёрнутый артефакт и аттестуйте его происхождение по SLSA, чтобы удовлетворить мандаты цепочки поставки, и выдавайте краткоживущие учётные данные из центрального хранилища с полным журналированием доступа. Ожидайте, что вам придётся показывать аудиторам и уполномоченным должностным лицам документированную цепочку хранения от исходника до эксплуатации, и выравнивайте гарантию идентичности по опубликованным стандартам вроде NIST SP 800-63.

Примеры

Стартап. Команда SaaS из трёх инженеров пропускает построение собственного входа и принимает управляемого провайдера OIDC в первый день, получая MFA и безопасный сброс паролей, не пиша критичный для безопасности код, в котором не может позволить себе ошибиться. Она опирается на ORM фреймворка, так что запросы параметризованы по умолчанию, держит секреты в менеджере секретов платформы, а не в файлах .env, которые коллега может случайно закоммитить, и включает автоматическое сканирование зависимостей, открывающее запрос на слияние, когда библиотеку нужно пропатчить. Ничто из этого не замедляет команду, а значит один утёкший ключ или один внедрённый запрос не прикончат компанию, пока у неё нет клиентов.

Крупная организация. Розничная платформа, обслуживающая десятки миллионов покупателей, стандартизирует аутентификацию на OIDC через единственного провайдера идентичности, принуждая к MFA для персонала и ступенчатой аутентификации для высокоценных изменений учётной записи. Весь доступ к базе данных идёт через ORM, настроенный на параметризацию запросов, а политика безопасности содержимого подстраховывает кодирование вывода. После широко разрекламированной уязвимости в популярной библиотеке журналирования SBOM компании позволяет определить каждый затронутый сервис за часы и пропатчить их за два дня, тогда как конкуренты без описей искали недели.

Государственный сектор. Федеральное ведомство пособий строит сервисы для граждан, проверенные по OWASP ASVS уровня 2, с уровнем 3 для компонентов, работающих с наиболее чувствительными записями. Секреты живут в центральном хранилище, выдающем краткоживущие учётные данные; сканирование коммитов блокирует любой утёкший ключ. Каждый развёрнутый артефакт подписан, а его происхождение аттестовано по SLSA, что удовлетворяет федеральному мандату на проверяемые цепочки поставки программ и даёт аудиторам ясную цепочку хранения от исходника до эксплуатации.

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

Собственная криптография или аутентификация. Почти всегда порождает тонкие эксплуатируемые дефекты.
Проверка только на стороне клиента. Обходится тривиально; сервер должен перепроверять всё.
Очистка по чёрному списку. Попытка вырезать «плохие» символы вместо разрешения хороших по списку; атакующие находят пробелы.
Секреты в исходниках или файлах среды. Самая частая причина утечек учётных данных.
Игнорирование авторизации при доступе к объектам. Допущение, что аутентифицированный пользователь может получить доступ к любому объекту, идентификатор которого он способен угадать.
Зависимости «поставил и забыл». Никогда не обновлять сторонние компоненты, пока взлом не вынудит.
Воспринимание Top 10 как финиша. Это пол, а не исчерпывающий стандарт; используйте ASVS для глубины.
Журналирование чувствительных данных. Пароли, токены и PII (персонально идентифицируемая информация) в журналах становятся взломом, ждущим своего часа.

Модель зрелости

Уровень 1: Начальный. Безопасность приложений зависит от знаний отдельных разработчиков и реагирует только после инцидентов. Нет стандартных средств контроля. Секреты лежат в исходниках. Зависимости редко обновляются. Аутентификация заказная и стихийная, а дефекты внедрения или сломанного контроля доступа находятся случайно, а не процессом.

Уровень 2: Развитие. Появляются базовые практики, различающиеся по командам. Осведомлённость об OWASP Top 10 распространяется, есть некоторые защиты на уровне фреймворка, менеджер секретов существует, но используется неравномерно. Сканирование зависимостей запускается время от времени. Новые системы принимают стандартного провайдера идентичности, тогда как старые сервисы сохраняют свои самодельные потоки входа нетронутыми.

Уровень 3: Стандартизация. Средства контроля документированы и соблюдаются по организации. Требования на основе ASVS заданы по уровню риска, параметризованные запросы и кодирование вывода норма, а центральный провайдер идентичности с MFA обязателен. Секреты управляются и сканируются автоматически, SBOM производятся, а сканирование зависимостей работает в каждом конвейере.

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

Уровень 5: Оркестрация. Безопасность непрерывно улучшается и интегрирована по организации. Безопасные умолчания встроены во фреймворки «проторённой дороги», так что безопасный путь автоматичен, краткоживущие учётные данные используются повсюду, а полная гарантия цепочки поставки с подписью и происхождением (SLSA) стандартна. Проверка непрерывна, реакция на новые уязвимости быстра и измерима, а каждый инцидент питает общие шаблоны, так что одно исправление укрепляет весь парк.

Идеи для обсуждения

Где должна жить логика авторизации, чтобы быть одновременно согласованной и сопровождаемой по многим сервисам?
Насколько агрессивно следует обновлять зависимости с учётом компромисса между экспозицией и оттоком?
Какой уровень ASVS подходит для каждого класса приложений в вашем портфеле?
Как устранить долгоживущие секреты, не создав хрупкой инфраструктуры выдачи?
Что потребовалось бы вашей организации, чтобы производить и потреблять SBOM и происхождение для каждого артефакта?
Как не дать безопасным умолчаниям быть отключёнными под давлением поставки?

Главные выводы

OWASP Top 10 необходимое знание; ASVS даёт проверяемый стандарт.
Наслаивайте проверку ввода, параметризацию и кодирование вывода, чтобы победить внедрение и XSS.
Используйте проверенные протоколы (OAuth 2.0, OIDC) и принуждайте к MFA; никогда не стройте аутентификацию с нуля.
Принуждайте к авторизации на сервере для каждого запроса и каждого объекта.
Держите секреты вне исходников, управляйте ими централизованно и переходите на краткоживущие учётные данные.
Цепочка поставки основная поверхность атаки; используйте SBOM, SCA, подпись и происхождение (SLSA).
Автоматизированные повторно используемые средства контроля защищают весь парк с предельной ценой на сервис.

Источники и дополнительное чтение

OWASP, Top 10 Web Application Security Risks
OWASP, Application Security Verification Standard (ASVS)
OWASP, Cheat Sheet Series (Input Validation, Authentication, Authorisation, Secrets Management)
Dafydd Stuttard and Marcus Pinto, The Web Application Hacker’s Handbook
Aaron Parecki, OAuth 2.0 Simplified
National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines
Cloud Native Computing Foundation and OpenSSF, SLSA framework and Supply-chain Security guidance

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

Обзор и мотивация

Ключевые принципы

Рекомендации

Знайте и отражайте OWASP Top 10, проверяйте по ASVS

Проверяйте ввод и кодируйте вывод

Правильно реализуйте аутентификацию и авторизацию

Управляйте секретами и ротируйте ключи

Защищайте цепочку поставки программного обеспечения