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

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

## 1. Цель практикума

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

## 2. Контракт безопасности перед началом

До запуска преподаватель и слушатель подтверждают:

- цель намеренно уязвима и локальна либо предоставлена для учебной работы;
- сервис не доступен из Интернета и не слушает все интерфейсы хоста;
- не используются production-данные, реальные учётные записи, персональные данные и секреты;
- версия образа/приложения зафиксирована тегом и предпочтительно digest;
- контейнер не получает Docker socket, `--privileged`, секреты, широкие монтирования или привилегированную сеть;
- есть порядок удаления учебной среды и публикационный фильтр для доказательств.

### Безопасный принцип публикации порта

Если Docker нужен для локальной демонстрации, порт привязывают к loopback-адресу, например `127.0.0.1:3000:3000`, и используют `--rm` для удаления временного контейнера после остановки. Не применяйте проброс без явного loopback-адреса для намеренно уязвимой цели. Не размещайте учебные цели на сервере сайта.

### Версия Juice Shop

OWASP Juice Shop развивается, и набор challenge меняется. Не используйте «плавающий» образ как стабильный контракт занятия. Перед занятием:

1. Проверьте [официальный release](https://github.com/juice-shop/juice-shop/releases).
2. Выберите, протестируйте и зафиксируйте тег/digest.
3. Запишите его в протокол группы и в отчёты.
4. Укажите лицензию конкретного upstream-релиза и его NOTICE.

## 3. Маршрут лабораторной работы

| Этап | Время | Действие | Результат |
|---|---:|---|---|
| Контекст | 5–7 мин | Актив, роль, граница доверия, ожидаемый инвариант | Сценарий проверки и границы разрешения |
| Практика | 20–25 мин | Проверка в локальной цели без выхода за пределы задания | Обезличенное наблюдение |
| Анализ | 10–12 мин | Первопричина, последствия, защитные меры | Черновик отчёта и регрессионный тест |
| Рефлексия | 5 мин | Что изменится в требованиях/коде/CI/CD | Один переносимый вывод |

## 4. Формула доказательства

Запись «получен флаг» недостаточна. В отчёте связываются пять элементов:

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

## 5. Темы и безопасные выводы

### A01 — контроль доступа

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

### A02 — конфигурация

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

### A03 — цепочка поставки

Фиксируйте зависимости в lockfile, формируйте SBOM, запускайте SCA, ограничивайте registry и подтверждайте происхождение артефакта. В CI/CD применяйте наименьшие привилегии, краткоживущие секреты и аудит изменений.

### A04 — криптография и токены

Явно фиксируйте допустимые алгоритмы. Проверяйте подпись/ключ и claims, включая `iss`, `aud`, `exp`, `nbf`. Не утверждайте, что конкретная JWT-библиотека по умолчанию принимает `alg=none`, если проверен только один учебный verifier.

### A05 — инъекции

Используйте параметризованные SQL-запросы; безопасные шаблоны и DOM API; контекстное экранирование; анти-CSRF-токены и защиту чувствительных операций; отказ от shell для недоверенных данных. Не выдавайте условное последствие XSS как безусловную «кражу cookie».

### A06 — проектирование

Инварианты проверяются на сервере и, где уместно, на уровне БД. Примеры: количество не меньше единицы, итог вычисляется по доверенным данным, цена неотрицательна, денежные значения используют точный тип, критичные операции атомарны.

### SSRF и сеть

Учебный SSRF-сервис не должен быть доступен публично. Внешний контейнер, если это необходимо для занятия, привязывается только к loopback; внутренний контейнер остаётся в приватной сети Docker без опубликованного порта. Для production нужны allow-list адресатов, защита DNS/IP, egress-политики, тайм-ауты и журналирование.

### C/C++ и память

Не сводите защиту к отключению защитных флагов ради демонстрации. В целевом коде первичны корректные границы буферов, безопасные API, проверка длины, отсутствие shell-интерпретации недоверенных данных. Дополнительно используйте `-fstack-protector-strong`, `-D_FORTIFY_SOURCE=3` при поддержке, PIE/RELRO/NX, sanitizers, fuzzing и правила CERT C/C++ / MISRA, применимые к проекту.

## 6. Раздельная классификация

В отчёте должны быть две независимые поля:

- **Тема учебного блока по notebook:** например, A03:2025.
- **Класс challenge в Juice Shop:** например, Sensitive Data Exposure, Vulnerable Components или XSS.

Эти поля не следует объединять в одно «официальное» утверждение. Для SSRF отдельно укажите историческую привязку OWASP Top 10:2021 A10 и корректное положение в OWASP Top 10:2025.

## 7. Публикационный фильтр

Для публичной части фиксируйте:

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

Открытый архив первого дня публикует исходные слайды, стенограммы, программу и учебный пакет вместе с атрибуцией и каталогом происхождения файлов.

## 8. Критерии оценки

| Критерий | Ориентир |
|---|---:|
| Результат и полнота обязательных шагов | 30 % |
| Наблюдаемое доказательство без чувствительных данных | 30 % |
| Объяснение первопричины | 20 % |
| Конкретность исправления и защиты в глубину | 15 % |
| Безопасность и аккуратность оформления | 5 % |

## 9. Источники

- [OWASP Top 10](https://owasp.org/Top10/)
- [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/)
- [Juice Shop Releases](https://github.com/juice-shop/juice-shop/releases)
- [OWASP WSTG](https://owasp.org/www-project-web-security-testing-guide/)
- [CERT C Coding Standard](https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard)