# Протокол дня 1 — «Безопасность приложений»

## Паспорт занятия

- **Дата:** 11 августа 2026 года.
- **Программа:** **«Образовательная лаборатория Kaspersky Academy | Безопасность приложений»**.
- **Организатор обучения:** АО «Лаборатория Касперского».
- **Назначение:** методический ориентир для преподавателя при подготовке и проведении занятий по безопасности приложений, безопасной разработке и AppSec-практике.

Материалы подготовлены по результатам обучения по указанной программе. Протокол связывает теоретические категории OWASP Top 10:2025, учебную среду и методику разбора лабораторных работ. Для последовательного изучения обсуждений дня используйте [подробную стенограмму дня 1](Стенограмма-дня-01-подробная-редактированная.md).

## Тематическая последовательность

1. **Основы AppSec и карта атакуемой поверхности.** Определение активов, точек входа, границ доверия, ролей, потоков данных и последствий нарушения конфиденциальности, целостности и доступности.
2. **OWASP Top 10:2025 — A01–A03.** Нарушение контроля доступа, небезопасные конфигурации, риски цепочки поставок ПО; затем первый лабораторный блок.
3. **OWASP Top 10:2025 — A04–A06.** Криптографические уязвимости, инъекции и небезопасный дизайн; затем второй лабораторный блок с индивидуальной работой и групповым разбором.
4. **Безопасность ИИ и образовательный процесс.** Риски систем с большими языковыми моделями и агентными компонентами, доверие к данным и подключённым системам, подходы к оцениванию компетенций.
5. **Итоговая рефлексия.** Переход от демонстрации недостатка к объяснению первопричины, последствий, исправления и проверяемого результата.

## Основные учебные выводы

### Защита начинается с контекста

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

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

### Клиент не является источником доверия

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

### Меры должны быть проверяемыми

Хорошее исправление — не общий призыв «повысить безопасность», а конкретное изменение с доказательством: серверное правило доступа, параметризованный запрос, ограничение диапазона, allow-list, ограничение в СУБД, тест, журнал, правило CI/CD, проверка происхождения или подписи.

### Уязвимость, дефект и риск различаются, но связаны

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

### ИИ ускоряет работу, но не снимает ответственность

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

## Лабораторные работы первого дня

| ЛР | Тема и категория | Учебный фокус | Проверяемый результат | Профилактика |
|---|---|---|---|---|
| **ЛР_1** | **«Пакет контроля доступа»** — A01:2025 «Нарушение контроля доступа» | Аутентификация и авторизация; горизонтальное и вертикальное нарушение доступа; IDOR/BOLA | Поведение маршрута или API-объекта при проверке роли и владения | `deny by default`, серверная проверка `субъект → действие → объект`, централизованная политика, отрицательные тесты |
| **ЛР_2** | **«Устаревший интерфейс (оставленная поверхность атаки)»** — A02:2025 «Нарушение безопасности конфигураций» | Неиспользуемый endpoint остаётся частью поверхности атаки; ограничение в UI не равно серверной проверке | Подтверждённое поведение устаревшего интерфейса или обработчика загрузки | Удаление неиспользуемых маршрутов, серверная валидация содержимого, единообразные ошибки, конфигурация как код |
| **ЛР_3** | **«Уязвимая библиотека (резервный файл + сообщение об уязвимости)»** — A03:2025 «Уязвимости в цепочке поставок ПО» | Зависимость, версия, реестр и резервный файл — части цепочки поставки | Перечень зависимостей и обоснованная связь версии с известной проблемой | SBOM, SCA, фиксированные версии, внутренние реестры, проверка происхождения и подписей, мониторинг уязвимостей |
| **ЛР_4** | **«Утечка конфиденциальных документов через публичный файловый раздел + неподписанный JWT»** — A04:2025 «Криптографические уязвимости» | Конфиденциальность файлов, обязательность проверки подписи токена и допустимого алгоритма | Наблюдение доступа к незащищённому файлу либо поведения уязвимой проверки JWT в учебной среде | Классификация и разграничение доступа, запрет публичного листинга, allow-list алгоритмов, проверка подписи и claims JWT |
| **ЛР_5** | **«Пакет инъекций (SQL-инъекция + DOM-XSS)»** — A05:2025 «Инъекции» | Недоверенный ввод не должен становиться SQL-кодом или исполняемой частью DOM | Наблюдение учебного сценария SQLi или DOM-XSS с объяснением причины | Параметризованные запросы, безопасные ORM-паттерны, валидация входа, контекстное кодирование вывода, безопасные DOM API, CSP как дополнительный слой |
| **ЛР_6** | **«Время расплаты (отрицательное количество → злоупотребление бизнес-логикой)»** — A06:2025 «Небезопасный дизайн» | Бизнес-инвариант проверяется на сервере, а не только в форме | Наблюдение влияния недопустимого количества на расчёт корзины/кошелька в учебной среде | Серверные ограничения диапазона и типа, проверка итоговой суммы, точные денежные типы, ограничения СУБД, тесты бизнес-логики |

## Методические ориентиры для преподавателя

### До занятия

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

### Во время занятия

- Начинайте с модели угроз и карты поверхности атаки, а не с инструмента или payload.
- Разграничивайте наблюдение и вывод: один необычный ответ ещё не всегда доказывает класс проблемы.
- Спрашивайте, где должна выполняться проверка: UI, API, сервис, база данных, CI/CD или инфраструктура.
- Просите предлагать не только способ обнаружения, но и регрессионный тест.
- Поддерживайте две роли участника: обучающийся проходит задание, преподаватель одновременно оценивает, как адаптировать его к своей аудитории.

### После занятия

- Разбирайте первопричины в порядке «требование → архитектура → код/конфигурация → тест → эксплуатационное наблюдение».
- Оценивайте не эффект демонстрации, а полноту объяснения: что произошло, почему, какие последствия реалистичны, как предотвратить повторение.
- Для ИИ-инструментов включайте в критерии проверку версии, контекста, ограничений применения и самостоятельного понимания результата.

## Словарь

| Термин | Краткое значение |
|---|---|
| **Актив** | данные, функция, инфраструктурный компонент или иной объект, ценность которого нужно защищать |
| **Граница доверия** | место перехода данных, кода или полномочий между областями с разным уровнем доверия |
| **Идентификация** | заявление субъекта о том, кем он является |
| **Аутентификация** | проверка заявленной личности субъекта |
| **Авторизация** | решение, разрешено ли субъекту действие над конкретным объектом в данном контексте |
| **IDOR / BOLA** | доступ к объекту по подменённому или предсказуемому идентификатору без надлежащей авторизации |
| **JWT** | JSON Web Token — формат токена; важны проверка подписи, алгоритма и ограничений использования |
| **SBOM** | Software Bill of Materials — перечень компонентов программного продукта |
| **SCA** | Software Composition Analysis — анализ состава и зависимостей ПО |
| **SQLi** | SQL injection — изменение структуры SQL-запроса через недоверенный ввод |
| **XSS** | Cross-Site Scripting — выполнение внедрённого сценария в браузере пользователя |
| **CSRF** | Cross-Site Request Forgery — нежелательный межсайтовый запрос в контексте действующей сессии |
| **CWE** | Common Weakness Enumeration — классификатор типов слабостей ПО |
| **CVSS** | Common Vulnerability Scoring System — система оценки тяжести уязвимости |
| **EPSS** | Exploit Prediction Scoring System — оценка вероятности эксплуатации известной уязвимости |

## Полезные ссылки

- [OWASP Top 10](https://owasp.org/Top10/)
- [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
- [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/)
- [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/)
- [OWASP AI Security Verification Standard (AISVS)](https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/)
- ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»