# Безопасность приложений — день 1: методический конспект

> **Материалы автора.** Подготовлены на основе программы АО «Лаборатория Касперского» **«Образовательная лаборатория Kaspersky Academy | Безопасность приложений»** и адаптированы для повторного использования в собственных курсах.
>
> Методичка предназначена для преподавателей и слушателей. Она не является официальным ресурсом АО «Лаборатория Касперского» и не означает его одобрения.

## Назначение

Конспект помогает провести или повторить первый учебный день по безопасности приложений: объяснить, как связать архитектуру, риски, сценарии злоупотребления, OWASP-категории и проверяемые защитные свойства. Слайды, подробная стенограмма, протокол и практические материалы собраны в [каталоге материалов первого дня](каталог-материалов-дня-1.md).

## Программа дня: учебная логика

1. **Основы AppSec.** Активы, угроза, уязвимость, риск; конфиденциальность, целостность и доступность (CIA).
2. **Архитектура и поверхность атаки.** Клиент, сервер, API, база данных, CI/CD, зависимости и границы доверия.
3. **OWASP A01–A03.** Контроль доступа, конфигурация, цепочка поставки ПО.
4. **Лабораторный блок 1.** Работа исключительно в разрешённой локальной намеренно уязвимой среде; оформление доказательств.
5. **OWASP A04–A06.** Криптографические сбои, инъекции, небезопасное проектирование.
6. **Лабораторный блок 2.** Связь наблюдения с причиной, последствиями и исправлением.
7. **Безопасность ИИ.** Риски LLM/agentic-систем, границы полномочий инструментов, проверка источников и образовательная ответственность.

## Базовые понятия

| Понятие | Рабочее определение | Вопрос преподавателя |
|---|---|---|
| Актив | То, что имеет ценность и требует защиты | Что именно потеряет организация/пользователь? |
| Угроза | Возможное нежелательное событие или источник вреда | Кто/что может реализовать сценарий? |
| Уязвимость | Недостаток, который делает сценарий реализуемым | Где нарушено ожидаемое свойство? |
| Риск | Сочетание вероятности и последствий | Что будет, если сценарий реализуется? |
| Граница доверия | Переход данных/команды между областями разного доверия | Что нужно проверить при переходе? |

### Не смешивать процессы

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

Успешная аутентификация не даёт универсального доступа. Авторизацию проверяют на доверенной стороне при каждом чувствительном действии.

## Карта поверхности атаки

Для любой функции приложения пройдите пять шагов:

1. Опишите бизнес-цель и активы.
2. Нарисуйте поток данных и границы доверия.
3. Перечислите входы, выходы, роли, хранилища, интеграции и зависимости.
4. Сформулируйте сценарии злоупотребления.
5. Для каждого сценария задайте защитное свойство и доказательство его выполнения: тест, контроль CI/CD, журнал или ограничение схемы данных.

Пример: форма обратной связи с вложением — это не только UI. Нужно рассмотреть загрузку файла, тип и размер, хранение, антивирус/песочницу, права модератора, уведомления, журналы и возможный доступ к объекту другими пользователями.

## OWASP Top 10:2025 — темы первого дня

| Раздел | Инженерный смысл | Проверяемая защита |
|---|---|---|
| **A01:2025 — Нарушение контроля доступа** | Роль/маршрут не заменяют проверку конкретного объекта | deny by default; серверная проверка субъекта, действия, объекта и контекста; отрицательные тесты IDOR/BOLA |
| **A02:2025 — Небезопасная конфигурация** | Старые endpoint’ы, debug и излишние ошибки остаются частью поверхности атаки | минимальная конфигурация, IaC/review, безопасные ошибки, контроль заголовков и экспозиции сервисов |
| **A03:2025 — Сбои в цепочке поставки ПО** | Библиотеки, образы и CI/CD являются частью продукта | SBOM, SCA, lockfile, проверка digest/provenance, приватный registry, наименьшие права CI |
| **A04:2025 — Криптографические сбои** | Сбой возможен в ключах, протоколе, токене или проверяющем коде | allow-list алгоритмов; проверка подписи, ключа, `iss`, `aud`, `exp`, `nbf`; негативные тесты |
| **A05:2025 — Инъекции** | Недоверенные данные меняют смысл команды или выполняются в неверном контексте | параметризованные запросы; безопасный DOM/шаблон; контекстное экранирование; отказ от shell |
| **A06:2025 — Небезопасное проектирование** | Бизнес-правило не определено/не защищено до реализации | abuse cases, серверные инварианты, точные типы денег, атомарность, ограничения БД |

## Важные уточнения для разбора

### JWT

JWT — JSON Web Token. Уязвимость вида `alg=none` не означает, что любой JWT или конкретная библиотека по умолчанию принимает неподписанный токен. Корректный вывод из учебного сценария: **уязвимый verifier** принял токен, потому что не навязал ожидаемую криптографическую политику. Защита — строгая проверка алгоритма, подписи, ключа и claims; смена библиотеки без этой политики не решает проблему.

### XSS и CSRF

XSS — выполнение внедрённого сценария в контексте доверенного сайта. Это не обязательно означает доступ к cookie: он зависит от `HttpOnly`, `SameSite` и модели хранения токенов. CSRF использует автоматически отправляемые браузером учётные данные для нежелательного действия; противодействие включает anti-CSRF-токены, `SameSite`, проверку `Origin`/`Referer` как дополнительный сигнал и повторную аутентификацию для критичных действий.

### SSRF

В OWASP Top 10:2021 SSRF было A10. В OWASP Top 10:2025 A10 — **Mishandling of Exceptional Conditions**, а SSRF/CWE-918 учитывается в A01. Не переносите старую метку как «A10:2025 SSRF».

## Лабораторная рефлексия

Один флаг или экран не является полноценным результатом. Отчёт должен показать:

1. Разрешённую локальную среду, дату и зафиксированную версию.
2. Нейтральное описание проверенного сценария.
3. Обезличенное наблюдение, подтверждающее недостаток.
4. Первопричину в коде, конфигурации или проектировании.
5. Возможные последствия для актива.
6. Конкретную профилактику и регрессионный тест.

Учебная привязка блока и собственная категория challenge в Juice Shop могут различаться. Храните обе метки отдельно: «тема учебного блока по notebook» и «класс challenge в Juice Shop».

## ИИ и образовательный процесс

Система с LLM — это не только модель: в ней есть данные, источники, системные инструкции, память, оркестрация, инструменты и люди. При обсуждении OWASP Top 10 for LLM Applications проверяйте:

- происхождение и доверенность данных/контекста;
- возможность prompt injection и poisoning памяти;
- полномочия инструмента, allow-list операций и параметры вызова;
- изоляцию, лимиты, наблюдаемость и одобрение человека для необратимых действий;
- качество результата и независимую проверку фактов/кода;
- версию применённого источника OWASP и дату проверки.

## Минимум источников

- [OWASP Top 10](https://owasp.org/Top10/)
- [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
- [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/)
- [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/)
- [Kaspersky Academy](https://academy.kaspersky.com/)

## Открытый архив и редакторская версия

Этот конспект допускает адаптацию с сохранением атрибуции автора. В открытом архиве представлены слайды, Markdown-протокол, подробная стенограмма и пересказы. Для нового материала фиксируйте редакцию, дату и контекст его использования.