# Безопасность приложений — день 2

## Методический конспект и редакторская карта

**Формат:** лекция, обсуждение, лабораторный блок, конструктор лабораторной работы.
**Связь с курсом:** продолжение дня 1 — от базовой модели AppSec и OWASP A01–A06 к аутентификации, целостности, наблюдаемости, устойчивости к ошибкам, non-web AppSec и внедрению SSDLC.

> Этот текст — авторская нормализованная редакция по материалам занятия. Он не является дословной расшифровкой аудиозаписи и не заменяет первоисточники OWASP, NIST, ГОСТ или внутренние регламенты организации. Полная редакторская стенограмма находится в `downloads/day-02/transcripts/Стенограмма-дня-02-полная-редактированная.md`.

## Результаты обучения

После занятия слушатель должен уметь:

1. Различать аутентификацию, управление сессией и авторизацию на уровне операции и объекта.
2. Объяснять риск небезопасной десериализации, нарушений цепочки поставки ПО и ошибок целостности данных.
3. Проектировать журналирование как обнаруживающий контроль, а не как неструктурированный набор сообщений.
4. Разделять историческую карту OWASP Top 10:2021 и редакцию OWASP Top 10:2025, не переносить номер категории между версиями автоматически.
5. Моделировать SSRF как server-side запрос через границу доверия и выбирать прикладные и сетевые меры защиты.
6. Выделять типовые риски C/C++, mobile и desktop‑приложений; связывать secure design, hardening и верификацию.
7. Встраивать безопасность в выбранную модель жизненного цикла через проверяемые артефакты SSDLC.
8. Применять ИИ‑инструменты в обучении и разработке с проверкой результата, сохранением конфиденциальности и явной ответственностью автора.

## 1. Редакционная рамка: OWASP 2021 и OWASP 2025

В исходных слайдах и речи встречаются две карты. Лабораторные задания исторически ориентированы на OWASP Top 10:2021, а лекционная часть обсуждает OWASP Top 10:2025. Их надо читать рядом, но не смешивать.

| Тема | OWASP Top 10:2021 | OWASP Top 10:2025 | Редакторское правило |
|---|---|---|---|
| Аутентификация | A07 Identification and Authentication Failures | A07 Authentication Failures | Номер сохранён; используйте актуальное название для новых документов. |
| Целостность ПО и данных | A08 Software and Data Integrity Failures | A08 Software or Data Integrity Failures | Сохраняйте связь с зависимостями, сборками и десериализацией. |
| Логирование | A09 Security Logging and Monitoring Failures | A09 Security Logging & Alerting Failures | В 2025 подчёркнута обязанность alerting, а не только записи в лог. |
| SSRF | A10 Server-Side Request Forgery | Не является A10:2025 | В курсе — историческая ЛР и тематическое дополнение. |
| Обработка исключительных ситуаций | не отдельная категория | A10 Mishandling of Exceptional Conditions | Рассматривается отдельно: fail-open, ошибки, таймауты, отказоустойчивость. |

**Обязательная формулировка для материалов курса:** `A10:2021 — Server-Side Request Forgery (SSRF)` и `A10:2025 — некорректная обработка исключительных ситуаций`. Нельзя подписывать SSRF как A10:2025.

## 2. A07:2025 — Authentication Failures

### 2.1. Что защищает аутентификация

Аутентификация отвечает на вопрос: «достаточно ли доказательств, что субъект — это заявленный субъект?». Она не отвечает на вопрос: «может ли этот субъект выполнить действие над этим объектом?». Второй вопрос относится к авторизации и должен проверяться сервером на каждой значимой операции.

Практически важно разделять четыре слоя:

1. **Идентификация:** имя, адрес, номер, ключ или иной идентификатор субъекта.
2. **Проверка доказательства:** пароль, криптографический ключ, одноразовый код, биометрия или доверенное устройство.
3. **Управление сессией:** выдача, хранение, срок действия, обновление, отзыв и защита идентификатора сессии.
4. **Авторизация:** политика роли, атрибута и владения объектом на серверной стороне.

### 2.2. Типовые сценарии

- **Credential stuffing:** автоматическая проверка ранее утёкших пар «идентификатор–пароль» против другого сервиса. Защита: уникальные пароли, MFA, блокирование известных скомпрометированных паролей, rate limiting, риск‑ориентированная аналитика и оповещение владельца.
- **Password spraying:** небольшое число популярных паролей проверяется против большого числа учётных записей. Простая блокировка одной учётной записи после нескольких ошибок сама по себе не решает проблему; нужны ограничения по источнику, по скорости, по риску и хорошие события мониторинга.
- **Небезопасное восстановление доступа:** предсказуемые ответы, длительно действующая ссылка, раскрытие существования учётной записи, отсутствие повторной аутентификации для чувствительных действий.
- **Фиксация сессии:** атакующий заранее задаёт или получает идентификатор сессии, который продолжает действовать после успешного входа жертвы. Минимум защиты: заменить идентификатор после входа/повышения привилегий, ограничить срок жизни, использовать `Secure`, `HttpOnly`, подходящий `SameSite`, отзыв и server-side проверку состояния.

### 2.3. Пример критериев проверки

| Проверка | Ожидаемый безопасный результат |
|---|---|
| Вход после серии неудач | Скорость и риск ограничены; событие доступно для анализа; легитимный пользователь получает безопасный путь восстановления. |
| Сброс пароля | Ссылка одноразовая, короткоживущая, не раскрывает лишних данных, после смены пароля старые сессии отзываются по политике. |
| Вход с существующей сессией | После входа выдан новый session id; исходный нельзя использовать для авторизованного действия. |
| Доступ к чужому объекту | Сервер возвращает `403` или безопасный `404`; клиентский идентификатор не является доказательством права. |

### 2.4. Контрольные вопросы

1. Почему успешный вход не даёт права получить произвольный ресурс по его идентификатору?
2. Чем password spraying отличается от credential stuffing по объекту перебора и по телеметрии?
3. Какая смена состояния должна приводить к ротации сессии?
4. Почему `HttpOnly` снижает часть последствий XSS, но не устраняет сам XSS?

## 3. A08:2025 — Software or Data Integrity Failures

### 3.1. Доверенная цепочка поставки

Целостность возникает не только в момент записи в базу данных. Сборка, зависимость, контейнер, пакет, конфигурация, модель данных и обновление — все это артефакты, происхождение которых нужно уметь подтвердить.

Минимальный практический набор:

- фиксировать версии и происхождение зависимостей, поддерживать SBOM;
- проверять подписи и хеши артефактов там, где это предусмотрено процессом;
- разделять права на изменение исходников, pipeline и релизных артефактов;
- исключать «скачать и выполнить» из неаутентифицированного источника;
- документировать исключения из политики и срок их пересмотра;
- тестировать процесс обновления, включая отказ, rollback и контроль версии.

### 3.2. Небезопасная десериализация

Структурированный вход остаётся недоверенным входом. Риск появляется, когда десериализатор создаёт объекты, исполняет callback, раскрывает внутренний тип, допускает чрезмерную глубину/объём или изменяет состояние за пределами ожидаемой модели.

Защита строится в следующем порядке:

1. Не принимать сериализованные объекты из недоверенного источника, если можно передать простую явно описанную структуру.
2. Использовать безопасный парсер и schema validation; не включать небезопасные теги, полиморфные типы или автоматическое конструирование объектов.
3. Ограничивать размер, глубину, время и потребление памяти парсера.
4. Подписывать и проверять целостность действительно доверенных сообщений, но не считать подпись заменой валидации.
5. Писать отрицательные тесты: недопустимый тип, лишнее поле, большая глубина, циклическая структура, неподдерживаемая кодировка.

**YAML‑bomb** полезен как демонстрация потребления ресурсов, но запускать его допускается только в отдельном контролируемом локальном стенде и с лимитами ресурса. Он не является «универсальным payload‑ом» и не должен запускаться против внешнего сервиса.

### 3.3. Контрольные вопросы

1. Какие артефакты релиза должны иметь проверяемое происхождение?
2. Почему валидация схемы и проверка подписи решают разные задачи?
3. Какие лимиты нужно определять для ресурсоёмкого разбора входных данных?

## 4. A09:2025 — Security Logging & Alerting Failures

### 4.1. Лог — не цель, а часть наблюдаемого контроля

Логирование помогает расследовать и обнаруживать отклонения только при наличии полного контура:

`событие → структурированная запись → доставка и защита → корреляция → порог/правило → владелец реакции → разбор → улучшение контроля`.

Минимальная карточка события включает:

- точное время и идентификатор корреляции;
- тип действия и результат;
- субъект, аутентификационный контекст и роль;
- объект операции в минимально необходимом виде;
- источник/среду/версию сервиса;
- код ошибки или решение политики без секретов;
- след изменения конфигурации или привилегии, если это применимо.

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

### 4.2. Доказательство работоспособности

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

## 5. A10:2025 — некорректная обработка исключительных ситуаций

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

Признаки опасного поведения:

- разрешение доступа или продолжение операции при неопределённом состоянии (`fail-open`);
- возврат пользователю stack trace, секретов, внутренних путей или подробной модели данных;
- бесконечное ожидание, неограниченные повторы, неконтролируемое выделение ресурса;
- отсутствие атомарности/компенсации в критичном процессе;
- исключение, которое исчезает из телеметрии или получает неверный уровень серьёзности.

Практический ответ включает явный контракт ошибок, безопасный HTTP/IPC‑ответ, timeout, retry budget, circuit breaker где применимо, идемпотентность, ограничение ресурсов, журналирование и проверку того, что отказ не обходит политику.

## 6. SSRF как историческая лабораторная тема (A10:2021)

### 6.1. Модель угрозы

SSRF возникает, когда приложение получает URL или аналогичный параметр от пользователя и сервер выполняет по нему запрос. В браузере может не быть доступа к внутренней сети, но сервер может иметь доступ к API, служебному контейнеру, административному интерфейсу или metadata service. Поэтому объектом защиты является не «строка URL», а **возможность server-side запроса перейти через границу доверия**.

### 6.2. Учебный стенд

В авторском пакете дня 2 используется отдельный минимальный fixture `participant-materials/lr-ssrf`:

- только минимальный gateway опубликован на `127.0.0.1:8080`;
- `app` и `internal` не публикуют порт на хост и находятся в Docker‑сети `internal: true`;
- gateway проксирует запрос только к фиксированному `app`, не выбирает URL по данным пользователя;
- внутренний ресурс выдаёт только синтетический маркер `INTERNAL_METADATA`;
- стенд не предназначен для проверки каких-либо внешних адресов.

Такой выбор заменяет нестабильный шаг, зависящий от внутренней реализации конкретной версии Juice Shop. Цель занятия — не «засчитать challenge», а построить модель потока, доказать первопричину и реализовать защиту.

### 6.3. Исправление и регрессия

1. Разрешать только нужные схемы, хосты/маршруты и типы контента; предпочтительнее не принимать URL вообще, если можно передавать идентификатор заранее описанного ресурса.
2. Разрешить DNS и проверить каждый фактический IP; отдельно блокировать loopback, private, link-local и зарезервированные диапазоны согласно модели сети.
3. Повторять проверку на каждом redirect; ограничить redirect, timeout, размер и число ответов.
4. Запретить egress на уровне сети и учётных данных процесса, чтобы прикладная ошибка не стала прямым доступом к инфраструктуре.
5. Покрыть отрицательными тестами запрещённые схемы, неоднозначные IP‑представления, приватные адреса, redirect и разрешённый позитивный маршрут.

## 7. Non-web AppSec

### 7.1. Нативный C/C++

В нативном коде особенно важны память, арифметика размеров, владение ресурсом, границы между модулем/процессом и качество ABI/API. Buffer overflow, integer overflow, use-after-free, double free и type confusion относятся к разным первопричинам; все они требуют исправления дизайна и кода, а не только включения одного флага компилятора.

**Практики проектирования и кода:**

- использовать типы размера осознанно, проверять преобразования и пределы до арифметики;
- предпочитать RAII, контейнеры стандартной библиотеки и интерфейсы с явной длиной;
- разделять собственность, заимствование и время жизни объектов;
- не передавать сырой указатель как единственное доказательство размера/владения;
- требовать code review для операций с памятью, сериализацией, IPC, криптографией и границами привилегий;
- сохранять воспроизводимый набор статического анализа, sanitizers и fuzzing‑корпус в CI.

**Hardening как defense in depth** (конкретные опции зависят от toolchain/платформы): stack protector, fortify, PIE/ASLR, RELRO, контроль предупреждений, CFI где поддерживается, AddressSanitizer/UndefinedBehaviorSanitizer и memory-safe компоненты там, где это возможно. Эти меры обнаруживают или затрудняют часть последствий, но не доказывают отсутствие первопричины.

### 7.2. Mobile

Проверяйте exported components, intents, deep links, permissions, WebView, хранение токенов, резервные копии, certificate pinning с планом ротации, нативные библиотеки и канал обновления. Доверять следует серверной проверке права, а не только состоянию UI или флагу в intent.

### 7.3. Desktop

Поверхность desktop‑приложения включает updater, IPC, локальные сокеты/именованные каналы, конфигурации, плагины, файловые ассоциации, пути поиска библиотек, журналирование, права процесса и интеграцию с ОС. Обновление должно иметь проверяемую целостность и безопасный rollback; IPC — явную аутентификацию/авторизацию и минимально необходимый протокол.

## 8. SSDLC: от модели жизненного цикла к проверяемому процессу

### 8.1. Модели разработки

Водопадная модель удобна при стабильных требованиях, итеративная и agile — при частой обратной связи, V‑модель подчёркивает соответствие между этапами проектирования и проверками, спираль управляет рисками через циклы анализа, прототипирование снижает неопределённость. Безопасность не является заменой модели: она добавляет контрольные вопросы и результаты в ту модель, которую использует команда.

### 8.2. Минимальный поток SSDLC

| Этап | Вопрос безопасности | Проверяемый выход |
|---|---|---|
| Инициация и требования | Что защищаем, от кого, кто владелец решения? | security‑требования, классификация данных, роли. |
| Архитектура | Где границы доверия и сценарии злоупотребления? | модель угроз, решения по рискам, ADR. |
| Реализация | Как исключаются типовые ошибки и утечки секретов? | secure coding rules, review, SAST, secret scanning. |
| Зависимости и сборка | Чем мы реально собираем и что попадает в релиз? | SBOM, SCA, pinned dependencies, provenance. |
| Верификация | Как проверяем позитивные и негативные сценарии? | тесты, fuzzing, DAST где применимо, отчёты и исключения. |
| Выпуск | Как подтверждаем целостность и управляем изменением? | подпись, release checklist, контроль конфигурации. |
| Эксплуатация | Как обнаруживаем и закрываем новые риски? | logging/alerting, vulnerability management, postmortem, regression. |

### 8.3. Моделирование угроз и оценки

STRIDE — метод систематически искать угрозы подмены, изменения, отказа от авторства, раскрытия, отказа в обслуживании и повышения привилегий по потокам данных и границам доверия. CVSS нужен для описания характеристик уязвимости после её обнаружения; он не строит модель угроз и не назначает бизнес‑приоритет без контекста актива и экспозиции.

### 8.4. Нормативная опора

- **ГОСТ Р 56939‑2024** — использовать как применимую отечественную рамку организации безопасной разработки и контроля процессов.
- **ISO/IEC 27034** — связывать application security с организационным контекстом и жизненным циклом.
- **NIST SP 800‑218 (SSDF)** — организовать практики подготовки, защиты, производства хорошо защищённого ПО и реагирования на уязвимости.
- **OWASP SAMM** — оценивать зрелость практик без сведения безопасности к одному инструменту.
- **OWASP ASVS** — превращать требования в проверяемые критерии на уровне приложения.
- **CWE** — фиксировать класс первопричины и связать исправление с тестом.

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

## 9. ИИ, агентные системы и обучение

LLM может быстро подготовить вариант текста, кода, теста или объяснения. Агентная система добавляет цикл «планирование → вызов инструмента → наблюдение → уточнение», а значит создаёт новые границы: разрешения инструментов, источники данных, маршруты выполнения, журналирование действий и подтверждение человеком.

Базовые правила:

1. Не помещать в стороннюю модель секреты, персональные данные, внутренний код и документы без разрешения и оценки поставщика.
2. Считать любой вывод гипотезой до проверки первоисточником, тестом, линтером или экспертом.
3. Дать агенту минимум привилегий, ограниченный набор инструментов и проверяемые границы данных.
4. В обучении оценивать цепочку рассуждения, артефакт проверки и способность объяснить решение, а не только гладкий ответ.
5. Фиксировать использование ИИ прозрачно: где он помог, что проверил человек и что осталось неопределённым.

## 10. Набор практических заданий

Полная спецификация находится в `materials/практикум-день-2-набор-заданий.md`. Общий формат сдачи для каждого задания:

1. Цель, граница разрешённой локальной среды и процедура reset.
2. Минимальный request/response, снимок или иной артефакт факта.
3. Формулировка первопричины без подмены симптомом.
4. Последствия в контексте модели угроз.
5. Конкретное server-side / архитектурное исправление.
6. Отрицательный regression test, подтверждающий, что исправление работает.

## 11. Контрольный чек-лист преподавателя

- [ ] На титульном слайде/странице указана дата и версия OWASP.
- [ ] SSRF не подписан как A10:2025.
- [ ] В заданиях разрешены только localhost и закрытые контейнерные сети.
- [ ] Нет призывов атаковать внешние хосты, корпоративные ресурсы или реальные metadata services.
- [ ] Персональные данные, имена подгрупп, Word metadata и raw‑транскрипты не опубликованы.
- [ ] Для любой демонстрации есть reset/cleanup и доказательство безопасной исправленной версии.
- [ ] В источниках указаны первичные нормативные/методические материалы.
- [ ] Практика оценивает первопричину и регрессию, а не только «challenge solved».

## Источники

1. [OWASP Top 10:2025 — Introduction](https://owasp.org/Top10/2025/0x00_2025-Introduction/).
2. [OWASP Top 10:2025 — A07 Authentication Failures](https://owasp.org/Top10/2025/A07_2025-Authentication_Failures/).
3. [OWASP Top 10:2025 — A08 Software or Data Integrity Failures](https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/).
4. [OWASP Top 10:2025 — A09 Security Logging & Alerting Failures](https://owasp.org/Top10/2025/A09_2025-Security_Logging_and_Alerting_Failures/).
5. [OWASP Top 10:2025 — A10 Mishandling of Exceptional Conditions](https://owasp.org/Top10/2025/A10_2025-Mishandling_of_Exceptional_Conditions/).
6. [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/).
7. [OWASP SAMM](https://owasp.org/www-project-samm/).
8. [OWASP Server Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html).
9. [NIST SP 800-218, Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final).
10. ГОСТ Р 56939‑2024, ISO/IEC 27034, применимые документы организации и конкретной системы.